Is Your Agile Transformation Greenfield? Really?

Over the last few years, it feels like the pace of agile transformation has really kicked up a gear. What was once the preserve of small software agencies and a few maverick departments in larger organisations has now reached the corporate mainstream.

As a result, we’re seeing more and more ‘greenfield’ agile transformations. Agile transformations taking place in departments or entire organisations that have never experimented with agile before. On one level that’s great, but on another level, it masks a problem for agile transformation that’s all too often overlooked.

You see, greenfield in this context can have two meanings. The first is the one most people usually think of. The organisation hasn’t used agile before, so you’ve got to get people used to new ways of working and new ways of thinking in order for them to start delivering using the agile mindset. This of course has all its own problems, like people thinking agile is a new process to replace the old process, or that agile is just something the delivery teams use at the lower level, rather than something that transcends all levels of the organisation.

The second meaning though is all too often overlooked, but to my mind, a huge factor in the success or otherwise of agile transformation. Regardless of whether the individuals, teams, department or organisation has used agile before, is the thing they want to use agile to produce a greenfield project in and of itself? In other words, is it a brand new product that is being gradually explored and discovered through constant inspecting and adapting, or is it an existing product that’s already live but now needs rebuilding in a new technology, or a product that has already been comprehensively designed up front, or is already being provided by all of your competitors, or is already halfway built but has run into trouble in its delivery, causing people to think agile might be a useful thing to introduce to speed things up?

All too often, it’s the latter. An organisation has a vision for a product it wants to create, has created a detailed specification for it, allocated a fixed budget to it and set a deadline for when it wants it to go live. Of course they want to deliver it better, faster and cheaper, which is why they’re doing a greenfield agile transformation, but they’re completely oblivious to the fact that their product is brownfield, so their overall transformation isn’t actually greenfield at all, and is hugely at risk of failure right from the start.

At first, you probably won’t notice this problem. Your up front budgeting allows you to bring the teams in in the first place, and if you’ve given your transformation a bit of thought, the teams might even arrive to find a nice big list of detailed user stories, set out in priority order, so people get straight to work. You buy them whiteboards and sticky notes, and feed them pizza and beer every Friday evening. A pretty textbook agile transformation.

Over time though, doubts start to creep in. As the teams do the work to deliver the stories, they start to uncover new information and issues no-one had thought of. They start to question some of the user stories and want to change them. They come up with better ways of achieving the same end goals, which means throwing away the agreed specification. But these things open up a whole bunch of problems. The business sponsors thought they knew what they were getting and when, and had been happily looking forward to seeing it in double quick time thanks to this agile thing. Now they’re being told that what they thought they were getting isn’t going to be what they actually get.

Not only that, but things seem to be taking longer than they thought they would. All of these new problems the agile teams are finding with your plan of work seem to be making delivery slower, not faster. You’ve got deadlines you agreed up front that you would hit, but these agile teams don’t seem to be particularly interested in hitting them. Indeed, some of them are even refusing to estimate when the work will be delivered at all.

Just when you felt like things couldn’t get any worse, you notice the market changing around you. The product you thought was going to be ‘best in class’ when you first conceived of it is already starting to look a little outdated in terms of what your customers are wanting and your competitors are offering. You’d love to start trying to keep up with all of this change, but you’ve already had the budget, timeline and deliverables agreed for this work, and you can’t get them changed until the end of the year and the next budgeting cycle. Besides, if you can’t even deliver what you said you would this year, then how are you meant to get funding agreed for a whole new set of deliverables? Especially when trying to do so risks making you look like a failure amongst your peers.

Suddenly it’s all going a bit wrong, isn’t it? You don’t know what you’re going to get or when you’re going to get it, but you’ve got a pretty good idea that whatever you do get will be the wrong thing, delivered too late. So rather than take the blame for this yourself, you blame agile, and go back to whatever way of working you’d been using before. Another greenfield agile transformation fails.

The tragedy with this is that it wasn’t a failure of agile, it was a transformation that was doomed from the start, because it wasn’t a greenfield transformation at all. Sure, the teams, departments and organisations were all new to agile, but the product they were creating was very firmly brownfield. Its foundations had already been fixed firmly in the ground, some of its infrastructure had already been built around it, and its future had been predicted up front in terms of what it was and how long it would take to be completed.

This might seem like a trivial issue, but it’s really not. Agile is there to build products in complex, fast-paced and uncertain environments, minimising waste and responding to changing requirements, constantly inspecting and adapting both what is built and how it is built. If you try to apply agile to a product that has already been designed up front, extensively specified and had its future delivery time and cost predicted up front like some kind of horoscope, then you’re entirely missing the point. Not only that, but you’re setting your agile transformation up to fail. The more the agile mindset clashes with the traditional mindset of how the product has been conceived, the more waste, delay and unhappiness will be created, until the transformation itself fails and is ended.

Greenfield is a great term to use in agile transformations. It helps identify what stage an organisation is at with their agile adoption, something that’s really useful for those joining the organisation to know. You need to think carefully about what it means though. To be a truly greenfield agile transformation, and to be one that is likely to work, you need to make sure greenfield applies to the product as well as the people and the process. Unless your product is greenfield too, and is open to staying that way throughout its lifecycle, then pretty much all your agile transformation will be is some people standing up every day next to some sticky notes, for no apparent reason.