Our Stories Aren’t Getting Done: Taking on More Than Possible

One of the classic issues that pop up when teams chronically don’t complete work they say they will, in the time they say they will is that they are taking too much work at once. Being somewhat hyperbolic, I liken it to eating a very large hamburger (for example) in one bite. Even if it is possible to shove the whole thing in, it would be painful to swallow. I have facilitated more than a few retrospectives that discussed taking on more work than is completable in a specific timebox. Several of the reasons that generally surface:

• The team does not make its own commitments.  In this case, someone else commits for the team and their job is to just do it. This is commonly seen coupled with a command and control leadership structure.  I also see this problem linked to “sell first and figure it out later” cultures. Teams that are not allowed to manage their own commitments CAN NOT BE AGILE.Potential Solutions: The organisation has to decide whether they really want to be agile or just want to use some of the techniques and practices. Assuming a desire to be agile, they must empower the teams to use approaches like yesterday’s weather, velocity (not my favourite), and throughput accounting to determine how much they can accept in any timebox.  Another approach is to use kanban or Scrumban and only pull work into the team when there is capacity.

• The 110% commit. Somewhere someone is teaching project managers and pseudo-Scrum Masters that they should “facilitate” getting their teams to commit to 110% (or more) of what they do. I have heard this described as a rolling stretch goal.  This a variant of someone else making commitments for a team. A team can occasionally stretch, but like any machine running beyond its means, it is a prescription for burnout and turnover. This fails the agile principle of a sustainable pace.Potential Solution:  Adopt yesterday’s weather and throughput accounting approaches to plan how much work to commit to accomplishing. Exhorting team(s) to work hard (this is what the 110% commit is saying), look at how the work is being staffed and funded and get the right number of people involved.

• A “yes” culture. In many organisations saying yes is equated to being a team player; one of those attributes we all covet at year-end reviews. Also, Anthony Mersino, a friend and colleague, points out that saying yes is a pain deferral strategy. All of which leads to the conclusion that it is easier to say yes and deal with potential negative consequences later when they will be easier to rationalise away.Potential Solution: Learn how to measure and show the impact of saying yes to everything on predictability and quality. Use your found measurement acumen to support gently saying no. Controlling what you say yes to will increase team (or organisation) delivery performance. In most circumstances, judiciously saying no yields more value to the organisation.

 

• Poor planning and its first cousin the “panic” culture. Planning is a core competency in all agile approaches. For example, Scrum has work refinement, daily Scrum, and sprint planning exercises. Another example, SAFe uses all the Scrum practices and adds several more planning events for Program Increments. No approach to business, whether agile, lean, or classic starts with the idea that we will wing work. Winging it often leads to panic as new work, demands, and things that go bump in the night appear out of nowhere screaming to be taken care of NOW.  Note: winging it and panic often create a hero culture that is addictive.

Potential Solution: Like all cultural issues, solving this at the team level will be difficult. That said, begin by celebrating calm. Educate stakeholders and product owners on how to increase their         planning horizon. Make sure you are using planning and refinement exercises (get coaching help). At an organisation level, start by educating leaders that even though heroes are great, they           can get a lot more done using that same ingenuity to solve problems before they happen.

Teams taking on more work than they can get done is a reflection of more serious issues. If an organisation has this problem chronically, at the crux of the issue is the question of whether they want to be agile or say they do agile. It’s a mindset thing and requires decisions that have significant consequences on how you approach people and work.

 

About the Author

Thomas Cagley has more than 20 years of experience in the software industry, serving as a consultant since 1997. He was previously the Metrics Practice Manager at Software Productivity Research. Earlier, he held technical and managerial positions in different industries as a leader in software methods and metrics and QA. Thomas is a frequent speaker at metrics, quality and project management conferences. His areas of expertise encompass management experience in a wide variety of methods and metrics: Lean software development, Agile software development, quality integration, quality assurance and the application of the CMMI Institute’s Capability Maturity Model® Integration (CMMI) to achieve process improvements. Thomas blogs and podcasts on all things Agile at his blog: Software Process and Measurement.