How to use agile methods for the fixed price contracts

Agile software development methodologies discourage the use of the fixed price contracts. When forced to commit to the fixed price, agile approaches advocate unfixing the project scope. However, even if it is impossible, there are still ways to realize the benefits of agile methods.

Poorly predictable complexities

Sydney opera house, a beautiful piece of art, the Sydney’s best known landmark and international symbol was started as a fixed-price, fixed-date project. Unfortunately, since it was no standard building time, it was impossible to estimate all the difficulties and complexities in advance. As a result, it took 13 years and 102 million Australian dollars to build instead of 3 year and 7 million estimated – 330% time overrun and 1350% costs overrun!

Software development is almost always to some extent a creation of something new, that nobody built previously. Therefore fixed-price and fixed-date contracts for the software development are known to be imprecise and incorrect. Nevertheless, despite the frequent and virtually normal cost and time overruns, in many IT organizations, especially in the big ones, it is often required to put a quote upfront in order to get funding secured. It is even more common in the subcontracting or offshore environment.

Agile fixes

An agile solution for such a fixed-price situation would be to unfix the schedule corner of the time-cost-quality triangle. It typically means establishing either a form of time & materials contract or gated financing. In the time & materials case the customer pays for the development month by month or iteration by iteration. Usually customer has the right to terminate the collaboration after any iteration, possibly with some premium. In the gated financing case, the product is agreed to be developed and delivered in several phases with the first phase fixed priced and the following phases fixed, when they are about to be started.

In both cases the solution has to be trust based as unfixing any time-cost-quality triangle variable naturally reduces the customers ability to force the implementor take the risks and pay for the estimation mistakes. Some clients, especially the ones working with the particular software development organization for the first time cannot agree to it. Is it still possible to apply the agile software development methods then? It is. Even though agile methods allow for the dynamic adjustment of the work scope to what the client actually needs, they also iteratively increase the efficiency of the team to the highest possible level. If you anyway have to work on a fixed price, fixed scope contract, it still makes sense to utilize the method that helps the team be most effective and as a bonus allows to see the danger of cost or schedule risks as soon as possible.

Further links

XP Practices

Values are the the roots of Extreme Programming stating what we like and not like. Principles guide applying the values to the realities of software development. Engineering and not so engineering practices compose the lowest and the most explicit layer of XP. These are known best ways of implementing the values and principles in the daily work. Primary practices are the ones that are useful on their own. Corollary practices are not so safe to start with and are best applied after most of the primary ones are implemented and there is a certain level of understanding the XP values and culture in the organization.

XP Primary Practices

Sit Together, Whole Team, Informative Workspace, Energized Work, Pair Programming, Stories, Weekly Cycle, Quarterly Cycle, Slack, Ten-Minute Build, Continuous Integration, Test-First Programming, Incremental Design

XP Corollary Practices

Real Customer Involvement, Incremental Deployment, Team Continuity, Shrinking Teams, Root Cause Analysis, Shared Code, Code and Tests, Single Code Base, Daily Deployment, Negotiated Scope Contract, Pay-per-use

Further Links

This page is a part of the Extreme Programming overview

How agile has to kill projects

Agile software development methods assume the significant amount of uncertainties and risks in the software development. The idea of the iterative development  employed by agile methods is aimed at verifying the project direction and state frequently.

Agile risk mitigation

Agile approach at risk mitigation is to attack the most unsure items first and therefore lessen the amount of the unknown as early as possible. In a way every iteration planning is a risk analysis and mitigation planning session. Imagine a project, where supporting millions of users is something the team is not sure is possible. In this case agile methods advocate for implementing the scalability support before the majority of the features.

Such a proactive attitude towards the project risks can establish the confidence in the project success very early in the project life cycle. However, reducing the amount of unknown might also reveal the fact that the company is building a wrong product, is using a completely inappropriate technology, etc. Frequent reassessment of the project risks might also shed light upon that competitors just overtook the whole market segment.

Kill fast

