Slow Agile Project

I recently delivered my ‘Introduction to Agile’ presentation to a client that is in the process of transforming from a very structured SDLC / Waterfall model to Agile, specifically Scrum.

The presentation is deliberately short; it is intended to spark conversations and questions rather than a detailed workshop on agile practices and processes.

The company in question has had some challenges in transitioning to agile, which is why I got a call to come in and help. I often use the introduction presentation as a tool to explore where there may be challenges. It has the extraordinary effect of opening people up, revealing numerous avenues to be explored.

On this occasion, one of the comments that came up completely took me by surprise.

Estimation and Fixed Pricing

To give a small amount of context, without breaking my client’s confidentiality, the company in question deal with a significant number of fixed bid / fixed price projects and have, over the years, become quite adept at estimating projects.

They had a sophisticated process through which they were able to map out their schedule with a margin for error of around 10%-15%. I was impressed.

Slow Never Ending Projects

The comment in question was this:

Agile processes just seem to create slow never ending projects.

I was stunned to silence. Everything I had presented, everything I had discussed, in fact everything I understood about agile processes contradicted this idea. How could anyone have developed this perception?

Asking the person to explain further, they elaborated with the following explanation. The company continued to establish their plans using their tried and tested approach, derived their estimate and initiated the project. They then progressed into their sprint cycles. As per their process, they did a demonstration of the functionality developed at the end of each sprint. This demo was to the customer and was used to elicit feedback which as expected was added to the backlog.

So far so good, right? I still wasn’t seeing the problem.

Walk in their shoes

I was fortunate enough to have Chris Voss’ excellent book Never Split the Difference recommended to me. It’s a fascinating read, has excellent advice, in my opinion, and is filled with practical hints that go far beyond its stated goal of negotiation.

Tactical Empathy, for example, is one of the key techniques in the book. It’s better known as seeing things from the other persons perspective. But his version is on steroids.

After a bit more digging, and applying a bit of tactical empathy, a sudden realisation dawned on me. A fixed bid deal had been agreed with the customer, but now the customer could change the goal every two weeks, which was the length of a sprint. The idea that the project could never finish was in the context of the original fixed bid project. That project might never finish because higher priority items kept being discovered.

Similarly, the slow reference related to how quickly the tasks in the original plan were being completed. Which in some cases was never.

Potentially Shippable

A key underpinning of the Scrum process is that each iteration should build potentially shippable software. This is a significant departure from Waterfall models, where at best a shippable product may exist at specific milestones in the project lifecycle. The impact of this small statement is often overlooked. In its widest interpretation, the customer may look at what has been delivered, decide that they have enough functionality and terminate the project. In the waterfall world, this could be breach of contract, or at best not an option until a previously agreed break / review of the contract. In agile, it’s a declaration of success.

Conversely, and to be honest the reality I’ve seen more often, the customer is forced to rethink their priorities to ensure that they are getting the highest value from each deliverable. There’s no rigid adherence to the long term roadmap. In effect, the frequent deliveries change how the customer sees their own capabilities and as a result, how they behave. This shift tends to be more gradual than a single epiphany but over time the customer becomes increasingly agile in their thinking.

Hidden Costs

The first problem then was that in this case, my client wasn’t managing the customer appropriately. They were still in the fixed bid, fixed feature, waterfall mindset, which naturally led to their misinterpretation of what agile was offering.

I had a niggling feeling that I was still missing something though. The behaviours were right, the customer largely seemed happy so why was it enough of a concern to raise during this presentation?

I’ll do a separate post on Fixed Bid projects, as I can’t do them justice here, but a key discipline that is required to effectively manage Fixed Bid projects is change management. If a project simply must be fixed bid, then every change has to be documented and agreed before it’s implemented.

This was the missing piece of the puzzle. My client had allowed the change process to overwhelm them. They weren’t managing the changes that emerged from the demo as change requests. They were being the nice guys and taking changes as bugs.

There were a couple of issues with this approach. Bugs weren’t billable under the project’s contract; delays and slipped dates had penalty clauses with a financial impact and most importantly, there was no record of the customer explicitly requesting changes. The net effect was that my client was subsidising the enhancements and they were being financially penalised for missing the original dates.

Do the Work

The fix in this case was straightforward. Apply the existing change management rules to enhancement requests resulting from the demo. Given the inherent formality of fixed bid projects, particularly those my client had signed, the change process necessarily was also formal. Each change had to be signed off by the customer, along with an estimated cost. It’s not trivial, it’s not quick, nor easy, but then again it also helps my client not go out of business.

Agile is not intended to be a free hand for the customer to eek increasing levels of functionality from a supplier. All of the agile processes / frameworks exist to accommodate the inherent changes in a software project, which makes fixed bid projects difficult but not impossible. It’s important to adapt all of the rules to the new process though or you might find your project bleeding money quickly.