Forums

By posting to our forums you are agreeing to the Forum terms of use.
Thoughts about *How Scrum works in a fixed Price Projects"
Last Post 28 Nov 2012 02:57 PM by Ian Mitchell. 9 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Informative
Usman
New Member
New Member
Posts:2
Usman

--
27 Sep 2012 02:28 AM
    Hi,

    The other day, I have been asked a question about how to bring scrum into fixed price projects... Interesting though.

    I would like you expert guys to give some thoughts about this.

    Any experiences would be highly appropriated.

    /Usman
    Leo Gagne
    New Member
    New Member
    Posts:1
    Leo Gagne

    --
    27 Sep 2012 01:33 PM
    The question can be answered this way:
    "You will get what will be done up to the budget limit!" In scrum, each sprint will deliver potentially shippable increment to the product. This means that if the product backlog is well prioritized, high-value features will be done soon during the project, resulting in a product that quickly has value. Each sprint will add value to the product. When the budget is reached, normally you should have something to deliver. Maybe it will not offer all the inital features you were expecting, but maybe you could be surprised to finally deliver more, or even better, deliver something that fits the customer needs better!

    Now... This question is often biased by a subsequent or underlying question: what happens if the budget is fixed, the timebox is freezed and we promissed to deliver all the functionalilities? This is what I call the "iron triangle", no variables, only solid-framed limitations... Get prepared to negociate! This is what agile tries to change!
    Eric Poole
    New Member
    New Member
    Posts:5
    Eric Poole

    --
    09 Oct 2012 08:38 AM
    Good morning, Leo.

    (I really hate the expression "In a perfect world", but...) In a perfect world, "You will get what will be done up to the budget limit" is fine. In the real world... I have been consulting in software development for 34 years and I have never met a manager who would stand still for that.

    This is a question to which I have yet to find a satisfactory, or even marginally satisfying answer.

    Most engineering and manufacturing companies, that aren't pure "think tanks", when they envision a new project to develop a new product, have a time and cost budget in mind beyond which it is no longer time-effective or cost-effective to develop the product. Maybe they have to get it out into the marketplace by a certain time or they lose their window of opportunity. Maybe the product has to sell at or below a certain price point or no one will buy it.

    Most Agile (upper-case "A") processes emphasize the time to complete the next increment (the next "sprint" or whatever one wants to call it) and don't pay much attention to how long it is projected to take to complete the whole project. Ditto costs... most Agile processes don't seem to pay significant attention to development cost targets.

    So, precisely HOW is it that one convinces senior management of the benefits of Agile processes when the managers' major focus (it's in their job descriptions) is on time-to-market and total cost figures?

    Note the difference between "Agile" (upper-case "A") and "agile" (lower case)... I consider the former to mean a defined process that conforms to the Agile Manifesto. The latter is what most people, particularly software managers, mean when they use the term... at best, they take it to mean "anything that is faster than how we have done it before" including any of the iterative processes that have been in use for decades.

    Eric Poole
    www.rkt-tech.com
    Joshua Partogi
    Posts:99
    Joshua Partogi

    --
    14 Oct 2012 07:32 AM
    Hi Eric and Usman,

    Have you guys taken Professional Scrum Master Course already? The trainer will teach you about fixed price contracts in Agile.
    Eric Poole
    New Member
    New Member
    Posts:5
    Eric Poole

    --
    14 Oct 2012 07:47 AM
    Thanks, Joshua, but that's a little bit like saying "Buy this book and it will tell you". Forums (fora? fori?) like this one are for getting answers to specific questions, helping one another, and holding discussions, without having to go to the expense of traveling to some course or buying some book.
    Philipp Eisbacher
    New Member
    New Member
    Posts:32
    Philipp Eisbacher

    --
    18 Oct 2012 08:51 AM
    Hello.

    I'm quite new to scrum, but I'm really trying to learn by reading and reading and participating in trainings, so my thoughts are:

    Scrum does not mean "no plan/no estimation" In the beginning of a product development you have to figure out what the needs of a customer are, and of course, they are estimated.

    Nevertheless it is clearly stated, that those estimates are only rough estimates to get a plan how many sprints you need to deliver if you know the velocity of your team.

    I know, this does not sound like scrum estimates are really exact, but in my experience with waterfall projects I found the same but with more investment in the planning, because the best IEEE-requirement-sheet always only says "it is as described if nothing changes!"

    So my project planes in waterfall most of the time show something like "exact dates" but this is an illusion MS project gives me ;-)

    I heard about an interesting presentation about selling this agility to the customer: Jeff Sutherland talking about "Money for nothing, Changes are free" google it, I think it's quite interesting.

    So estimating (and fixed price projects are much about estimating) is always hard and the bigger the project and the more unknown a domain is, the harder it gets. But scrum does not make it harder, it makes it faster and more flexible.

    may I was able to bring a few things/thoughts in this discussion.

    Br,
    Philipp
    Gunther Verheyen
    New Member
    New Member
    Posts:26
    Gunther Verheyen

    --
    11 Nov 2012 12:14 PM
    Eric, one could have a good enough Product Backlog holding requirements and other ideas to build into the product, consider expected team size, look at past velocity or comparable figures to figure out the estimated #Sprints and have an indication of timing and cost. Actual implementation is still required to validate all these assumptions. If time and budget have been fixed, scope will become negotiable. Product Backlog and progress on it (e.g. burn-down) will keep all involved informed about the feasibility of the initial plan.
    The amount of detail that's put in the initial Product Backlog depends on the level of trust in general. Creating an exhaustive, fully detailed Product Backlog is not helping much but may be required. Do note that this is not an obligation posed by Scrum, but a decision taken outside of Scrum.
    Gunther Verheyen
    New Member
    New Member
    Posts:26
    Gunther Verheyen

    --
    11 Nov 2012 12:17 PM
    There is always something like ("Yes, but reality"). As in my answer to Eric, always look for highest achievable. Nevertheless, if I give my honest opinion to people on the topic of fixed prices, in general everyone agrees with my statement: "Fixed Price bids. An open invitation to bribe, cajole, lie and cheat.". All my thoughts at http://ullizee.wordpress.com/2012/1...and-cheat/
    Renesh
    New Member
    New Member
    Posts:2
    Renesh

    --
    13 Nov 2012 08:54 AM
    My 2cents worth: The problem with Fixed Priced Bids is that it is based on a contract...and therefore the contract takes precedence over everything else. This would go against the AGILE Values of valuing customer collaboration over contract negotiation. In my experience (at various clients), once the AGILE mindset and the thinking behind scrum is explained to the client, the need or demand for a fixed bid price is dropped in favor of the client being able to continuously 'direct' the product. This is the value of SCRUM and AGILE in my world. Alas, Fixed price contracts are going to be around for a while though...
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:581
    Ian Mitchell

    --
    28 Nov 2012 02:57 PM
    I recently applied Scrum within the DSDM framework to support public sector fixed price contracts. Essentially, this was done by treating a Sprint as a DSDM delivery timebox, and therefore as a trading space for negotiating requirements in or out of scope. Cost and time were fixed, but scope became variable. The tradeable scope consisted of the Should and Could requirements of a MoSCoWed sprint backlog.

    Admittedly this was done before the Scrum Guide changed from sprint commitments to forecasts, but I suppose it might be possible to do something similar by placing the contractual emphasis upon sprint goals rather than upon a sprint backlog.

    Fixed price work certainly presents challenges for agile practice, but I agree that it is going to be with us for a while yet.
    You are not authorized to post a reply.


    Feedback