Using Scrum in fixed-length / patch projects?

Question

I am new to Scrum and want to implement Scrum in my company. Getting a buy-in is not a problem, it is my company and the developers who are more than happy to work this way.

The problem is that 75% of our income comes from fixed-length / fixed-price projects.

Ken Schwaber in his book "Agile Project Management with Scrum" covers the topic of tendering for fixed-length / fixed-price projects in the appendix at the end of the book.

After a long search for the soul, Ken realized that Scrum is only useful in this situation, when you can convince a potential client to think differently. The client must be in order with great uncertainty (about the final cost and the final delivery date) in exchange for receiving something much faster, which may be acceptable, and the ability not to perform each function can save them money.

I'm not sure if this is the only way to implement Scrum in projects with length / fix correction.

I want to know how others successfully bid and benefit from length correction / correction projects.

Answer 1

Yes. I think you can. See Waterfall not working .

“Getting out of the field with a fixed price” is not so difficult to conduct. Customers also saw glitches. They saw the long delays associated with the document requirements. They saw endless change orders. They don’t like it either.

But, if you are sure that the client does not want to manage things in different ways, you need to take a hybrid approach.

Pricing is not Agile - it cannot be. You must, in order to appease irreconcilable customers, make a price. Obviously, you will have some kind of master plan to justify the price. Basically, all you want from this master plan is lag. Other details are nothing more than hypothetical planning assumptions. [They always plan assumptions, but some PM believe that the original plan is a divine oracle to be followed. This is not true.]

Then you take small, quick steps. You must engage users early and often, and you must allow conversations. But! Each change in lag should be considered as a potential change in volume, value or schedule.

At the end of each sprint, any lag changes could potentially be a project area and contract changes.

Agile lowers your risks because you are actively working with area changes earlier and more productively with your client. Trying to identify (and freeze) the scope is not an additive, so just stop doing it. Treat the scope as an assumption, and make changes to the scope on each sprint.

Answer 2

I'm not sure about bidding and profit, but the scrum methodology can certainly be applied to a project with a fixed length / price. If the requirements are known and reliable, they can be put in the backlog of the product, and the sprint can be planned in accordance with the requirements and deadlines. You can still take advantage of the daily scrum meetings, burnout schedules, etc., to make sure the project remains on track.