This Tuesday I got to know him as the “man on center stage” for the Software Test Professionals Conference – and also as a context-driven thinker.
Beck began his talk by telling us about the arguments of his youth — how one side would say that practice X was essential for success in software development, while a second would say the same practice was a recipe for disaster. He pointed out that, in his experience, the arguments never seemed to go anywhere, they just ended in hard feelings.
Next Beck wondered aloud: Is it possible that both of those people are wrong? Is it possible that they are both right? Or perhaps they are both right — for two entirely different contexts.
While many different things can change the context for a development team, Beck chose to focus on one thing for his talk: The speed of the deployment cycle. He showed us a very informal graph of projects in the 1990’s with rough percentages of project cycle-times. The main cycle times he selected were projects that took a year or more to ship to production, those that deployed quarterly, monthly, weekly, daily and even many times a day. He also showed what project release schedules look like today and a comparison between the two.
The overall conclusion: Project teams today are shipping more often.
His proposal: Changing the deployment cycle causes social, technical, organizational, and business changes. These changes mean the practices the team will need to use in order to be successful will also change.
For example, these are some of the changes Beck suggested teams make when accelerating release schedules.
From annual releases to quarterly:
– Automate acceptance tests
– Institutionalize refactoring as an everyday, continuous practice
– Continuous integration
– Subscription (don’t charge for upgrades, buy support)
From quarterly releases to monthly:
– Developer testing (developers have to stop making so many bugs)
– Stand-up meetings
– Cards on a wall
– Pay per use business model
From monthly to weekly:
– Live, two-way data migration (rollback, make it safe and cheap.)
– Defect zero (another good example of context matters. Great idea for tight releases, crazy idea for long release cycles)
– Temporary branches
– Bootstrap financing
In addition to adding features, Beck suggested taking some practices away, such as large organizational barriers between development, test and operations. He also suggested that traditional paperwork heavy processes, like formal change control or design documents, become less valuable as deployments shift toward daily or even more frequent builds. (At the daily level, he suggests getting rid of standup meetings, because they are too slow to enable daily releases. Beck suggested keeping everyone in the same room and constantly communicating as an alternative.)
What to do tomorrow
Although he never came out and said it, the general impression I had was that Beck supports more frequent, iterative releases. (Come to think of it, he does say that, often, in just about all of his books.)
One of the things he discussed during his talk, however, was the sort of dogmatic “you will begin (x more often or shorter) releases” attitude of the typical agile consultant, which is typically met with resistance.
Instead of thinking of it as a battle of wills, Beck suggested picking up some of the enabling practices above, implementing them one by one, and seeing if the objections and opposition to more frequent release just sort of … melts away.
Overall, I found the framework to look at practices to be much better than any “it depends” handwaving. It’s practical without being prescriptive.
As for his idea of trying a practice at a time to enable more frequent delivery, I found it refreshing.
I hope you do too.
For even more, you can look at Mr. Beck’s entire set of slides on slideshare for free.