An agile team is supposed to size user stories and take up a fixed number of points every sprint and complete them. This is called a team’s velocity.This velocity is supposed to help the management guess the amount of functionality that can be delivered in a given time frame. Unfortunately, many teams are unable to deliver consistent velocity due to various factors.
Some of the factors that are often talked about are overloading of the sprint, blocked user stories because of dependencies on other teams, technical limitations, etc.
I was thinking about how to get teams to deliver consistently when I remembered a statement made by Peter Deemer, our trainer during the scrum master training. He said ” scrum/agile is hard, because it brings out problems that are already existing in the teams. Most of the problems are not related to agile processes, but pre-existing problems that have now been highlighted because of agile process ”
I believe ,for a team to deliver consistently, a certain set of roles need to be performed by the team members. These roles may be performed by one or many people and many roles can be performed by one person. These roles are -
- ‘Overview’er - This role is performed by the person who knows the product/project at a high level. He understands how things are inter-dependant and is aware of functionality being developed by other teams. Usually, an experienced person who has worked on the same product for several years would be able to do this role
- Problem-solver - This person can solve any technical/logical problems a team faces. This is the person the rest of the team goes to when they hit a roadblock, trying to thrash out possible alternatives to the original plan.
- Technical ‘guru’ - This person knows the technical aspects of a product like its design & architecture thoroughly.
- The ‘Go getter’ - This person gets any information required for the completion of a user story. Most often this information is available with other agile teams
How do these roles help a team achieve consistent velocity?
The overviewer comes into the picture at the time of release planning or sprint planning. Since he has the over all picture of how things are, he can identify dependencies and tell the product owner to schedule the user stories accordingly. He also comes into picture when a user story is blocked due to technical difficulties. If similar functionality has been implemented by another team/product, this person could guide the team to get information from them.
A problem solver comes into the picture when things don’t go according to the plan. Many teams that lack this role will be unable to proceed and block this user story. They would then create a technical spike to investigate and find an alternative solution to the problem. However a team that has this person can thrash out a solution/alternative very fast and get the user story unblocked. A problem solver is usually a very good at analysing and coming to logical conclusions.
A technical guru would help find dependant testing scenarios. He would also help out in splitting user stories into smaller ones since he can think of the code behind each functionality when others are just discussing functionality. Many people confuse the technical guru with a problem solver, but I believe these are two separate roles. One requires technical knowledge, while other requires logical reasoning.
The go-getter is helpful in retrieving information from other teams in time to complete a user story. This person is good at explaining the context and the exact information required in a single mail. This usually saves time in case of cross geographical teams( like vancouver and Bangalore).
What do you think of my roles? Do you think there are any other roles that I have missed?
If your team is not delivering consistently, can you identify which roles are missing in the team?