Continuous Retrospectives

At the end of each Sprint, teams should have a Sprint Retrospective to get actionable ideas for improvement for the next sprint.  Good, bad or indifferent, the points are discussed to allow the team to praise, vent and reflect.

However, in a 2 week Sprint a lot can happen.  The Sprint could have started badly and turned out well, for whatever reason.  In cases like this the retrospective will most likely focus on the points that are fresher in the memory rather than providing an overall view of the sprint.

To get more realistic actions from Retrospectives and to quicken the inspect and adapt cycle we often use Continuous Retrospectives.  Our team write down any item they want to discuss during the Retrospective and add these to the task board.

We choose an appropriate number of items to act as a catalyst for a retrospective.  So if our limit is 3 items, we must have a retrospective once any 3 items are added to the board.

This allows is to quickly resolve issues meaning we can see benefits immediately within the current sprint.

Meet the acceptance criteria, don't exceed it

During the initial sprint reviews for our current project it became apparent that the team weren't meeting the acceptance criteria for the user stories that made up the Sprint Backlog.

Our retrospectives helped us find that this was generally because the team over-built, delivering more functionality than was actually required to meet the stories.

The team felt that they were doing the right thing in delivering more to the Product Owner, however as they were pushing themselves to deliver a higher volume of functionality they lost sight on delivering high quality software ultimately meaning that we were failing our client by delivering an unusable, buggy system.

This also affected our Product Owner as the additional functionality had not been previously approved by them.  If additional work was going to be delivered our Product Owner should have the authority to determine what that functionality should be.

When discussed with the team they realised the impacts that this was having and agreed to do only what was in the stories.

Information Radiators

A colleague of mine recently protested about our whiteboard and post-it note project board as he felt that we'd be much better served with an online solution so that team members who work from home could view and update any progress.

As much as this is true I argued that using a system to store progress information was effectively locking the project board and it's information away therefore making it much less useful.

A physical board sitting beside the team acts as an Information Radiator, pushing project information out to the team.   At a glance anyone can clearly see the status of the project, and any changes being made are immediatley visible as you can actually see when people update the board.

Having to access and log in to a system may sound easy enough but in practice these extra steps generally discourages a team from making updates to the board and if that happens then you lose all the advantages that a project board gives you.