Peter DeYoe's Blog

Hello All,

I have been reviewing a number of articles and blogs recently dealing with the question: “Can you do fixed price software development using an agile approach?”  On one post in a LinkedIn group recently the participant wanted to know if you could do fixed price development and still adhere to the principles of agile.  I responded to the post by sending an article from RichardsBraindump that provided some ideas as to how you could pull this off.  And although I do agree with a number of the points in the article, I wanted to expand a bit on the topic.

As agile practitioners you understand that in terms of the Iron Triangle that you can fix schedule and cost, but that scope must flex.  You are indoctrinated in the core principle that you can complete a certain amount of work in a fixed time period (a 4 week sprint for instance).  This in turn will translate to a fixed budget to complete some amount of work within that time period.  If it looks like you will not complete the initially targeted scope within that time period, you drop out scope in favor of honoring the time and cost commitment.  The result is that you finish your 4 week sprint on time with a working, tested and production-ready piece of the software puzzle but the omitted scope goes back on the product backlog to be reprioritized for subsequent sprints.

In a typical fixed price contract where all sides of the Iron Triangle (schedule, cost and scope – with quality being constant) must be met, this looks like the project is slipping.  And of course, if scope is not flexible, then in fact, it is.

The rub lies in the fact that in the eyes of the agilest, deferring scope from one sprint to the next is a natural result of the agile process.  However, in the eyes of the business leader and IT leader responsible for the delivery of the software to the business, the project is in trouble if you continue to defer scope from one sprint to the next.  The Agilest is of the mindset that not all of the scope defined in the initial project backlog will actually be developed (only the highest business value features), yet in the mindset of the business, the definition of done (in a typical fixed project) is when all scope defined in the initial project backlog is complete.  So how do you reconcile this?

My first piece of advice is this:  If the business or customer cannot accept the idea that not all of the features specified on the initial project backlog are truly necessary to deliver business value, insisting rather that the definition of done is when all of the items on the product backlog have been completed, then you should politely decline to take on the project.  If there is one thing that I am absolutely sure of, there will be no way to reconcile this difference and meet all of the quality, scope, timing and cost constraints of the project.

For those of you that have ever “taken a bath” on this kind of project (and I feel confident that many, if not most, of you have) then you understand what I am talking about.  I think it has been well established in the industry that there is no way that a project in the early phases can be estimated with any degree of accuracy.  The Cone of Uncertainty has been well documented.  On the Construx.com website the authors state that:

“As you can see from the graph, estimates created very early in the project are subject to a high degree of error. Estimates created at initial concept time can be inaccurate by a factor of 4x on the high side, or 4x on the low side. “

And;

“An important– and difficult– concept is that The Cone of Uncertainty represents the best-case accuracy that is possible to have in software estimates at different points in a project. It is easily possible to do worse. It isn’t possible to be more accurate; it’s only possible to be more lucky.”

So, with this in mind you can safely say that what you know in the early phases of any software development project is that your estimates can be wrong by at least a factor of 4, and possibly even worse.  If you attempt to build a fixed price contract based on this reality then several things can happen.

• You will have to significantly inflate your contract price to accommodate this reality.
• You will “low-ball” the price in the beginning and hope to make up for the difference by creating an iron clad contract with caveats and arcane contract language that will lead to “nickel and dime” changes throughout the life of the contract.  This of course creates nothing but frustration on the part of the customer/business and pushes the project end date into the dark abyss.
• You will simply “lose your shirt” trying to satisfy the requirements of the project if you are not lucky.
• Quality will suffer greatly as you try to short-cut the effort to preserve your financial condition.

OK, so now the partnership and collaboration speech.  Hillary Clinton is famous for her book “It Takes a Village”.  I realize that she was not referring to software development, but to create value-rich, high-quality software, it really does!  Your customers and businesses must be co-conspirators in the quest for developing high quality, value-focused software.  They must be indoctrinated in the principles that lead to software development success.  They must understand and embrace the fact that the definition of software in the early phases of a project is loose and ambiguous and that only iteration after iteration will drive them closer to the clear definition that they seek.  They must embrace the fact that software drives business value over time and is evolutionary in nature.   In an earlier post on my blog ( Agile Adoption = Mental Shift) I stated that:

“A second agile adoption principle that must be embraced requires businesses to stop thinking about software projects with defined beginnings and endings, and think instead of software applications as living, breathing, business-value delivery systems.  Businesses must understand that business value delivery through software is evolutionary.  As the business changes, so does the definition of business value and so must the software applications that deliver that business value. “

I highly recommend that before engaging your client in any fixed price agile project that there be a period of indoctrination as to the principles of agile and an unwavering commitment from the top of the organization to those principles.  As agile practitioners, within your portfolio of services you must have an extensive education program that focuses on the key elements of agile adoption and deliver this education to all levels of the organization involved in the software development effort.  Yes, this means culture change!  Agile requires the right business climate to flourish, and like all living things, it will die outside its normal and life sustaining habitat.  Again, if this cannot be accomplished then you are better off declining the project.

