The Productivity Trap
Over the years, the continuing drive for cost saving, efficiency and profitability has resulted in many software development teams being stripped to the bone. The opportunity cost of this is the strangling of innovation, one consequence of this is what I refer to as ‘The Productivity Trap’.
I think it is fair to say that many organisations have struggled to fully implement and adopt Agile techniques. I believe this has a lot to do with the scope of Agile being a little too narrow. Without taking into account and altering practices in all the areas associated with delivering software, Agile implementations often really struggle with the ‘final mile’; i.e., getting software applications through quality assurance (QA) and deployed into production (live). As a result, bottlenecks prevent more rapid delivery and, crucially, it slows feedback to developers.
Slow feedback to developers results in a lot of wastage within software development and release cycles. In response to this, DevOps has risen to tackle these challenges and look at the business of delivering software products in a more holistic way… but there is a problem. Existing teams are stripped so close to the bone that there is nobody available to build the things that enable the rapid delivery of software product; e.g., a Continuous Delivery (CD) pipeline.
In the real world this often manifests in teams embarking on a DevOps journey of continuous improvement, but that gets canned before they are able to deliver the benefits because they are redirected to manually release the software. Oh well, we tried, but the need to “just get things out” got in the way, right? Well, actually this is really damaging as when ROI isn’t realised it is correctly seen as a waste, but often incorrectly it turns into; “DevOps doesn’t work - we tried that, it doesn’t deliver, it’s another white elephant.”
Taking a step back, I mentioned earlier that I felt the focus of Agile was too narrow and has prevented it from really taking off – let’s be honest, the commercials are hard to manage when the output is no longer fixed – it just does not compute for procurement departments. Agile has always been sold on a; “…but it’s better this way”, “it’s not cheaper, but you’ll get more of what you want”… the driver for change wasn’t strong enough.
With ‘Software eating the world’* the need to keep pace has now become ‘do or die’. The burning platform required for transformation is here, it’s all about being able to exploit the malleability of SOFTware – if the time taken from ‘ask’ to ‘gets’ is too long then your competitors will gobble up your market share. The need is to release quicker and at higher quality.
The analogy I use for releasing software is like crossing a body of water. The traditional approach is like that of a ferry – we put as many cars, lorries, bikes and people on as we can, set sail at an agreed time, hope it doesn’t sink on the way and if it gets to the other side we risk crashes and the locals (users) complaining there is too much traffic all at once (too many disruptive changes to get used to in one go). The DevOps approach is to build a bridge; that way when a person or vehicle arrives, it can simply cross the bridge; no waiting, nothing else to get in the way, and it’s easy for the locals to deal with the regular flow of traffic (regular small changes).
Building a bridge takes time and whilst you’re doing it you either have to stop all traffic, or you need enough people to build the bridge and run the ferry at the same time. The investment needs to be made in the delivery infrastructure – in this case an automated continuous delivery pipeline. If I got a fraction of the savings that could be made by teams were they to complete this automation I would be well on my way to being a wealthy man, but all too often the same team are called down to man the ferry (manually release). Human error and not having the tools necessary to reduce the risk of deployment (automated testing, continuous integration, scripted environments) creates its own world of inefficiency and additional work, so the team will never get out of this productivity rut.
So there you have it, the ‘Productivity Trap’ is created and the only way to break it is ensure there is always a large enough crew working on building the bridge. Either ring-fence resources (or add people from the DevOps team to help) and manage customer expectations (we’ve got to slow down to go faster) or invest in additional resources to ensure you’ve got enough slack in the team to deliver the innovation (spend now to save later). What is increasingly clear is that the longer the productivity trap exists, the closer the flames on the burning platform. The less able you will be to respond to your market and grow market share… and the faster your competitors will eat your share of the market.
Commit to the change and see it through, the future of the business and success of the software product is at stake.
* Marc Andreessen 2011 - http://tinyurl.com/n85jsjx