Getting to Done

My book Scrum: The Art of Doing Twice the Work in Half the Time was published in October. Over the last six weeks, I’ve been touring the U.S. and Europe telling the story of all the influences that culminated in the creation of the first Scrum team over 20 years ago. No matter where I go, people ask me what the secret is to running a good Scrum. The secret sauce of running a great Scrum Team is Getting to Done!

Bad Agile

There is a lot of “bad agile” out there. According to Jim Johnson at the Standish group, 49 percent of Agile projects fail. Why? Because people don’t grasp the essence of what it means to be Agile. It requires a fundamental shift in thinking. The second value of the Agile Manifesto is quite clear: Working software over comprehensive documentation. That means that at the end of every Sprint you have potentially shippable increments that work!

Working software is key because it is the catalyst for one of the most important aspects of the Scrum Framework: feedback. If you don’t have working software at the end of the sprint, stakeholders can’t use it during the Sprint Review and, as a result, can’t give the Product Owner and team the feedback that will allow the team to develop the product into the customer’s sweet spot.

The secret to working software is complete testing inside the Sprint. If your testing practices aren’t tip-top, your teams are probably struggling, your customers are probably frustrated, and you most likely don’t know when the product will ship.

Five causes of team failures

1. Poor definition of DONE
2. Stories not READY
3. Dysfunctional Leadership,
4. Technical Debt
5. Ineffective coaching

• A rigorous definition of Done includes working tested product at the end of the Sprint. Teams must work together to refine their definitions of Done. Product Owners have to stop accepting Stories that don’t meet these criteria.

• Good definitions of Ready and Done are two levers that produce successful Sprints. Stories don’t magically become Ready, they need to be clarified and granulated. Acceptance tests need to be embedded. This takes time and attention from the Team.

• A leadership team that sees the benefits of going Agile, but hasn’t engaged enough to shift its mindset is a recipe for disaster. Scrum works because it allows capable workers to self-organize and determine how best to accomplish their goals. If management maintains a command-and-control mindset, a Scrum implementation will fail. In an Agile context, managers become Leaders. They are tasked with setting transcendent goals for the organization, supporting the Teams and removing organizational impediments. They need to determine what Scrum metrics would best bring transparency to the processes so they can hold the Product Owners responsible for value delivery and Scrum Masters responsible for velocity.

• Technical Debt needs to be stopped in its tracks. The discipline of having clean code every day is essential as is completing all testing within the Sprint. Then the historic technical debt can be reduced piece by piece

• When implementing an organizational change, companies are pretty good about educating their employees but they fail to provide them with support they need to succeed. The most successful implementations not only get their workers trained but also bring in outside help to launch the teams. A team launch includes an expert coach who helps develop the first iteration of the Product Backlog, helps the teams define what it means for a story to be both ready and done, and leads them through all the Scrum ceremonies at least once. Ideally, the coach returns periodically to fine-tune the teams’ work and take them to the next level.

Systematically focusing on remediating these issues will consistently produce high performing teams with 200-400% improvement in production.

Failure to focus on them will add yet another team to the 49% of teams that are “Bad Agile” leading to unhappy customers, lost revenue, and lower stock prices.

-- Jeff Sutherland