Now, with the stage set and the right mix of life sustaining ingredients in place, you can begin to construct a program based on time-boxed cycles, budget commitments and TRUE value delivery to the organization.

Here are the steps that I recommend in constructing a fixed price engagement within an agile framework.

• It is assumed that the period of indoctrination was completed successfully and that the organization has or is adopting a culture conducive to agile software development.  In order to secure the business this might be a FREE or low-cost service that you provide.  Some businesses may be willing to pay, others may not.  If the software development effort is large enough the cost could be absorbed during the duration of the effort.
• Assist the customer in defining the level of expenditure that they are willing and able to spend in a given period of time for the delivery of business value driven software.  In my article Agile Adoption = Mental Shift I stated that:

“In order for Agile to work successfully, we must stop asking the following question:

‘We have all of these needs and wants for the new system that have yet to be defined in detail but can you tell me precisely how long it will take and how much it will cost?’ (Traditional fixed-price model).

Instead, businesses looking to adopt an agile software model must shift their thinking and begin rephrasing their question as follows:

‘I can afford to spend $1,000,000 of my budget this year on the development of new software that will add value to my business.  How much real business value can I deliver this year for that level of expenditure?’”

• Conduct a series of sessions that are focused on developing the initial product backlog.  This should take about 2 weeks of elapsed time working with the business and stakeholders.  You can time-box this into four, one day sessions within the 2 week period and charge a fixed price for the 2 week assessment.
• Once the project backlog has been created, begin the typical product backlog prioritization activities.  In my experience you can conduct 2 working sessions (1 day each) to arrive at a well prioritized list.  Again, this can be time-boxed and delivered for a fixed price to the customer.
• Now create your initial estimates for all of the features on the product backlog list using your relative-value estimating techniques.  I’ve typically seen the use of user stories and relative- value story points as feature set and estimating vehicles.
• Commence a 2 sprint discovery period (typically 4 week sprints, but 2 weeks is acceptable as well). This discovery period provides you with the baselines you will need to establish your core architecture, coalesce the team, and baseline your team’s velocity (throughput) and estimating accuracy.  It will eliminate a certain amount of uncertainty out of the blocks and establish the core metrics that you will need to provide your fixed cost.  Again, fix the cost of the 2 sprint effort to the customer.
• Since uncertainty of estimates is a reality, especially in the early phases of a project, you must calculate an uncertainty factor.  One way to arrive at this is to assess the accuracy of your estimates during the discovery phase.  Since you should be tackling the most complex aspects of the project first (the most complex or unknown features should be at the top of the product backlog) you should be able to arrive at a reasonable uncertainty factor.  During your first sprint planning session, you should re-estimate the features contained in Sprint 1.  Compare these to the initial product backlog estimates.  If there was a 15% difference between your original estimates and the first sprint estimates, log this as your initial uncertainty factor.  Then as you begin Sprint 2, go back and determine, based on the actual completion of Sprint 1 what your actual Sprint 1 estimates should have been.  Let’s suppose that the comparison showed, based on learning’s that the uncertainty factor was 20%.  Now do the same with Sprint 2.  Let’s assume that the uncertainty factor for Sprint 2 was 25%.  Use the greater of the values to determine your uncertainty factor which would be 25%.
• Now that you have a budget number, an estimate for the overall project in story points, an uncertainty factor and an estimated team velocity, you can now begin drafting a contract with the customer.  You can derive your costs to conduct each sprint based on the velocity.

Let’s assume that the budget for the project is $1,000,000 and after 2 sprints your average velocity is 100 story points per sprint.  Let’s now apply the estimating uncertainty factor of 25%.  If the originally estimated points in your product backlog were 1200, then it will, in theory, take you 12 sprints to complete the effort at a cost of, let’s say $100,000 per sprint.  Now, since you have already reduced the backlog by 200 story points during the discovery sprints (at roughly the cost of $200,000), the backlog is now only 1000 story points and the new budget number is $800,000.  If you then add the uncertainty factor of 25% to the remaining story points, the new story point estimate is now 1250.

On the surface, this would put you in an over budget situation (roughly $1,250,000).  However, because you have prioritized the list to deliver the highest business value features first, and you have come to agreement with the Product Owner/business that a certain percent (let’s say 70% for this example) of the total remaining project backlog represents the features and functions that will deliver what the business truly needs to increase revenues, lower costs etc., then the magic number to complete the highest value components is 875 story points (1250 x .70).

