Agile methodology in the wild

Agile methodologies like Scrum sound amazingly efficient when presented by people who have implemented them in a non-hostile environment. But conditions are not always perfect, and things can sometimes go wrong.

One of the key features of agile project methodologies is that they have different types of meetings. Each different type of meeting has a very specific function. They can become tedious and unproductive if they deviate from the prescribed form and function. With that in mind, let's look at the different types of meeting, how they are meant to work, and what can go wrong.

Three Amigos   © Copyright Peter Trimming and licensed for reuse under this Creative Commons Licence.

Three Amigos

This is a relatively new type of meeting in the agile toolkit, and was developed in 2013.

Essentially, this is a meeting during which the business analyst (BA) presents the requirements and tests for a new feature. The Three Amigos (BA, developer, and QA) discuss the new feature and review the specification. The aim is to create a common understanding and shared vocabulary across these individuals. The QA and developer also identify missing requirements/edge cases — these need to be defined before a feature is considered ready for development ("ready for dev") and can be assigned into a sprint.

Estimation meeting

The estimation meeting is for estimating the size of different tasks that could go into a sprint (a time-boxed collection of work to be done by the team). One way to do this is called Planning Poker, where the team hold up number cards to estimate the size of a task. The aim is to reach consensus.

This can go wrong in a number of ways. One problem is when the nature of the task is not well-understood, or is disputed. This will lead to long discussion about what the task actually involves. This discussion is actually outside the scope of an estimation meeting, and should have already happened in a Three Amigos meeting. Another problem can be when a team member spends ages deliberating about which card to hold up. The point is that your individual opinion of task size doesn't matter that much - you are there to contribute to the consensus view. Uncertainty about the size of the task is often caused by not being sure about what the task actually involves.

You can fix a lot of these issues by only estimating user stories that have been prioritised by the product owner and analysed by the Three Amigos meeting. Ensure you have completed this checklist before scheduling your estimation meeting.

• 10 Tips for Better Story Estimation - LeadingAgile
• Scrum Effort Estimation and Story Points - Scrum Methodology
• Success Story: How to Estimate Quickly and Efficiently? - Scrum Alliance

Sprint Planning Meeting

Once the top priority stories in the product backlog have been estimated, the sprint planning meeting can take place. At this meeting, the development team agree to complete a specified number of stories during the sprint. This can go wrong in a number of ways. One risk is that the team has been unable to effectively measure their velocity in previous sprints, and so commits to an unrealistic amount of work. Another is if the team is not empowered to select the amount of work it can realistically complete; or if the tasks are not well-understood, and were therefore estimated inaccurately.

Daily Stand-up

The purpose of the daily stand-up meeting is for each developer to answer three questions:

• What did you do yesterday?
• What will you do today?
• Are there any obstacles in your way?

Only answers to these three questions should be allowed in a well-run stand-up meeting; and the answers should not go into great detail. The daily stand-up meeting can quickly become bogged down with unnecessary levels of detail, particularly if managers are allowed to chip in and ask questions. The best way to do a daily stand-up is to hold it around the scrum board, so that the scrum master can move the "done" stories into the review column, or the completed column, as appropriate.

Sprint Review Meeting

At the sprint review meeting, the team demonstrates potentially shippable features to the product owner. If the user story for the feature was well-formed and well-understood, this should be a pleasurable and easy process of demonstrating the features that the team developed during the sprint.

Sprint Retrospective

The aim of the sprint retrospective is to review how well the sprint went, and what could be done to improve team velocity, team communication, and so on. It should never descend into recriminations, blame-and-shame sessions, or other horrors. The goal of the meeting is to take collective responsibility as a team, not to pin the blame for something that went wrong onto a particular individual. The quickest and most effective way to hold a sprint retrospective is to hand post-it notes out to the team, and invite them to write on them what went well, what could have gone better, and what could be done differently to improve things?