The rate of organizations moving from waterfall to Agile software development practices is staggering! Scrum being the most popular Agile framework, development teams are suddenly being ask to commit to delivering a specific amount of functionality every 2 to 4 weeks. The pressure is immense and committing to something in software development, even for a short period, is risky at best. But Scrum was clear – the team has to commit at the beginning of a Sprint and many used this as the perfect tool to reward, punish and evaluate. Pressure is good. Too much pressure and the whole thing falls apart.
Well a lot people will be going though a rough withdrawal period because in the latest Scrum Guide, team commitment has been replaced with…team forecasting.
Is commitment dead?
The concept of commitment as been used and abused by management, ScrumMasters and even Agile coaches. I should know! I’m one of them! I figured that by making the burndown highly visible and holding team members accountable to their Sprint planning commitment, that somehow it would get done. Worked for me when I was a developer! Oh ya…I also worked nights and week-ends to get it done. This didn’t only mess up the team’s true velocity but I also wasn’t necessarily getting better at what I do.
Asking the team for a guaranteed functionality delivery commitment for a Sprint isn’t only futile but it can also be harmful to a team’s continuous improvement initiatives.
So is commitment dead? Its misguided use might be coming to an end but the team still needs to commit, engage and take responsibility. It’ll simply be used for what it was intended to in the first place – that is committing to something deeper and more meaningful.
So what can the team commit to? Here’s a hint : At the end of a Sprint Planning meeting, focus away from the specific Stories and tasks and ask the team if they can commit to being Agile!
Can the team commit to…
- Satisfying the customer with the delivery of valuable software by the end of the Sprint?
- Working with the business people a daily basis?
- Dropping emails and communicate through face-to-face conversation?
- Working at a sustainable pace?
- Continuously pay attention to technical excellence and good design?
- Maximizing the amount of work not done?
- Inspecting and adapting?
I believe (not so naively) that if a team commits to applying Agile practices rather then to delivering specific functionalities, good things will happen. By committing to bettering their practices, teams will have no choice but to increase their velocity…It’ll just happen! Somehow I think that’s what the co-creators of Scrum had in mind.
The heartbeat
Development teams need to remember that they are not alone when delivering the next best thing in software. They are surrounded by other teams such as marketing, finance, sales and operations. And there’s this other group called clients and they are impatiently waiting for our clockwork delivery of cool features and bug fixes.
Let’s not misuse the word “forecast” and allow organizations to float the other end of the irresponsibility spectrum. During early iterations (more or less Sprints 1 to 4), forecasting can be used in its purest form and teams can offer a “we’ll do our best” estimate. As a Scrum team, we just don’t know what’s gonna happen! But as we move ahead into later sprints, we, as a professional team of experts, need to learn from those early sprints and start expecting the unexpected. Without actually knowing what will happen, we now know that it probably will. We need to start offering our stakeholders some good information through RELIABLE sprint forecasts. We are not the local plaid suit weather forecasters. We are serious forecasters where getting it wrong can lead to dyer consequences. We need to create that reliable heartbeat of high quality product delivery. Only then can our multi-team (development, marketing, sales, communications, finance) initiative effectively and efficiently plan for the future. Notice I didn’t specify Product Owner. The reason is simple: The Product Owner is part of the team and equally responsible, albeit at another level, in creating reliable forecasts.
Good days ahead!
By replacing “commitment” with “forecast”, management and ScrumMasters can no longer (in theory) rely on the blunt tool of pushing teams to reach that infamous 0 on the burndown chart. Hopefully that simple replacement will bring about a mind shift where Scrum practitioners will now focus their energy on deeper team and organizational issues, such as team dynamics, reducing waste and getting upper management buy-in. As for teams, they will continue to deliver great software all the while committing to perfecting their Agile practices.