It is always hot topic while discussing project management approaches. I want to review this issue from Agile/Scrum perspective and my own experience.
If you are familiar with Scrum, its essence is:
- The Team is given clear goals
- The Team organises itself around the work
- The Team regularly delivers the most valuable features
- The Team receives feedback from people outside it
- The Team reflects on its way of working in order to improve
- The entire organisation has visibility into the Team’s progress
- The Team and management honestly communicate about progress and risks
This way of working is based upon values of self-respect, respect for others, trust and courage and Scrum Master is responsible to make sure that the Team accepts and applies these values.
So, as you can see close Team’s and Scrum Master’s collaboration is very important in order for the Team to meet its commitments.
I made following important from my point of view notes for myself during Scrum adoption and apply/highlight them during each Sprint Planning or Sprint Retrospective session:
Keep the sprint scope clear and understandable for everyone: each Team member, Scrum Master, Product owner
Scrum Master must ensure that after Sprint planning meeting everyone leaves the room (or any other place) with clear vision and understanding of what needs to be done at the end of the sprint. There must be no surprises to anyone in the middle of the sprint or what is worse during sprint review. Each team member must understand following things: what features will be implemented, how they will be implemented, what modules/projects will be affected, how they will be tested and what are acceptance criteria’s. (You can read more about Sprint planning here)
Avoid ambiguities
All ambiguous requirements should be avoided from Sprint backlog, since as my experience shows it always leads to undone work and commitments failures. And this results to reduced team’s morale. The Team must identify such features/stories. Ambiguous requirements can be handled two ways: include it to sprint as optional task for additional technical analysis; such requirements are good candidates for Backlog Grooming/Estimation meeting. Both decisions must be communicated clearly among all interested parties. (You can read more about Backlog Grooming meeting here)
Commit to the “right” amount of work
Getting the commitments right is a learning process for the Team. The Team members need to learn that they have committed not only to scope by the end of the sprint, but also to quality (expressed through the definition of done), and that quality has precedence. Sometimes it is useful to categorize stories as ‘Committed’ or ‘Conditional’. The latter are generally smaller stories which have been authorized by the Product Owner and which the Team might complete if time permits.
If a committed story is not finished, then the Team and Product Owner discuss the situation during the Sprint Demo. Conditionals are a bonus. If the Team can finish one or more, that’s great, but there is no expectation that they will be completed by the end of the Sprint. From the perspective of expectation management, it is important to consistently deliver all ‘Committed’ stories, preferably with a ‘Conditional’ or two. Better to slightly under-commit and slightly over-deliver than the other way around.
Keep the scope fixed through the sprint
The Team and Product Owner must “freeze” scope for the specific sprint. Scope “freeze” can be formalized or verbal (it depends on situation), but it is Scrum Master’s responsibility to make sure that scope is not changed or additional work is not introduced during the sprint. Also I admit that trade off’s between planned features/stories and new features/stories are possible, but don’t use it very often, these must be exceptional situations – keep the scope freezed!
Keep the Team’s focus on sprint goals
Sometimes team members tend to lose focus from sprint goals due to different reasons: spend too much time on looking for the best technical solution, stuck with technical difficulties, consulting other team members and etc. It is not a problem that these things happen during the sprint, but sometimes teams try to use these as excuses during failure. Scrum Master must track such things during daily stand up meetings and make sure that focus is kept on sprint goals. (You can read more about daily stand up meetings here)
Keep the Team’s focus on quality and other non-functional requirements
Scrum Master must always remind the Team, that goal is not only to deliver desired functionality, but provide results with good quality and compliant with other non-functional requirements. Developers tend to forget about testing and results verification.
Always introduce automation if applicable
It is hard to believe but there is always a lot of room for automation: testing, builds, data preparation other activities. Automation helps to save a lot of time and focus on more important tasks. New Teams will always tell you that it is not possible, do not believe them – it is not true. Automation is possible and worth; it only depends on how much time you plan to invest into it. If Team is “afraid” of automation there is one rule that worked for me – start from easiest/the most obvious thing to automate (attract “automation experts” from other teams if possible), and after the Team sees the value of this automation they will always find ways how to automate other things by themselves.
Feel personal responsibility
Who is responsible for a story/feature implementation? Should it be whole Team or a particular person in the Team as well? Fundamentally, the Team commits to the story, but I prefer to have one team member take responsibility for each feature/story. This team member feels responsible for it and will probably demo it at the Sprint Demo, so s/he makes sure that it works its way through the process from accepted to done. This decision of course depends on culture, but sometimes there is a situation - if everyone is responsible, and then no one is responsible. But in any case each team member must feel personal responsibility for results.
Learn, inspect and adapt!