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…

10 Warning Signs, that your team is not self-organizing

How do you know that self-organization is working? The Bern Chapter of Scrum Breakfast Club looked into this questions, and identified the following warning signs (which I have taken the liberty of translating).

The team reports to the Scrum Master at the Daily ScrumPeople wait for instructions from the Scrum MasterTeam members don't hold each other responsible [for their commitments]The same impediment comes up twice"That's the way it is" => resignation"I" instead of "We"Flip charts are lonelyCulture of conflict-avoidanceDecisions processes are unclear, nor are they discussedPersonal goals are more important than team goals
To this list I would add my a couple of my favorites:
you don't see a triangle on the task board (not working according prioritization of stories)after the daily Scrum, people return directly to their desks (no collaboration)there are a least as many stories in progress as team members (no pairing)
P.S. You can join the …