If your team uses Scrum as a development process, the team decides which of the next most important items it can complete by the end of the iteration. However, this “commitment” is often used to hold the team accountable for the amount of work that will be shipped by the end of the sprint. Holding your team accountable for failing to deliver on their engagements is counterproductive and will act as a regime of terror. This is no small issue, and Scrum now suggests using the word forecast instead of commitment.
Commitments can be abused by management as a way of holding the team accountable. Typically, the manager or even stakeholders will say that they made engagements (i.e., announced a detailed release) based on what the team said they could deliver. They usually fix this situation by asking the team to work overtime in order to deliver on their own promises.
Yes, the goal is to burn down until you reach 0, but not at any price. If developers fear that they won’t make it by the end of this iteration and you made it clear that they promised to finish, you are basically forcing them to cut down on quality.
Every time you make a deadline because your team worked overtime, don’t be too quick to celebrate. The work they did on overtime may very well be of lower quality. After all, they were not as fresh-minded as they should’ve been.
Making your team work overtime is paying your debts with their health and the quality of your product. Those two things also happen to be the main things actually delivering value and making money to your company.
After a rush, the normal reaction will be to sit back and relax. If you want your process, your work output, and your project to be predictable, this is the last thing you want. Your team’s velocity will be inconsistent from one iteration to the next and inconsistent velocity leads to unpredictability.
No matter the problem, when the discussion is aimed at finding a person to blame, it’s better to not even have that discussion. Instead of trying to find the who, we should always be focused on the why we want to objectively find solutions.
If management uses those engagements in order to blame the team—or worse, a specific person—not only does it nurture fear for their next iteration planning, but it also fails to solve the real problem(s).
Either way, whether the commitment concept is abused by management or by the developers themselves, the usual victim is product quality, as Ken Schwaber himself has repeatedly pointed out.
The team is responsible for building great software—that’s it. It’s the only thing the team is responsible for and it’s the only thing that they actually control. In other words, the development team is committed to quality software.
The commitment aspect of iterations is just there to focus the team on the next most important set of functionalities. Holding them accountable on their shortcomings is leading by fear.
In the end, a manager who abuses his team’s engagements against it is inadvertently lowering the quality standards of the product as whole.
Yes, it’s fine to deliver on time, but not at all costs.
Contributor: Emanuel Petre
Emanuel is the cofounder of Insight, an Agile dashboard for Pivotal Tracker. He is an engineer with a passion for technology and innovation in general. Outside of work, you can find him spending time with his girlfriend and kids. He also enjoys swimming and reading.
Category: Productivity Community
