As I entered the room for Ron Quartel’s Agile 2015 talk on combining scrum with technical practices for hyper productivity, I sensed a certain energy and urgency. The session drew a diverse crowd. They wanted to hear Ron’s answer to how to deal with a rift so large that it split even the conference world in the Software Craftsmanship events and the Agile Events. It didn’t take long for Ron to get started.
Ron set the stage by quoting experts on the importance of technical excellence. For example, Dr. Jeff Sutherland, a co-creator of scrum, said that few scrum implementations reach a true hyper-productive state (500 percent to 1,000 percent normal team performance), and those that do reach it have implemented variations of Extreme Programming.
Extreme Programming (XP) involves hard technical practices, including test driven development, refactoring, pair programming, and continuous integration. These practices change the way the work is done and can take months to learn and develop expertise. Scrum, on the other hand, changes the way the work is organized and managed; organizations can adopt scrum in a few days.
The result, according to Quartel, is that organizations choose the quick and easy way over the hard and disciplined way. Ron went on to show survey results from VersionOne’s State of Agile Survey and Scrum Alliance’s State of Scrum Report, which both show overwhelming adoption of scrum, between 50 percent and 90 percent, with less than one percent of organizations doing actual Extreme Programming.
Then Ron dropped the bomb.
Reality: Companies don’t care about increasing quality
Pointing out that after years of preaching quality and seeing it fall on deaf ears, Ron switched to talking about speed and increased velocity. In his words “Suddenly the same companies were all ears.” Ron suggests that this explains why DevOps and continuous delivery are darling terms in the industry: they promise to deliver software faster and more frequently.
That’s a problem, because practices like Extreme Programming require an up-front investment. When you add pair programming, the technical practices look like they’ll slow development down by 50 percent. Learning test driven development and setting up continuous integration mean the team will go slower than 50 percent. Plus we already know that quality, which is intangible and invisible, doesn’t sell.
Talking in terms of investment—in numbers and spreadsheets—might help, but the psychological barrier of a 50 percent drop in speed is too much for management to bear. Ron suggests that you need something to allow people to feel the pain, and he has just the exercise for it: the Scrum Gauntlet of Debt.
Picking seven volunteers, Ron began with two roles: developers and testers. Developers outnumbered testers five to two. Stickies on one wall represented to-do work. Developers moved the stickies from development to test, and the testers moved them from test to done, all in a brief timebox, about two minutes. Playing the role of manager, Ron exhorted the participants to get more done, because, after all, what management wants is velocity.
After the round, Ron dragged a few chairs to stand in the way, representing technical debt that has to be worked around. After a brief warning about safety, Ron began the next round, imploring the teams to go faster. The temperature in the room rose, people began to feel the pressure, and yes, performance went up.
For a while.
Over time, as Ron added more chairs, performance declined.
Then Ron changed the rules, simulating the technical practices. Because the programmers were investing, they had to stop running, walk at a sustainable pace, and remove one chair per two-minute sprint. Over time, performance went back up.
After a round or two under the new style, Ron broke the exercise and showed on a spreadsheet what the two styles do to performance over time. The first “hard driving” style has an immediate payoff: people under pressure do perform, but the long-term impact is a slow decline in speed as the team takes on debt. Meanwhile, teams that have the tools to remove debt (the technical practices) at a sustainable pace move faster over a long period.
The math Ron revealed may be simple, but it makes a point. Over time, managers get both velocity and happier teams with the technical practices. At the same time, they have an exercise that allows them to see and feel what it’s like to be a team pushed constantly for velocity—it doesn’t feel good.