Agile Fixed Price - How to ...

Geert Bossuyt

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 ... as an alternative for the iron triangle


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 !

Comments (11)

  1. Eric Jimmink - Reply

    October 17, 2011 at 11:24 am

    Hi Geert, nice post!
    I fully agree that the deadline is part of the business need. And that the team must be in a cooperative mode to meet that aspect of the business need.

    Separating (perceived) complexity and business value is the hard part. A decade ago, my team was doing agile releases in a set timeframe. Usually, the product owner wanted more than what would readily fit into the release at first glance. What was needed to get to the core of the business value, was visualization. Tradeoffs were made in front of a whiteboard. Our planning sessions resulted in a lot of sketches and whiteboard pictures. In terms of your 5 keys to success, we jumped into step 5 early, and had to fill in the blanks where the path to the vision was not clear enough.
    In my experience, many teams are too fast to enter poker sessions, when understanding of the business needs or discussion of simpler alternatives is not yet complete.

  2. Alex - Reply

    October 17, 2011 at 12:57 pm

    Hello Geert,

    you write: "I propose a paradigm shift in developing software to deliver business value."
    This is something that agile SW development methodologies are cultivating for many years, nothing new.

    "The deadline is part of the need, and not the result of estimation or planning techniques."
    This is a rare case IMHO, usually the deadline is the result of customers business estimation and planing. The problem with waterfall development is usually that the customers vision and understanding (and thus his deadline) is not that clear as he thinks initially.

    "[...] where the Team decides on when something will be done. This is weird ! "
    It is indeed weird, because what you describe is not Scrum. Scrum clearly states that the PO decides when sth. is done. The Team estimates how long it will take to reach this done state. If the PO wants sth. to be done faster, he needs to collaborate with the Team to rewrite (e.g. simplify, clarify) the story.

    "It’s like buying a refrigerator [...]"
    No, IMHO, it is not. You write about software *development*. To develop sth. is different to buying sth. "from the shelf".

    "Product Owners all over the world, understand what the real business value is behind their Vision."
    "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."
    Why aren't they doing waterfall then?

    Greetings

  3. Vin D'Amico - Reply

    October 17, 2011 at 3:11 pm

    Excellent ideas! One of the major problems with any type of agile development is simply that these approaches often place too much control in the hands of the software developers. I don't believe this is the intent of the agile manifesto at all, but agile is often implemented this way.

    It often stems in part from the lack of active participation by the business stakeholders and end users. When the business is not actively engaged, the developers are forced to make decisions on their own.

    Turning the equation around and making development "market" (or business) driven changes the game. It sends a message to the business that developers are focused on their needs and will work with them to meet their goals.

    Teams can still operate with test-driven development but the planning can be market-driven. Like it!

  4. Bossuyt Geert - Reply

    October 19, 2011 at 12:02 am

    Hi Erik ,

    I totally agree with the power of visualisation !

  5. Bossuyt Geert - Reply

    October 19, 2011 at 12:14 am

    Thanks Vin D'Amico !

    Still strange though .... that many agile teams have too much power.... wonder why this is the case ... ?
    Active engagement of the business will definitely grow when using the MarketPlace.
    The mindset that is needed to deliver on time on target goes beyond co-decision making and engagement, I believe.

    It's a DESIRE to build the simplest thing that will fulfill the entire business need. This is not easy ! It's completely different from just doing what is asked and work my time.

  6. Bossuyt Geert - Reply

    October 19, 2011 at 12:22 am

    Hi Alex,

    I love your wrap up of my blog. The paradigm shift I propose is to see the desired deadline as a part of the Business Need. This is definitely a new approach. If you already have experience with this, I would like to learn from you.

    The 'issue' with waterfall is not the planning aspect.
    There are 3 real issues with waterfall :
    1. there are a lot of transition moments where information is lost
    2. things are done in a certain order, so if one takes more time, all will be delivered later
    3. most waterfall implementations are not focussing on inspect & adapt or learning from frequent feedback.

    So make a plan ! Visualise your project in time !
    But do it together, do things smart, and be prepared to learn a lot.

  7. Elgert Verhoef - Reply

    October 25, 2011 at 8:13 pm

    Hi Geert,

    Very interesting blog. Nice to read that there is an alternative for the iron triangle.

    I fully agree on the words ''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.'' however in most organisations the product Owner has nothing to say how software will be developt. There are lots of architecture boards that also have a opinion.

    Like the idea to organise a 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. Key words ...Work together

  8. Michael - Reply

    November 11, 2011 at 8:24 pm

    Interesting perspective. I think you're on to something, though it's important to remember that there are going to be some thing that you just can't simplify away. In other words there is a practical lower bound when reducing complexity. Brooks' ("No Silver Bullet") refers to this as the "essence" of engineering software. I think what you're proposing is that we eliminate as much of the "accident"or incidental work as possible, which is solid advice.

    The only other possible hole I see is that even if you fix business value up front, as the system is developed you learn more and requirements inevitably change. What you propose sounds great in theory, but ultimately dealing with change is the whole point, right? In other words -- business value is artificially fixed in this model. This is the real challenge of working with agile fixed price contracts... really any fixed price contract. At least by calling it agile you acknowledge that change WILL happen.

  9. TomGinTX - Reply

    November 22, 2011 at 6:20 pm

    Geert,

    Thanks for the blog post. It was thought-provoking enough that my boss
    made it assigned reading for our team! A comment:

    In your refrigerator example, the reason you can fix the time is that you are
    selecting from some refrigerators that have already been built. At the time you
    go shopping, the time it took to build each refrigerator is already past.

    When we are talking about development, we are necessarily talking about all the
    things that happen _before_ the item is completed and on the store shelf.

    Say you want to have your old fridge repaired instead of buying a new one.
    If the repairman comes to your house and says, "It will take a day and a
    half to fix your refrigerator," what do you do? Do you tell him you
    have a business need to have the refrigerator fixed today? Do you tell him
    to reduce complexity? Do you tell him he needs a new paradigm? Presumably,
    none of that will change his estimate.

  10. TomGinTX - Reply

    November 22, 2011 at 6:35 pm

    Geert asked:
    "Still strange though …. that many agile teams have too much power….
    wonder why this is the case … ?"

    When I take my car to be repaired, the repairman has a lot of power in
    the "negotiation" because he knows a lot about cars and I don't. So when
    he tells me it will take 6 hours to fix my car, and that I really need
    to have the transmission fluid changed, I don't have any basis for
    arguing with him.

    Likewise, any software development team is going to know more about
    the software development than the customer. That will give them "power".
    Whether they use that power for good or evil is a different question,
    though certainly an important one.

    Geert, does that answer your question? Or do you mean that there some
    special power that _agile_ teams have but other kinds of development
    teams don't?

  11. TomGinTX - Reply

    March 1, 2012 at 9:10 pm

    To Geert and all other readers,

    I had one more comment to make to sum up my thoughts on this subject.

    I agree with Deming (I think it was) who said that you should always
    try to identify previously-ignored factors that affect the success of
    your business. Include those factors in your planning.

    Maybe your enterprise has been taking delivery dates as dictated to you
    by the customer. At the other extreme, maybe you have been dictating
    delivery dates to the customer. In either case, you may be missing an
    opportunity to adjust delivery dates in order to meet the most important
    customer needs.

    On the other hand, maybe delivery date _is_ the most important thing to
    the customer, and you just have to plan around it.

    There are all sorts of things that may be valuable to a customer:
    Deadline, cost, features, performance, quality, training, documentation,
    product packaging. (Can you think of others?)

    Anything that the customer wants, or thinks he wants, or should want,
    can become part of the business need.

    Since the various wants may conflict with each other, it becomes necessary
    to negotiate and make trade-offs until we arrive at something that satisfies
    the customer in the best way possible.

    Geert, Thanks again for this thought-provoking article.

Add a Comment