The Big Bang

In the last month two significant things happened in my work.

Firstly we completed a major release for a high profile client.
Secondly I got the opportunity to work in the new River office for the first time.

This is an exciting time in my current company as we strive to move not just to taking an agile approach in our software development, but to embracing agility across the organisation by working flexibly and incrementally, always looking to add value and regularly review priorities. Working in an agile way on internal projects is one thing, taking an incremental approach with customers is not always as straightforward, particularly with customers who have a large set of requirements, a target date when I they want these to be delivered by and an expectation of getting it all delivered in one 'Big Bang'.

New Office

I worked in the new River office for the first time recently. In a mildly surreal experience a colleague and I were initially sat at desks in the middle of a nearly empty room.

I then I had to move to the corner of the room as the chap who was using an industrial cleaner to deep clean the carpets needed me to move. I wasn't bothered by this, or the noise of the cleaner, or lack of tea making facilities. I had a desk in an isolated space where I could get my head down on a task that required some careful attention. There was a lot of value in that office space for me.

Typically you would think of a move to a new office as a classic big bang operation with everyone packing boxes and piling in as part of a large scale coordinated event. Right now in typical fashion for my company, we're taking things incrementally and getting a lot of value even before the whole thing is ready. People started having meetings over there and some folks went over just to get some quiet 'heads down' time. Then slowly teams started to move in as and when they could be supported and at this stage about half of the company are now based in the new site.

Old School

By way of a contrast, in recent weeks I've been involved in a major release of software to support a customer engagement programme. As this was a replacement for an existing site the customer was keen to get as many of the features in place ready for a big launch as possible. The release was also the first to be based on a set of core capabilities that we were investing in ourselves that needed building from the ground up to support not only the bespoke needs of the programme in question but also other similar programmes in the future. This magnified our uncertainty around the development, and therefore the risk, significantly.

When working with new customers and trying to convince them off the benefits of an iterative approach, one of my favourite images to reference is one from Henrik Kniberg

It gives a very simple representation of why delivering incrementally can provide a safer option, particularly in projects with large scope or many deliverables. Not everyone is familiar or convinced by such an approach and many still insist on rolling the scope, and risk, up into a major release - as was the case in my latest project.

Did it work?

I have to say that in terms of big bang customer releases my most recent one was one of the smoother ones that I've been involved in. There was a lot of effort put in and some longer hours as we approached the release, however we did release within 2 hours of the target time with the majority of the features in place and a generally happy customer. If I was to attribute this success to anything I would highlight two factors

We ran a number of user testing sessions during development to demonstrate and get feedback on the features delivered to that point, essentially embedding a level of incremental delivery into the larger project
We did manage to negotiate a number of features out of scope of the initial release thanks to a very reasonable customer and some open conversations.

As we approached the release the customer could not have been more reasonable about things that were/were not going to be included. Nevertheless there was still a degree of pressure around the delivery that resulted in some anxiety, not least on my part, around getting the release out on time. I was painfully aware of the potential for a sense of frustration around having to compromise on some of the features that would be available from day one.

It is hard to over-state the sense of satisfaction and relief that comes in getting software released. The difference in anxiety level in a team that has successfully delivered working software and is adding to it, as compared to one that is in the process of accumulating a large inventory of unproven software, is tangible. From a personal perspective, the discomfort I felt in having a fixed scope of work and a fixed release date to deliver led to some very stressful moments.

What has happened since has also not been plain sailing. Despite efforts to maintain our standards around our core capabilities, we still accumulated a small degree of technical debt leading up to the release such that we consequently struggled to deliver the follow up work to the time-scales expected by the customer. We simply weren't in a position to progress them as quickly as we thought due to the final push to deliver the release.

In a riff on a Benjamin Franklng quote, I once read that 'the smell of poor quality lingers for long after the champagne bubbles of an on time release have gone flat'. I can relate to the sentiment. I'm pleased that we made the right decisions to maintain quality under pressure in most decisions, but not all. Despite the apparent success - the retrospective that we held post-release exposed the discomfort felt by some of the team in the days leading up to the release due to having to increase the pace of development.

A Confession

At this point I should make a confession. The fact is that for 9 years in my previous company all we did were big bang releases. Our customers didn't want new versions of the software every 2-4 weeks so we'd typically roll up new functionality into 6 month releases. Over this whole time we consistently delivered on time and with the target major feature set. In my more moribund days at that company (I am prone to a high level of self criticism) my VP would repeatedly remind me what a fantastic achievement it was to repeatedly release on time over such a period of years.

In order to achieve this we tailored our approach so that they were very well suited to tackling Big Bang releases successfully:

We worked constantly with the same team on the same product so had highly predictable velocity
We generally operated to product roadmap deadlines rather than customer deadlines, whereas other big bang releases I've worked on were based around when the customer wanted to release rather than a practical target appropriate for the software in question.
We had the ability to negotiate scope from the beginning and remove items from the release that were unachievable, or became unachievable due to emergent priorities
We had the time to focus on a continuous integration and testing structure that allowed us to maintain a constant level of quality.

It wasn't that we had the luxury of working slowly - the pace and predictability of the work delivered was impressive. It was the case that we had the maturity of process to know what was possible and predict early what was not. We also had the rigour and stability in our continuous integration and testing processes to know that we were never far away from a releasable product.

Big Bang or Hard Sell?

When working in a commercial capacity it is easy to plump for the big bang approach. In simple terms - it is easier to sell.

As an example I was recently asked to scope/cost a response to an RFP (Request For Proposal) from a company wanting an intranet and engagement programme. On examining the RFP it was clear that the scope had been established more on the basis of a big list of features desired by a number of stakeholders than a clear understanding on what value the program was intended to deliver. The list of technical requirements was huge, yet each sufficiently ambiguous to present a high level of uncertainty and risk in attempting to deliver. Even so the customer was expecting a fixed cost fixed time-scale based response to the delivery.

We took a brave approach to the response and actually offered a fully iterative delivery. We suggested working with the customer to establish their highest priority goals and target initially the delivery of features that supported those incrementally. We fully expected this to be a challenging approach and our expectations proved correct. The customer's response was along the lines of :

"Why would we take that approach when we can work with another supplier who promises to deliver this whole list in a fixed time for a fixed budget?"

I'll admit it is a harder sell. Customers are always going to prefer the illusion of certainty over the honesty of unpredictability. I've included some useful links in the references below on approaches to try to sell an agile approach to project delivery from others facing this same challenge. My strong belief is that, any supplier who did promise such a delivery would need to renegotiate once clearer details of the true requirements became clear.

On a more optimistic note - for some companies that we work with the understanding that agile deliveries can present a lower risk to both parties is starting to take hold. We are encountering more organisations who not only understand but expect an incremental delivery. Given how ubiquitous agile understanding is in development communities if can be hard to believe how alien the concept is in other fields. yet the common perception is still that the setting of arbitrary deadlines for large scope projects will deliver software of equivalent value as delivery through a process of incremental release, review and refinement. Hopefully as stories of the successes of more incremental projects become more readily available this will change, so to help this process along...

Despite the project I've described above being a 'big bang', we still approached the work in an agile way. We delivered completed features through the process and exposed these to the user community for feedback and refinement as we went. Because of this, despite the fact that not all of the scoped features were available on day one, we still released on the target day, with what is proving to be a very popular and well liked application (one of the users this week wrote a poem in celebration of the new system!) and a solid set of core capabilities that have the quality and exten sibility to use in other implementations. So I'll leave you with another of my favourite Kniberg images, to help in deciding whether the project was successful or not.