Optimized Scrum: Getting to Done Done Done Done

At my last company we delivered production software to multiple large enterprises at the end of every sprint. Within two years we dominated all competitors. Our CEO said he didn't understand why we couldn't get Done (feature testing), Done (integration testing), Done (performance testing), and Done (user acceptance testing) by the end of every sprint . Only then could he collect revenue from customers.

The Scrum teams told him it was impossible and then self-organized to achieve it with the CEO aggressively removing all impediments (including management when necessary). By the time they achieved this they were benchmarked at 10 times the velocity of our outsourced Indian waterfall teams. The revenue for the company quadrupled in one year.

Why can't Scrum teams get shippable code at the end of a sprint?

The biggest problem worldwide for Scrum teams is getting shippable code at the end of every sprint. That was the goal of the first Scrum team in 1993 and they delivered it for every sprint, including the first sprint. Yet over 50% of Scrum teams cannot do this worldwide and this slows them down by somewhere between 2 and 24 times depending on the complexity of their application.

I have found a solution to this. Scrum Inc and our partner qaSignature have teamed up to offer a way to ensure that full regression testing is completed every day of the sprint so getting to done at the end of the sprint is guaranteed. We are working with a local software product company that has increased their ability to release product by a factor of 6 just using the regression testing capability. The CEO of this company will be coming to our Scrum class in Cambridge to plan for deployment of Scrum to double this initial gain to a factor of 12.

Call us about an “Optimized Scrum” course focused on implementing QA during sprints beyond unit and functionality tests, unclogging software development’s biggest bottleneck. We will discuss complete daily automated regression testing independent of application size or number of products in a portfolio.