Skip to main content

Italian Agile Day: Fixed Price Projects

Yesterday it was my privilege and honor to give the keynote speech at the 6th Italian Agile Day. 400 Agilists gathered at the Savoia in Bologna to share their experiences. And there were even curious skeptics from company management, who wanted to find out about about Agile and whether it could help their problems. Lots of energy.

I also found some surprising obstacles. I was very surprised about the class warfare tones I heard in the discussions. Much of Italy's best talent goes looking for work in London or Munich where their work is more appreciated: the pay is substantially higher than in Italy. One of the cornerstones of Agile is the idea of building trust, e.g. between the developers who build the product and the managers who request it. I wonder how well this culture will do in an atmosphere of contention over pay, benefits and respect.

My favorite quote from the Coaching Workshop: "My name is Luca and I am a Waterfall-aholic". "Hello Luka" everyone replied. Reminded me of the sharks in Finding Nemo.

My talk was about doing fix priced projects with Agile. I believe that Agile is the only way to go for a fixed price project. (I believe there are better approaches than fixed price projects, but that is another story.). It's very simple. Under Agile, a project is 50% complete when 50% of the features have been completed. With non iterative processes that don't regularly produce a product in a stable state, you just don't know how complete it is.

Completing fixed price projects is a lot about risk management, so in the presentation, I talk about how to identify and minimize the risk in the bidding, planning & execution stages of a fixed-price, fixed-scope software development project.


Unknown said…
I've eared the discussion with "Mr Bad Guy" asking how to manage an unpredictable need of productivity from one year to the other of 10 times the current productivity. I think is this is not a rational question (does exist a rational manager?), but I've never eared a rational answer. I suppose our duty as scrummaster/tech lead/whateveryouwanttocallme is to find a rational way to answer this unrational question. The first question about this argument that jumped in my mind is: "What is productivity?", old fashion number of lines of code?! Number of classes? Number of implemented features?
Cohen in his book about estimating project suggest that the only way to estimate long term project is using Velocity, do you think this concept should be applied scaling 'Productivity'?
If scrum or in general Agile methodologies are so "Productive" why major actors such as Accenture, IBM or the one who goes around with trendy ties, seems not very interested (they doesn't came to the Agile day!) to Agile methodologies?
Peter said…
Hi Balza,

Good questions! I subscribe to the belief that productivity is measured in

1) ROI (X per 100K€ invested, where X is whatever you are trying to accomplish, e.g. revenue, users on your web site, cost savings, whatever -- as long as it's a business goal) and

2) defects per 100K€ invested.

X should go up and defects should go down. Depending on the size and flexibility of the organization, you might see results in 3 months, but it may take longer.

A close second as a productivity measure is number of releases per year. A common result of a Scrum Transition is to take a team which wasn't able to release software in 2 years, a get them able to make a release every 3 to 4 months.

What about IBM and Co? Many big companies do Scrum with various levels of commitment. SAP, Allianz Germany and Nokia come to mind. You might what to ask Agile thought leader Scott Ambler why agile is not more present at IBM.


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…