Doing "Big Bang" releases may seem like an effective use of time and people. They may carry huge prestige and bragging rights for their leadership. But are they good for ROI? In this episode, I talk about the dangers they bring - from dangerously high levels of risk to reduced agility to respond to market pressures.
Or listen at:
Published: Thu, 26 Nov 2020 08:13:43 GMT
Transcript
[00:00:35] Hello, and welcome.
[00:00:38] I want to continue my mini series on Bad for ROI, a mini series looking at things that may seem on the face of it, good for ROI, something we may feel desirable, we may feel is actually a good way of working. Traditionally, maybe we've been taught it's a useful way of doing things.
[00:00:57] However, what I want to do is to take those individual things that I want to discuss and I want to question them. I want to look at actually: "is it the best thing for ROI?", "Is that the right way we should be doing stuff?"
[00:01:09] And in this episode, I want to look at Big Bang.
[00:01:14] So what am I talking about when I say Big Bang?
[00:01:16] I'm talking about doing everything at once, some big fundamental change, maybe some grandiose event that are making changes to, maybe the culmination of a massive project.
[00:01:27] Take, for example, we've been working on a new website for six, 12, 18, 24 months. Big Bang is about releasing it all in one go going.
[00:01:38] "There you go, done."
[00:01:41] Now, I can understand that Big Bang can be quite attractive. Take the example of that website. You're thinking, well, if we've got this much work to do, let's defer things like testing, for example, until the end, where we can concentrate all our testing in one go.
[00:01:59] So if there's maybe six months worth of development effort, let's have testing right at the end and devote our time to testing it fully at the end. It might feel as if it's an effective or even efficient use of resource.
[00:02:16] Businesses also like to have big milestones.
[00:02:20] They like to have audacious goals, which is great, and maybe turning around and saying "Right by this date we're going to have this big bang change" feels good and sometimes it actually brings prestige.
[00:02:33] I can also see it being quite attractive at the executive level. Once you set this big, audacious piece of work going, you could maybe be quite hands off, maybe only receiving things like status updates, maybe as far as every month, every quarter.
[00:02:51] But basically you've got this massive project running behind the scenes with as expected outcome at some point. And that becomes quite attractive to the executive team who think that's just being handled and they can concentrate on other things while it's happening in the background.
[00:03:10] I also think there's a level of prestige that comes with anything big, anything big and grandiose. You want to be the project manager of this massive, fundamental, changing project. You want to be the leader that brought in this massive change.
[00:03:26] So there's a number of reasons why it's attractive, both in terms of, I believe, perception about effectiveness and utility of people and time and money and of course, the prestige that can come from something so grandiose.
[00:03:44] But let's talk about the downsides.
[00:03:48] For me, probably the biggest downside you've got straight away is the increased risk.
[00:03:52] If you're putting that much change into any any event, you're increasing the level of risk. More change, more risk.
[00:04:01] I also find that if you're doing a big bang approach, you're tying up so much of your resource that it also makes it very difficult to react.
[00:04:11] So, for example, if you needed to react to the market or maybe a security problem. If you've got all of this code tied up before you possibly even think about doing a release, how long could you possibly have to wait to do something that's super urgent?
[00:04:32] I've also found that what happens is you get an ever growing spiral in terms of cycle times. So a small set of changes may only take a couple of months to roll out and it becomes a cycle.
[00:04:48] So you build up the set of changes. You test them as a batch, you release them.
[00:04:53] However, what you're finding is because the more you're doing, the more you need to test. The more onerous that whole process of getting it out of the hands of the developer and into production is.
[00:05:04] And as that work grows, there is a mindset shift to go: "OK, can we sneak something else in?" or "Can we do something else?" or "Could we do something else?"
[00:05:14] And before you know it, I've seen businesses get to the point the cycle has become so large that in effect we never actually get to the point where they manage to release - because they're putting so much work in, by just trying to squeeze the extra bit in.
[00:05:27] In one case, it got so bad that the customer was unable to deploy for two years because they got such a large cycle and backlog of work ready to go, that they'd have to take their main site down for 48 hours, which wasn't acceptable.
[00:05:51] So what's the antidote to Big-Bang?
[00:05:55] Well, little and often that's the simple answer.
[00:05:59] Smaller changes done with much greater frequency.
[00:06:04] So if we're talking about where I have highlighting concerns over if you needed to react to the market quickly, and it's been very difficult if you've got a lot of work ready to go - it makes it so much easier if you're actually deploying a little and often.
[00:06:20] You can just go "OK, we've got a major emergency", "we need to do this because of a security issue", "what we need to do this for a major customer", "we need to do this for legislation" - It just slots into the next available slot. You get used to that muscle memory.
[00:06:37] And by doing that, and by doing little small incremental changes, you've got much smaller risk. You have much smaller risk to the organisation.
[00:06:49] This, in turn, means you're much faster to market and much more flexible. As I've just said, it leads to considerably less failures because you're not trying to back up 100 different things that affect the entirety of the website. You may be releasing one or two things that have a very small surface area.
[00:07:10] And this ultimately leads to ROI - because what you're seeing is you're turning the investment you're putting into your development team, into your product teams, into your any work you're changing, you're seeing it into the customer's hands quicker, sooner - whether that be internal or external customer.
[00:07:30] You're seeing that work getting into their hands quicker and thus you can start realising any benefit and thus realising ROI.
[00:07:42] And working in a little and often way is very much in line with how modern software development is heading. Everything in modern software development is about looking to automate those pieces of work that actually preclude you from doing little and often.
[00:07:59] So if we look back in history and we talk about all we wanted to make a website change, we may be going - OK, it's going to take us maybe a day for the developer to do his thing. We then need the system testing that may take a week. We then need it plan deployed and so on and so forth. And we could be talking of a developers one day of work may take another two, three, four weeks even before it could be released.
[00:08:29] Now, this is where things like Continuous Integration, Continuous Delivery and Continuous Deployment, technologies are introduced in episodes 19 to 21, really help us to be able to move much faster by automating so much of that work. So much of the testing, so much of the integration and so much of the actual deployment itself, that we have the confidence that we can move faster.
[00:08:57] It's all handled by the system.
[00:08:59] The system knows what it's doing - its automated, quicker, more reliable, more trustworthy. And we've got better proof that it was done right.
[00:09:10] OK, so I've talked about Big Bang in this episode. The main thing I wanted to talk about was the risk and the speed to market that batching all of these things up into. A big, grandiose release is really bad for us. It causes high levels of risk. It slows us down in terms of our speed to market and it ties up all that investment and good work that we've done to actually produce ready to go live.
[00:09:39] And the antidote for that, of course, is keeping small, experimental, moving quickly - using modern software technologies and practises such as Continuous Integration, Continuous Delivery and Continuous Deployment.
[00:09:55] I hope you've enjoyed this episode, and I look forward to speaking to you again next week.