Often detecting this kind of facts early helps with crafting the corrective actions. However, sometimes it clearly shows that killing the project is the most profitable decision the company can make. Seeing such a sad truth might not be the easiest experience in the lifetime, but sometimes it is the only recipe for saving a pile of company and/or customer money. The ability to fail early and kill the project before burning much time and money is one of the often overlooked strength of the agile methods.

See Also

  • Agile Also Means Fall Early and Get Up – Nick Malik advocating the kill parties, “where everyone celebrates when a bad idea is killed before it consumes buckets of shareholder’s cash”

Weekly Agile Reading. Pack 6

Manually filtered top of the most interesting writing published since last Saturday. Of course, most interesting from my personal point of view.

Top writing of the week

  1. Nine Boxes – Dave Nicolette describes a simple yet effective tool for interviewing customers. In essence it is just a clever set of of questions to get the requirement captured in a dialog.
  2. Estimating Testing Using Spreadsheets – Mike Kelly presents a practical approach of estimating the effort needed for testing the project. Whether we agree or not, some concrete spreadsheet examples are worth looking at.
  3. QCon – Trends in Agile Development by Kent Beck – srinip’s notes after the Kent Beck’s keynote presentation on QCon 2007 conference. Quite a typical Kent’s talk. (Kent Beck is the father of Extreme Programming method)
  4. Scrum – Use More Paper – James Brett arguing for the use of simple tools in Scrum

See also

If you happen to encounter another interesting content published since last Saturday, please, post links in the comments.

How to Avoid the Integration Pain

Integration, pre-integration and post-integration steps are the wrap-ups that have to be done after the “actual” software development and before the product can be shipped. These steps can include :

  • final big testing, ad-hoc testing by everybody available
  • different kinds of localization – translation of the program texts into many languages
  • writing documentation
  • testing of the translations and documentation
  • if you are developing a box product, designing and printing the packages
  • etc., etc.

Human Errors
It is a matter of fact, that when a human being performs any action for the first couple of times, a number of unexpected mistakes can happen. If so big integration steps are going to be performed only once in a project lifetime, no surprise things can go wrong even where they shouldn’t.

  • The word processor used for creating the documentation might suddenly not know how to sort the glossary in a particular language
  • The framework your application is based on might suddenly be unable to handle the right-to-left input
  • Some Chinese characters might mysteriously be replaced with the pseudo-graphical symbols
  • etc., etc.

Train yourself
The solution is simultaneously simple and complex. The only way to perform the actions flawlessly is to try it in advance and train yourself or your tools. If the localization, document or installer creation formatting are done and verified ten times a month, it is unlikely they will let you down at the moment of the delivery. Certainly it is rather difficult to convince a real person to do it all and some things like translation into 20+ languages might be impossible to do every week.

However, there are ways to automate the integration process: the installer, documentation, the actual installation and uninstallation  can be performed by a nightly or even hourly script that verifies that the correct files go into the right places, and maybe even do the basic user interface testing. Translations are more difficult to automate, but it many cases during the development process it is possible to “simulate” the localization process by supplying the random French or Chinese words just to verify that the strings look ok in at least few languages.

Then wrapping the application up would take a little more, than printing the packaging and burning the disks.

Unfinished work

half iPod

Agile processes recognize and try to effectively use the fact, that software creation is a difficult and not very predictable process. Therefore quite often teams applying agile processes end up with the not completing all the committed product backlog items by the iteration end. Teams just starting to employ Scrum or XP can sometimes end up with half of the items being not completely done. Naturally in such a situation people are tempted to finish the uncompleted stuff as soon as possible. Some think about extending the iteration length for a week or two, some think about marking the item half-done, adding half of its size to the team velocity and continuing with it during the next iteration.

