The following post is from our guest editor Srinivas Chillara. Srinivas is a Scrum coach and co-author of “Essentials of Scrum practice“- a mini-book currently in advanced draft stage. This is an extract from the book.
The hidden hobbler of Scrum teams: Pressure
One common problem Scrum teams face is in the difficulty of meeting their sprint goals, followed by increasing pressure, which is never-ending. Such teams don’t see sustained significant improvement and can quickly fall into a death march mode, or a jaded plodding with longer hours but no end in sight. Such situations are due their choosing sprint goals (targets) under duress in some form. The ill effects of such commitments are not easy to understand or link to the cause. Team requires to make a fair shot at making an independent commitment for their sprint, after all they are the ones who do the work. Mainly managements are worried that the teams will under commit. Software development is very commonly done under pressure, and this makes it seem as though this is very normal, and possibly the only way to work. A good anti-dote to such thinking can be found within Tom DeMarco’s “Slack”.
What do we do when the pressure to finish is so much, that there is no choice left to the team.
Don’t buckle under pressure, and stick to the Scrum principle, however this is much easier said than done. Many projects have deadlines in some form, based on a marketing wish or executive fiat. Since organisations need to make plans, what upper management wishes for, may be necessary. Trouble is created when this wish is widely out of line with reality. What organisations do poorly, is handle the difference between an original high level plan (based on executive wish or even a high level estimate) and the reality as the devil in the details appear. The Scrum approach is to do planning in small bits (2 weeks) and improve continuously by ‘inspect and adapt’. In the experience of authors, far too many projects are worried about the success of any given sprint and don’t give a chance for the team to learn and improve. A difference is made if a couple of steps were to be taken before the sprint starts:
1. Get an agreement from management that the team be free to choose the extent of work they commit to; offer to be transparent regarding why such a choice is made.
Essentially this means that the details of the sprint planning meeting is made available to the larger organisation. Management also needs to support the Scrum Master in his/her task of protecting the team from any external pressure. Now the Scrum Masters job is easier, if he/she also provides transparency into the Sprint Planning Meeting, by highlighting significant events in a MOM, as well as, circulating the sprint backlog/plan itself after the meeting. Normally the sprint backlog, with estimated hours for each task totalled and compared with available time, will give a realistic view of what is within the realm of possibility for the team to take up.
2. Explain the distinction between a real commitment that the team makes, believes in as well as is serious about and a perfunctory one made under duress.
Pressure to finish fast exists in most organisations. However, better the protection a team can be provided, to demonstrate to the team that their honest views are truly valued, better the commitment from the team and the teams attempt to meet this commitment. Fair and transparent planning will mean that team will not knowingly under-commit. Once a true commitment is in place the team, they should be supported by the Scrum Master and the management will do all in their power to meet the sprint goals. An unrealistic deadline imposed may make the team work harder, but they are unlikely to learn and also this will not be sustainable. What the Scrum Master and the management can do is replace pressure with motivation. Any pressure must only be peer pressure, generated naturally, not imposed from higher up.
Finally, if after all this discussion we still have a situation where pressure cannot be held off, either due to the unwillingness of people to be open, or the unwillingness of management (briefly glossing over the fact that management also consists of people) to accept bad news, then the Scrum master must present the actual versus the hoped for amount of functionality delivered after the sprint in a neutral communication as a means for the organisation to learn. Many organisations take time to learn so this can be a long drawn out process. Remember Scrum Masters can do this easily, if they are not directly responsible for the success of any and every given sprint, which is typically the case with a project lead. It is well worth noting that a ScrumMaster is not a new glorified label project lead, but an enabler and protector of a team which is responsible for delivery.
What you say about pressure and the perceived under-commitment is true. Even though the team is at a liberty to chose the tasks and give a time estimate in a sprint, there are 2 main pressures that makes a member take on more than he can chew. The first pressure is peer pressure, if member A has taken up tasks worth 20 points then member B should match up or exceed him, so that he can have a good impression on his lead/manager. The other pressure is the sprint goal, if the number of tasks in the sprint are unrealistic then the team cannot confront the PO in the sprint planning meeting to reduce the number of tasks (though this is better than unfinished tasks at the end of the sprint).