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.
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.
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.
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.
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.
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.