As in pretty much everything in agile processes there is no universal truth and every team can develop its own style for handling the unfinished work. However, there are the default recommendations that work well for many teams. Changing the iteration length is rarely a good idea. It breaks the timebox, makes everybody think that “couple of days more is nothing serious”, while projects are always a year late one day at a time. Eventually it makes the team less predictable and forces the customer to trust your commitments less. Recording some velocity for unfinished item is also not too good idea. With unfinished item it is not always clear how much time is needed to complete it, the unfinished item cannot actually be used. Eventually it forces the customer to consider your velocity containing two parts: completed velocity and half-done velocity.

Back to the backlog

The usual rule that works for many teams is to put the undone work items back to the product backlog. If the item is half-done it is quite probable that it will be chosen as a top priority thing by the product owner (also remember that it is team who selects items to work on). However, sometimes with the latest market information at hand it might be more valuable to do another item first. Agile is not about the efficient “resource utilization”, it is about maximizing ROI – working as little as possible to get as good results as possible. Working on what’s the most important for the customer, not on what was the most important for him during the previous iteration.

What do you consider is useful to do with the unfinished work? Should there always be an attempt to split the potentially unfinished item into two smaller sub-items, so that one of them could be completed during the current iteration?

Picture courtesy of James Cridland @ Flickr

Product Owner Responsibilities

Product owner is one of the three Scrum roles. The responsibilities of the Scrum product owner are pretty much the ones of any businessman. Product owner decides what the project is all about, who is going to benefit from it and what the project priorities are. He is the one who secures funding, cares about the return on investment (ROI) and manages money.

The difference from more traditional approaches is in that agile methods actually allow take all the technical details away from the product owner and let him to focus on managing business value. Agile processes explicitly separate whats from hows. Product owner is the king in the what area and cannot influence the how area. Exceptions might exist as in the cases when additional funding is needed in order to improve the team velocity, but even in this case product owner is to see what value (increased velocity) the customer gets from the investment.

Put into a simple list, typical product owner responsibilities are:

  • decide on the project vision – who is going to benefit from the project and how;
  • secure funding;
  • continuously make decisions on the product priorities – what is more important with the latest information in mind;
  • continuously make decisions on maximizing the product ROI – make sure the features with the biggest benefit/cost ratio are developed first.

Weekly Agile Reading. Pack 5

Manually filtered top of the most interesting writing published since last Saturday. Of course, most interesting from my personal point of view.

Top writing of the week

See also

If you happen to encounter another interesting content published since last Saturday, please, post links in the comments.

XP Practice: Continuous Integration

Integration is often one of the most difficult moments in software projects. In traditional waterfall development, the integration phase at the end of development can take a lot of time and reveal many design deficiencies. Things become easier if the organization adopts the practice of bi-weekly, weekly, or daily builds. The more frequently the system is built, tested, and verified, the earlier problems and deviations are found.

As with many other Extreme Programming practices, Continuous Integration is taking a known good practice to the extreme level. If it is good to integrate often, let’s keep the code integrated always. The idea is to run the build and automated tests (at least the fast ones) whenever somebody checks code into the version control system. Usually it is done in automated manner by a tool such as CruiseControl. However, technically it can be done manually — some even find it beneficial and fun to do it without the automated tool support.


This page is a part of the Extreme Programming overview.

Agile Finland News

I am leaving in Finland and I am trying to follow the local agile community news. There is a local Agile Finland website, some free seminars with the world-class speakers and quite active discussion group. This week something significant happened there and I am happy to share the news that the community is going to be become more official and at some point (in a year?) we might even be able to organize a local conference!

– Agile Finland will be officially established as an association (ry)
– Agile Finland will organize a seminar in March with Mary Poppendieck
as the guest speaker
– Agile Finland will evaluate whether there is sufficient interest and
commitment to organize a yearly conference about Agile, organized by
an association free of any commercial ties (but with sponsors). The
aim would be to make this conference a focus point of the community
and an independent and reputable source for Agile knowledge world-wide.

This news might not be of much interest for those who never or rarely visit Finland, but to me it is rather exciting. What about the place where you leave? Is the agile community active there? Do you organize local seminars or gatherings?