The Sprint (and common misunderstandings)

How a Sprint should look like

I am writing this blog post because I again recognised a current misunderstanding of how the Development Team works together in a Sprint. You might notice, that I am not a football expert, but I will use a football (ball-game) metaphor to explain what I mean. I will only address the most common problems I have encountered. For the sake of simplicity, I will solely focus on User Stories, not on the tasks to accomplish the User Stories.

Beginning of a Sprint
The beginning of a Sprint

The game duration is the duration of the Sprint. In the game, the players (the Development Team) have to score as many goals as possible – which means they have to take a ball from the left side to the right side of the field (the goal). The balls on the left side are the user stories that the team wants to implement during the Sprint. The balls on the playing field are unfinished user stories. The balls in the goal are finished user stories. For each goal, the football club receives fame and honour (and money). The players have different roles, such as defenders, midfielders, forwards and others. In the Development Team, this might be software developers and software testers with different areas of expertise. The goalkeeper is the Product Owner, who decides if a story is completed (goal) or not (the ball goes back on the field).

Too many balls on the playing field (Multitasking)

What you will often see is that some players deal with many balls at once. Probably, because the implementations are interrelated, or they like to multitask, or they get bored when working on one story at a time, or any other reason. Of course, while the development code is written the testers will write new test-cases or regression tests or update automatical tests.

Too many Stories in Progress
Too many Stories in Progress as well as an imbalance between work-load

Consequently, there could be the danger, that the software developer finishes many or all user stories at once and hands them over to a tester. This tester then has a lot of work to do while the software developer has slack time (or he asks for new user stories from the Product Backlog). Thus, the tester might not finish his work before the Sprint ends, buggy stories go back to the developers and more. There is no flow in this system. Often at the end of the Sprint, many User Stories will remain unfinished. Other consequences are the downsides of Multitasking. You can experience the downsides of Multitasking by playing Brain Shock or Multitasking Infection.

Hence, the team should work on as little stories at once as possible and focus on finishing stories. You can easily visualise the flow on a task board and discuss it in the Daily Standup conversation.

Team members don’t support each other

Especially in new teams with people who are not used to work in a team, everyone sticks with their speciality. I often notice that people who thought that everyone sticking to their speciality counts as a team. This is far from the truth.

Consequently, one or more team members can become a bottleneck, e.g. this can be a person who specialises in testing, a backend developer who has problems to finish a service and anyone else.

Bottlenecks during the Sprint
Bottlenecks during the Sprint

To continue with the football metaphor: If a defender is standing 2m from the goal and in possession of the ball, he won’t say “no, I am just defending, I don’t shoot goals”. The forward player won’t say “I have to shoot the goal”, even if he doesn’t have a free line of fire. He will probably pass the ball to another player in a better position. The same counts for the team. The team members, of course, have their areas of expertise. However, in addition, they have knowledge and expertise in other areas or they can or want to extend their knowledge in other areas (aka T-Shape), e.g. a Java Developer will also be able to help with any other programming language or even testing, a CSS expert might want to learn how to use JavaScript and others. So if a bottleneck or any other problem occurs the whole team helps to remove it. You can experience these benefits by playing Consonants and Vowels.

Daily Standup is seen as a Status Meeting

A Daily (Standup) is not a status meeting. It is a meeting where the team members align their (game strategy). Probably this can best be seen in Amercian Football when the team gets closely together to discuss the next move. So please avoid using the Daily Scrum solely as a status meeting.

What the Daily Standup Meeting is About
What the Daily Standup Meeting is About

For this reason, I encourage teams to hold a standup each day with the task (or storyboard) as the base. For the reasons above, the whole team should be present, if not physically at one place, at least in a video or phone conference. Of course, not all problems can be solved during the Daily Standup. Some problems might have to be more thoroughly analysed and solved during a Retrospective.

Resume

To successfully finish a Sprint, the Development Team has to recognise that they are a team, i.e. a bunch of people whose common goal is to finish as many user stories as possible. Everyone in the team helps the others out, everyone can ask for help if necessary. The alignment of the strategy happens in the Daily Standup. It might take some time (a couple of Sprints) before this happens and it might happen again and again in later stages. As a coach, I suggest to let the team find out by themselves and just push them a little every here and then. 

How a Sprint should look like
How a Sprint should look like

 

 

References

Images

Sport vector (the footballs) created by Rocketpixel – Freepik.com

Background vector (the football players) created by Brgfx – Freepik.com

Business vector (the business woman) created by Freepik

 

Chris

Chris

Agile Practitioner, Trainer, Coach at vividbreeze consulting
Since the late 1990s Chris has been working in different projects for major national and international corporations, small businesses and start-ups, advising companies in areas from software architecture to project management. Chris has been part, led or coached project teams of different sizes. His field of expertise encompasses agile project management, business and requirements analysis as well as technical analysis, design and implementation.
Chris