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.
The exercise
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.
Something to try
If you're struggling with a team that's unwilling to learn modern technical practices or management that's unwilling to give time to invest, take a long look at this exercise. The detailed rules are available in slides 21-23 in Scrum Plus Extreme Programming (XP) for Hyper Productivity. Run it with a few friends to get the kinks out, then propose it at a department staff meeting. Like Ron, explain the methods to appeal to verbal learners, then provide the diagrams to help the visual and the exercises to reach the people who learn by doing.
After the exercise, try to come up with one small experiment to run with one team or one project. Decide on something to invest and a timebox that gives people enough time to learn something new—perhaps a month—knowing it will cause a slowdown at first. After the month is up, meet and propose the next thing.
And be prepared to have an exercise the second time—people will come to expect it.
For the final third of his talk, Ron returned to the consequences of scrum without technical excellence.
A little more on debt
After we saw the power of pressure, we were able to discuss what it looks like in the organization. People take shortcuts: they cut and paste code and create massive objects that do too many things. When it's time to modify the code, a small change in one place can lead to unanticipated behaviors. Exploratory testing and setup take longer and are necessary, because a change over here could break something over there.
In short, quality suffers.
Ron reminds us of what he had mentioned earlier: no one cares about quality. The costs are invisible. Yet, just like the team members trying to run around chairs, technical debt causes progress to grind to a halt. His big lesson: a "drive for results" without attention to quality "works" until it doesn't, when suddenly it's difficult and expensive to make progress.
In another example, Ron drew from the children's toy, Etch-a-Sketch. Drawing something on Etch-a-Sketch is simple enough—the trouble is with extending objects. With no "erase" button, the author has to either leave their drawings with errors, fill them in with black, or start over. As an alternative, Ron suggests that teams learn to develop code as craft and points to a set of techniques designed to make code malleable over time and releasable quickly.
Ron goes on to provide some guidance to teams starting with technical practices:
- Build slack into the sprint. Reduce velocity by 20 percent and start
- Study books such as The Art of Agile by James Shore
- Get an XP coach, as this can compress the journey to high-functioning in six months.
Take the next step
Reading the concept is one thing; experiencing it is another. So check out the full rules to Ron's Scrum Gauntlet of Debt in the slides to the presentation, available free online. Run the exercise with your team, then gather together to discuss what to do next. Ron suggests bringing in a technical coach to reduce the time to Hyper-Productive. Teams without budget might consider a book club; Andrew Stallman's Learning Agile is a modern take that covers Scrum, Kanban, and Extreme Programming. If you'd looking for how to adopt these ideas on teams of teams, you might want to look into Ron's scaling method, fast-agile, which involves the use of open space, technical people signing up for work, and incredibly tight timeboxes.
Today we've taken you through the theory and told the story. The next step is up to you.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