You know that your velocity is 100 story points per sprint so you can feel relatively confident that you can complete the remainder of the effort in 9 sprints (8.75 sprints rounded) at a cost of $900,000.  However, since we have already used up $200,000 of the budget, we are still over budget by $100,000.  The customer must either increase his budget to $1,100,000 or you must reduce the number of story points and consequently the business value that you can deliver (unless of course you want to compromise your financial position to meet the customer’s needs which is always an option).  For the purposes of this exercise let’s assume that the customer is willing to increase the budget to $1,100,000.

So these are the magic numbers that you base your fixed price contract.

For the fixed price of $900,000, we will deliver to the business the remaining 875 story points, that at least at this point in time; represents the core business value that the software system must deliver.

Now for the controls!  What you are agreeing to with this contract is to deliver 100 story points worth of features each sprint (on average) that have been developed, tested and accepted by the customer.  The definition of completed story points in Agile is that they are potentially production ready.  The onus is on you and your team to live up to that commitment and the associated costs to deliver this will be on you and your team, not the customer.  So, it is imperative that you have a “well-oiled machine” that can deliver this consistently.  A subpar team will put you in a losing situation.  You must know what you are doing and your team must operate with the greatest level of efficiency and effectiveness.  If you cannot deliver this then you should consider an alternate vocation.  Selecting the right initial velocity is important.  The good news is that as your team completes sprints, the velocity should improve over time.

If you are up to the challenge, then a couple of key ingredients must be in place.  The Product Owner, typically a Sr. Business Level or Project Management professional that embraces the principles of agile and understands true business value must be a full-time contributor to the project and represent the business at all times.  This is typically an employee of the company that has direct reporting responsibility to executive management.  (See my blog posting Product Owners – The Guardians).

Secondly, if you are using Scrum for instance, the Scrum Master must work closely with the Product Owner/customer to ensure that the team is focused, daily, on the 875 story points.  This is what was initially determined by the customer to represent the 70% of features that will deliver the most value.  The 70% at this point becomes moot from a contract perspective because that will most surely change over the course of the effort.  Because the customer can add features and functions to the product backlog and because it is reprioritized and re-estimated continuously, 875 may not represent 70% of the backlog in the future.  This is acceptable in the sense that the contract is for 875 story points regardless of how the product backlog changes over time.  This contract is designed to deliver 875 story points.  No more.  If it is deemed by the Product Owner that more story points must be completed to represent value to the business then the contract needs to accommodate an increase in the number of sprints to be completed and ultimately an increase in the price.

Now here is the “fly in the ointment”.  Estimates will be changing throughout the project from sprint to sprint.  No matter how good you believe your initial estimates and uncertainty factors are you can’t have full confidence in them.  With enough accuracy erosion of your estimates over time your contracted 875 story points could potentially represent less of the features and functions than the customer originally expected.   So even though you hold the mark on delivering 875 story points it could represent less and less of what the customer expects you to deliver.

Sounds like you are right back where you started from right?  RIGHT!    Well folks, let’s face it.  That is the essence of the fixed price game.  And with agile, you cannot guarantee the scope.  You can definitely deliver high quality software in increments of time that you can commit to and increments of cost that you can commit to.  But you cannot commit that the scope will not change from what the original expectation may have been.   You are committing to delivering high quality software that the customer can feel, touch, and experience as it is being developed so that the resultant product is what they asked for.  You are committing to providing the highest level of velocity possible.  You are committing to accomplishing as many features and functions on the product backlog as humanly possible.  You are committing that you will not exceed the budget dollars that were set at the beginning of the project.  But you cannot commit to the percent of the product backlog that you will actually accomplish.

What am I saying here?  That you should not do fixed price agile projects.  Well, if you have a choice, probably not!  But we live in a world of budgets and deadlines that will ultimately require you to “fix” something.  So if you have to engage in a fixed price project, fix it on capacity (velocity) for a given period of time (e.g., 100 story points each sprint for 9 sprints) with a guarantee of the quality of each unit of software delivered.  However, since committing to a project model based on malleable scope is so foreign to the way in which most businesses have operated in the past, you are causing the customer some apprehension here.  You need to provide them with a lever of control.  Therefore, I (and others in the agile community) recommend that after each sprint, the customer can cancel the project if they do not feel that enough value will be attained by the end of the effort (you might want to add a small cancellation penalty to cover your ramp down costs).  If they get through 3 sprints and realize that only a fraction of the business value will be delivered before the budget is exhausted, they have only paid for 3 sprints and can seek other means of finishing the project if they choose or cancel it completely.

As I go back and review what I just wrote, I realize that this is not a perfect scenario.  But then again we have chosen a profession that does not fit neatly into a box.  Most of us in the software development business have been dealing with this and will continue to deal with this issue for the rest of our careers.  It all comes down to building trust with your customer community, taking it on the chin from time to time I suppose, and maintaining an open and honest channel of communication with your business customer.

I welcome your thoughts and insights.

Pete

Follow me on Twitter at www.twitter.com/peterdeyoe