It’s my hypothesis that Continuous Delivery through its focus on the actual mechanics of the production of software provides us a step change in how we deliver value through software to the business. I also argue that the failure of what is perhaps the most popular Agile approach in use today, Scrum, to put this at the heart of the development effort has been a key contributor to the disappointing results of many agile transformation programs.
The leader on scrum.org on “What is Scrum?” says;
“Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. Management and teams are able to get their hands around the requirements and technologies, never let go, and deliver working software, incrementally and empirically.”
So guess how many times the Scrum Guide, also available from that site, mentions the words “Software” or “code”? Quite a lot you’d think yes? But no, the actual number of times is zero, not once, zip, zilch that’s right not one single mention of the very thing its supposedly focussed on building. In fact I’d argue that if you read this guide and did not already know that Scrum was about building software, there is no way you could ascertain that from the text.
Don’t get me wrong, there are many good things in Scrum, but it’s focus exclusively on the organisational patterns and processes is simply not enough, on its own, to ensure the delivery of working software that meets business needs. This much was recognised by Jeff Sutherland when he wrote about the very first Scrum project;
“…a key to entering a hyperproductive state was not just the Scrum
organizational pattern. We did constant component testing of topic areas, integration of packages, refactoring of selected parts of the system, and multiple builds per day.”
From AGILE DEVELOPMENT: LESSONS LEARNED FROM THE FIRST SCRUM By Dr. Jeff Sutherland October 2004
Actually talk of code is very much at the fore in this early six page document on Scrum; it mentions code 12 times and software 36 times. Somewhere along the line however it seems that Scrum has forgotten to emphasise this central element of a successful product, one that to my mind is far more fundamental than organisational patterns. Unfortunately I’d argue that it is these elements of eXtreme Programming that were much more crucial to the success of a software project than the organisational concerns that Scrum majors on.
Ironically this lack of talk about code, I think, is one of the reasons using Scrum as the route into agile has been a popular choice as the route in for non-technical management. It talks about things they understand and inputs they can influence without worrying them about the tricky technical stuff.
Because we fail to ensure the basic building blocks of continuously delivering working software are in place we have repeatedly undervalued the importance of key technical skills. Its my experience that introducing agile organisational practices without the fundamental technical practices in place is not only unlikely to improve matters but can be downright dangerous – trying to deliver working software every couple of weeks without test automation, or clean code inevitably slows to a point of failure. Often this will result in cargo cult ceremonies instead of actual improvements. You may have seen the BBC Red Dwarf episode where Rimmer spends most of his six week period of revision fine tuning his revision timetable, leaving him with no time to actually do any revision. It seems to me that the focus on organisation patterns and process we see so often in agile leads to us failing to spend any time on actually writing better software.
Enter continuous delivery; in contrast to the Scrum Guide Continuous Delivery mentions software 588 times and code 405 times, now I accept that this is a bigger document but at 463 pages that’s still over twice per page on average for the two words combined. There is no doubt what this book is about – its about automating the software delivery process. It focuses on the desired outcome – how to get working software reliably and predictably into the hands of users.
Continuous Delivery, by building on XP and Lean, provides us, I think, with a step change in software delivery. By bringing the basic engineering practices of software, automation, building in quality, TDD, ATDD, clean code and code craftsmanship to the fore we put the code where it should be, right at the heart of our development efforts. All of the really effective development teams I have seen have these engineering practices at the core of how they deliver software. In fact by focussing on automating the mechanics of the software process they have, perhaps paradoxically, been able to consider the softer organisational issues that may be even more challenging.
Start with Continuous Delivery other good stuff can follow.
The fundamental building block’s of automation and good engineering practice must be seen as at least as important as the introduction of organisational patterns like Scrum. Scrum and CD practices can be used together successfully, but whilst great benefit will almost certainly be gained from CD alone, using Scrum in isolation is, I believe, doomed from the start.
As a final thought, if you are a non-technical manager reading this article you may be assuming your technical team are learned in these core technical practices, sadly the state of our industry is not so great. Anecdotal evidence suggests only around 1/3 of developers have or apply these core engineering skills on a regular basis, a quick search on a popular job search site today threw up the following numbers (within 100 miles of London);
2,218 jobs for agile
779 jobs for (BDD or ATDD or TDD or “clean code” or craftsmanship)
Not very scientific, I admit, but its consistent with other anecdotal evidence from show of hands at conferences etc. and it gives an indication of the perceived relative importance of these skills. I say again I have never seen Agile Software development be a success without these things at the core – Like Rimmer we need to stop worrying about our revision time table and focus on the actual revision.
See my talk on how implementing continuous delivery turned around our development efforts here.