A common refrain I hear from management in organizations transitioning to agile is, “if the teams are self-directed and get to choose how much work they do, how can i be sure they are working hard enough?” Or in other words, how do we hold teams accountable? Traditional projects fix the schedule and the scope of work and use that to hold teams accountable. If the team doesn’t deliver the predetermined scope in the stated time box then they have failed. Even projects that claim to be agile do this. They do this by hiding traditional fixed scope practices behind agile concepts and phrases like “sprints”, “acceptance criteria”, and “commitment”. Even worse they will try to boil all of the complexity of software development down to a single number, a “velocity”, measured in story points, and try to hold the team to that number. Do you find your teams lawyering acceptance criteria at the end of the sprint, trying to “prove” that they met them so that they can take credit for the story points? How well do these discussions go? If this sounds like you then your project is probably falling into this trap.
For software projects there are many techniques, such as Behavior Driven Development, that can alleviate the lawyering and help teams agree that the work was done correctly. In this post, however, I want to address the higher-level problem of using story points and velocity for accountability in the first place. Measuring accountability in this way is deceptively simple. The team committed to 50 points and completed 47, therefore they “missed their commitment”. Organizations will often use this “missed commitment” as proof that the team is not performing or they may reward the team that reliably exceeds their commitment. However, remember that points are nothing more than an estimate and are ultimately just a proxy for the actual work completed and value delivered. And not always an accurate one at that. A team could deliver a ton of value without fully delivering all their points. Likewise, a team can complete all their points and that doesn’t mean they actually delivered anything of value. Why force teams to commit to something that doesn’t tell us anything about what we actually care about?
So if velocity isn’t appropriate for measuring commitment, how can teams be held accountable for doing an appropriate amount of work? The Agile Manifesto provides answers. In this case we focus on a few of the 12 agile principles.
The first appropriate principle is “Build projects around motivated individuals … and trust them to get the job done.” If we can’t trust our people then we have bigger problems that story points sure aren’t going to solve. Hire good people and, absent clear reason to do otherwise, trust them to do good work. If they say the amount of work is reasonable, believe them. If they say they need help, get it for them. Also, keep the lines of communication open. Active and consistent communication with the teams will make it obvious if a team is “sandbagging.” Not to mention, I’ve never seen a team “sandbag” when management listens to them, gives them what they need, and gets out of their way.
The second appropriate principle is, “Our highest priority is to satisfy the customer through … delivery of valuable software.” Instead of concentrating solely on velocity, have teams focus on what is valuable to the customer. Have them define sprint goals in terms of what customer outcomes they expect and what value they intend to deliver. This does two things. First, it states the commitment explicitly in business terms that everyone can understand. Second, it frees the team up to be flexible with how they treat stories that don’t end up contributing to the objective. Ultimately its the value that matters, not the stories. This may not be as easy as looking at story points. But nobody ever said agile was easy! Now, regardless of the points or stories a team ultimately completes, they are accountable for tangible outcomes that are clearly recognizable, and valuable, to the business. Also, teams are free to use points and velocity as they were intended and in a way that means something to them — as an internal, team-facing check to ensure the goals they set are “right-sized”, given the teams history.
What are your thoughts? How do you hold teams accountable in a way that builds trust and ensures delivery of customer value? Add your comments below.
