Scrum and fixed price: impossible?

When you want to introduce Scrum in a fixed price project, the majority of people you’re talking to about this idea will immediately say that it’s impossible to use Scrum in a fixed price project.  Do they know that for sure? Did they ever try it? The answer to both questions is ‘NO’, no doubt about that. So why does everyone accepts that this combination is impossible?

Well, the answer is quite simple in fact. When people think about fixed price, they implicitly think about fixed budget, fixed time and fixed scope. And yes it’s true that a fixed scope and Scrum can’t go together. That’s quite obvious because one of the base principles of Scrum is that scope just can’t be fixed. That’s the idea behind the product backlog: at the beginning of a sprint, the team commits themselves to implement the most valuable stories at that moment before the end of the sprint. But the sequence of stories and even the content of the product backlog -except the stories the team is committed to-itself can change at any time.

But fixed time and fixed budget are absolutely no problem with Scrum. An argument I hear a lot is that you can’t set a deadline at the beginning of the project because you don’t know what will be delivered in the end. Because you don’t know what will be delivered in the end, you don’t know when it will be finished and you don’t know what will be the total cost of the product.
Well in my opninion, in a traditional waterfall project when people negotiate about what will be delivered, when and how much it will cost in the end, they also don’t know how long it will take and what it will cost. That’s why most sales people and project managers multiply the initial estimations with a factor 3. And even then, when the deadline is reached, still a lot of issues need to be fixed and the customer will have to pay a lot for that.

Another fact is that the customer can’t predict the future. It’s stupid to think that a person can know all features he wants in a year. Of course his mind will change! Of course he will change his mind when he tests the product! And that’s what most consultancy companies know. So they can make a lot of money by implementing change requests. So the fact that you can’t predict the price of a product on beforehand is just true. But there’s no difference between waterfall and Scrum projects…

The problem is that people want to use the same practices in the offering phase with Scrum as they are used to use with waterfall and that’s a wrong mindset. You can already create a general coarse grained product backlog at that time. Based on that backlog, a minimum set of functionalities can be defined and budget and deadline can be defined.
One can make use of the principles ‘money for nothing’ and ‘change for free’.

Change for free means that the customer can replace stories from the backlog with other stories with the same amount of storypoints at any time without any extra cost. This guarantees that in the end, a customer will get the product he wants and won’t pay more for it than initially estimated.

Money for nothing means that the customer can say that he has enough functionality delivered at any time he wants, even when not all functionalities from the initial set are delivered. The customer will have to pay a fee to the consultancy company but in the end the price per functionlity will be cheaper than what they agreed upon.

So to conclude: a better name for fixed price would be fixed budget. And fixed budget and even fixed time can go hand in hand with Scrum. The best Scrum contract model is called ‘Variable scope and cost ceiling’.

How to make Scrum fail

A lot of people heard about Scrum, some of them know what it is, some of them tried it already and for some of them it failed. In this blog post I’ll enumerate things you should do if you want your Scrum project to fail. For those who don’t like failure, keep on reading the descriptions below each topic, they’ll help you to make Scrum succeed.

I won’t cover Scrum basic principles like sprints, daily standups, task board and burndown because I expect you know them. Those are things you must do if you’re implementing Scrum, I think that’s quite obvious.

1. No or bad retrospectives



How would it be possible to make things better if you’re not looking behind? Retrospectives are required because there every team member can communicate what went good and what could have been better. And of course you’ll have to learn from your mistakes. If that isn’t done, retrospectives are useless.


2. Bad Product Owner



The Product Owner should be available at any time. He should participate in standups, retrospectives and sprint planning but he should not estimate tasks during sprint planning because estimations are the team’s responsibility. He should be able to prioritize the backlog by business value. For this, he needs to have a vision, a business plan and a release roadmap. He should define the stories in a way that they are clear enough for the team to understand what they mean. On-going changes shouldn’t be present in the Sprint Backlog.

3. Bad Scrum Master



The Scrum Master should not become  a team administrator. The team should be self-managed. The Scrum Master should not lead but steer the team when needed. He should make final decisions if team members can’t agree. He should be able to make a prioritized impediment list and to remove those impediments as soon as possible. He should keep the team focused and try to improve things constantly: things can always get better.
Tasks should not be assigned to people, they should pick them up themselves.

4. Scrum Ceremonies are taking too long

In stand up meetings everyone should say what he has done, what he will do and what’s blocking him. That’s all that should be said. A stand up meeting should not be a social talk and you don’t have to provide detailed information. If one needs detailed info he can get it after the stand up. Stand ups shouldn’t take longer than 10 or 15 minutes depending on the team size.
Retrospectives and sprint planning meetings should be timeboxed. Stick to the essence of the meetings. Scrum should be fun but it’s not meant to be a playground.

5. Wrong definition of done



At the end of each sprint the produced software product should be production ready and thus demo-able. This means that it should be tested, not only by unit and integration tests but also manually. And of course the developers should know about the exit criteria the testers are testing against or there’s a mismatch between automated and manual tests.

6. No velocity tracking

Team velocity should be tracked. The Scrum Master must undertake some action if the team is slowing down. He must find the root cause by means of the 5 why’s method or Ishikawa’s fishbone diagram.

7. Waterfall within sprint

It’s better to have 75% of the stories 100% done than having 100% of the stories 75% done (cfr. definition of done). Not a single person but the entire team owns the story and testers should be part of the team.

8. Technical debt

Technical debt must be avoided because otherwise more defects will appear at the end and last iterations would produce less new functionality while every iteration should produce as much functionality as others. Refactorings (and redesigns) should be done immediately when they are needed because they cost too much and take too long if done at the end. Bugs should also be fixed as soon as possible.

9. Interruptions/PO bypassed

The team should stay focused which means that too many interruptions are bad. One can ask for support of course but new features should be requested to the product owner. He should add it to the backlog and prioritize it again. If it’s an important feature, the team can already deliver it at the end of next sprint. One should not send feature requests to team members directly.

10. No analysis/documentation

Scrum does not mean that no analysis should be done or no documentation should be written. The way of doing analysis and documenting is just a bit different: it’s a continuous process. Stories in the backlog should be clear enough for the team to split it up in tasks and estimate them during sprint planning (= at the moment the story will be implemented in the sprint, it should be detailed enough) . This means that stories shouldn’t be too detailed from the beginning of the project (but still clear), but stories need to be estimated in story points when creating the backlog.

My advice/conclusion for those who want to try Scrum and want to succeed with it:

Scrum is not a silver bullet. It’s no methodology that defines a lot of rules. Instead it’s a framework which defines some best practices. Of course you’ll have to adopt the basic principles to make it work. But how some things are filled in (when do we do standups, how does a task card look like, …) is up to you and can differ from project to project.

Scrum is a completely new way of thinking and mind-set shifting. It is not just a list of practices: if you “stand-up” it doesn’t mean you do Scrum …

References:

• Agile Manifesto
• How SCRUM works
• 5 why’s
• Fishbone diagram
• Implementing Scrum