In fixed-price contracts, how can a story be "negotiable and represnt a starting point of conversation with business?

Question

Our company paid for an agile coach, who - without knowing much about our company - went like this:

• Story should just encapsulate the value and then and clarified with the business
• Avoid detailed specs, that is not agile!

We were thinking about that but think that just cannot work in standard fixed-price and fixed-scope delivery projects:

• To be able to come up with a precise estimation, even the proposal must be detailed enough
• Any unclarities must be resolved as soon as possible to prevent rework effort

I do not truly believe this "minimum story level and conversation later" works anywhere in service delivery, and the same goes for postponing design and any other decisions as late as possible. Sure, it can be done, but the rework (and cost) due to e.g. design changes might be enormous...

Why is it "not agile" to know very well upfront what you need to do? What value is in reworking and redesigning a solution (pointing to adaptability) in response to changes, when the resultant solution will not be well thought-through but rather a hybrid?

Answer 1

There are a few red flags from the agile coach. User stories aren't a part of Agile Software Development. There's nothing inherently wrong with specifications. Trying to suggest methods of moving toward agility without understanding the company and the environment won't be of much help to anyone.

Agile Software Development consists of 4 values and 12 principles. Fundamentally, agility is about responding to the risks associated with uncertainty and a changing environment. There's nothing wrong with spending some time upfront to understand what is desired. However, most software development efforts are full of unknowns - either known or unknown. Agility is about discovering the answers to those unknowns and adapting a plan over time. The unknowns prevent you from creating a detailed plan early and then executing on it.

Change management is often a large part of traditionally-managed software development efforts. As time progresses, changes to circumstances drive changes to requirements. As work is done, more is learned about the work. Both of these lead to changes which have to be controlled and managed. Agile Software Development builds change management into the process by focusing on working, demonstrable software over complete and fully-approved specifications as well as close collaboration between stakeholders to make decisions on what next steps to take.

Fixed-price and fixed-scope efforts are built around plans. When a stakeholder learns something new, the scope changes, which changes the price. Agile Software Development recognizes that these changes happen very frequently in software development and large-scale fixed-price and fixed-scope efforts don't work. A series of short, iterative, and incremental efforts, perhaps even to a continuous flow of value, work better. Instead of spending a couple of weeks or a couple of months to figure out requirements estimate costs, those weeks or months can be spent working on the clearest objectives while gaining clarity on others. It also allows for changes or even termination on a regular basis.

If you truly can know with a great deal of certainty what you need to do up front, then Agile Software Development is probably not appropriate. It will only add overhead. However, if you expect to use your change management process to make changes to scope that will impact cost and schedule, then perhaps building in that change management to the way of working will have advantages.

Answer 2

“Avoid detailed specs” is likely a tortured version of this agile value:

Responding to change over following a plan

If you’ve ever experienced a project that spent multiple months gathering requirements only to fail to learn anything thru them then you might understand this interpretation.

However, no amount of agility let’s you skip requirements gathering. We all do it. Even if we do it on a cocktail napkin, rather than a 40 page word document that no one reads, we all do it.

Unfortunately “detailed” is simply to vague for this admonition to mean anything except to those who already know not to get lost in requirements.

But even though it’s being explained poorly the point is valid. Gather just enough requirements to produce useful software and let the first version teach you what the next version should be like.

Because after all, coders communicate best with code.

Answer 3

In fixed-price contracts, how can a story be "negotiable" and represent a starting point of conversation with business?

It can't.

Think about it. When do you ask for the fixed-price? At the end, of course, when you know what you need to do and thus how much it will cost. If you are trying to mix Agile development with traditional fixed-price contracts then you are asking for trouble.

Time and Materials contracts are more appropriate when doing Agile development. If you want fixed-price with Agile, then you can use it for an initial test phase to build something for a (short) predetermined period, to see how things can work and how everyone likes it, and then decide on terms and conditions of a further contract, which will probably still be Time and Materials.

If you want the traditional fixed-price, then you need to have a lot of details about what needs to be built, upfront, so that you know how to price it. Using User Stories as a starting point for a conversation then placing a price on the result of the conversation - without having had the conversation - is just silly.

You can't afford to discover things as you go along with a fixed-price contract. If you do that you will carry a lot of risk of the result of the conversation being something completely different than what you initially priced. So there are mainly two options for dealing with this risk:

• set a very large price to cover anything imaginable (which might cause you to lose the contract because it will be very expensive);
• or try to predict a more realistic price by figuring out precisely what needs to be done (in which case that's not the start of a conversation but having a very comprehensive discussion of what needs to be done, with a lot of details).

Why is it "not agile" to know very well upfront what you need to do?

Agile is about iterative, incremental development. One of its principles says to "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale". A big upfront plan is usually a characteristic of more traditional software development methodologies. The idea there is that you predict what you need to build and how you are going to build it. You then make a plan and follow it. And you do this at the beginning of the project when you know least about the project. History has shown that this doesn't work all that well in practice. Agile just recognizes that fact.

Ironically, the initial Waterfall concept was also iterative. Its author mentioned that without iterating the approach was risky and invited failure. But you don't even need to read the original paper to realize this, because in real life, if you pay attention, you will see that Waterfall is also iterative:

• you do your "Requirements" stage but in the "Design" stage you find the problems with them and iterate.
• in "Implementation" stage you find issues with your design so you need to fix them. Maybe find issues with requirements also, and fix those too.
• in the "Verification" stage you find issues with your implementation and you need to fix them. You may also find issues with the design or the requirement, and you have to fix them.
• etc.

People don't recognize this work as iterative because they work in stages. "Design" stage is over, now we are doing "Implementation", even though some of the work in "Implementation" might be to fix or iterate on issues from "Design", and so on.

So if the nature of software development forces you to iterate, why not start with that in mind, instead of wasting time to do a lot of upfront planning with heavy documentation to predict something that reality will contradict soon enough?