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.



Comments

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?
Thanks
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.

Cheers,
Peter

Popular posts from this blog

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…

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…

Five Simple Questions To Determine If You Have the Agile Mindset

My company has started a top-down transition to Scrum and Kanban. Will that make us an Agile company? About 2 years ago, I attended a conference hosted by the Swiss Association for Quality on the topic of Agility. As a warm-up exercise, the participants were given the 4 values of the Agile Manifesto, then asked to arrange themselves in space. How Agile is your company? How Agile do you think it should be? Very Agile on left, very traditional on the right. There was a cluster of people standing well to the right of center. “Why are you standing on the right?” It turns out that they were all from the railway. “Our job is to run the trains on time.” They were uncertain whether this agility thing was really aligned with their purpose.
Is Agility limited to software? Steve Denning has collected the evidence and laid out the case that Agile is not limited to software, nor is it merely a process, nor is it something you can do with part of your time, nor is it something you can have your …