Agile Fixed Price – How to …

Market Driven Development  (aka Agile Fixed Price)

I propose a paradigm shift in developing software to deliver business value.
For a team to satisfy a business need,
it is not the amount of work that defines the time needed,
it is the available time that defines the amount of work that can be done.
The deadline is part of the need, and not the result of estimation or planning techniques.
With the deadline being part of the need, the Team and the Product Owner have a shared budget ( = number of Sprints ) to realize the Vision.
Instead of using Poker to give insight in the estimated time of delivery, let’s create a Market Place where Product Owner and Team ‘negotiate’ on the complexity of each story.

I see a lot of organizations doing Scrum where the Team decides on when something will be done.   This is weird !   Those teams hold the organisation hostage.I believe this cannot be a good way to collaborate.
I would like to share some success stories about how we delivered Agile Fixed Price projects lately and the ideas that made them succesfull.

What is a ‘business need’ ?

A ‘business need’ doesn’t need to be vague.  It’s something very concrete.
As a business stakeholder I want to realize my idea so that I can gain competitive advantage.  And I want this before the end of next quarter with a maximum cost of X euro.
In Scrum we call this the ‘Vision’:   One statement that everybody can understand and where everybody believes in.

A metaphor

It’s like buying a refrigerator:  When I want to buy a refrigerator, I know what I need and how much I want to spend on it.    The business value for me in this example is that it is red ( my entire kitchen is red),  that it keeps my food fresh and that I can use it as a freezer.   My budget is 100 euro.  I need it today because my fridge is broken.  And off course it needs to be not to bad for the environment, we live in the green age after all.
Going to a retailer, it will never happen that I come home with a blue fridge for 500 euro that will be delivered in 3 weeks.     I might decide on a big or small fridge with one or two doors, but these criteria don’t add value to my business case.

Fixed price, fixed need, fixed time and fixed quality

So in my example of the fridge, I fix the price, fix the need, fix quality and I fix the time.
No issue with that.   Naturally I need to be flexible in some area.   I’m prepared to be flexible as it comes to features that have no direct relation to my business need.
Software development is no longer that hard that this example doesn’t stand as a metaphor.    Product Owners all over the world, understand what the real business value is behind their Vision.   Part of this Vision, is to have this idea realized before a certain date.     Fixed price, fixed quality, fixed need and fixed time !

The golden pentagon… an alternative for the iron triangle.
Fixed price, fixed quality, fixed need and fixed time !

Flexibility is in technological genius, polishing features, features that are not really needed…. Flexibility is in the time we spend on meetings, on fixing bugs, on discussing…
Flexibility is in our heads because we like to fix complex things instead of making things simple.
The key is in simplicity.    Simplicity of technical solution, simplicity of collaboration, simplicity in responsibilities.   The more we make things complex, the less flexibility there’s left.

How to bring this to practice :

2 steps that will make a world of difference :

•  Know the path to success.

Business value is hard to  link to individual stories.   Far easier it is to define the business value for a Vision or an Epic.
When business value is decided, it is doable to decide on what you can afford to spend on the realization of this idea.   Given the cost, and given a team, the time that can be spend on this development is a given as well.
Let’s take a Vision that can cost 10 weeks to deliver.     Then work together to define the path towards this Vision, and clarify what part of the Vision will be realized in every 10 of the sprints.
From there it’s simple.  The only thing you have to do, is make sure you deliver every week what you agreed upon.   And remember, flexibility is in cutting complexity, not in descoping stories.

•  The Market Place instead of Poker sessions.

A lot of complexity is in each story itself.   How to cut down the complexity that is in every story ?  Since we’ve already decided on what needs to be done in every Sprint,  the value of pokering stories might seem questionable.
However there is a good reason to continue doing something similar:
Before a Product Owner enters the Market Place ( new name for the poker session), he knows what he wants to spend on each story.  We can use storypoints as a currency here.    He explains the story, and the Team pokers the story.   When the estimation is in line with what to Product Owner wants to ‘pay’ for this story, all agree.
When the estimation is higher then the Product Owners budget, the Team and Product Owners should discuss on why the Team thinks this is more complex.   Often, in this discussion it turns out that complexity is in the things that have no business value.  So skip complexity, and make the story smaller, without compromising business value.
Don’t forget, it’s ‘Quality without Compromise’.    Reducing complexity is not a synonym for degrading quality or compromising on the so called non functionals.   We’re talking about reducing functional complexity, technical complexity, complexity in interaction designs, ….
When the Team estimates lower then the expectation of the Product Owner, you have the same discussion.  Why did the Product Owner reserve a larger part of his budget then needed?  Where does he see complexity that the Team doesn’t see ?

Key to success :

1. To have a clear Vision.   Understood and with business value.   Including a strong need for deadline.
2. A Product Owner that knows his need, and can translate this Vision need into stories that define smaller business needs.
3. A Team that has the mandate and is willing to make choices to deliver the Vision in the given time.
4. Clear understanding of the path towards the vision.    I love to do this in a storymap.   It makes clear what will have to be done in every Sprint along the way.
5. The Market Place, where Team and Product Owner ‘negotiate’ on the complexity, the value and the cost of every single user story.    The more intense this Market Place, the more complexity will be cut, and the more business value will be delivered.

One last thing:

As Parkinson’s law states, the amount of work will fill the time given.
If we don’t allow the work to fill half of the time, we can deliver every piece of work double as fast.

Market Driven Development (MDD)

MDD is a concept to bring entrepreneurship into software development.
Product Owners all over the world, understand what the real business value is behind their Vision.   Part of this Vision, is to have this idea realized before a certain date.
With the deadline being part of the need, the Team and the Product Owner have a shared budget ( = number of Sprints ) to realize the Vision.
Strong ‘negotiations’ in the Market Place force complexity to be reduced and allow both Team and Product Owner to deliver business value with fixed price, fixed time, fixed quality, fixed need.
Let’s unite !  And give our Product Owners what they need when they need it.
Product Owners around the world, become entrepreneurs and negotiate to get what you want.  No more, no less !