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.


balza 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 …

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…