Introducing scrum in a waterfall environment

Question

We have a wish to try to introduce Scrum in one of our development departments, but have a number of challenges we are not sure how to solve. If someone could point us in the right direction it would be very nice.

We are producing a very complex enterprise product and we have 2 product owners, 10 developers and 4 testers.

We have 4 releases each year which consist of 20-30 change requests ranging from 10 - 1500 hours each. We are bound by a fixed price contract which requires us to have a fixed deadline, scope and price on each of these changes. Besides the change requests we also do bugfixing. The release cycle is fixed and we have to deliver installable packages every 3 months + a number of service packs and hotfixes.

Some of our challenges we are facing are:

• We have many small changes which only take a short time for one person to do.
• We have some specialized technologies that only a single person knows and can't easily be knowledge-transferred.
• We have a lot of urgent hotfixes that require immediate fixing.
• We have fixed budgets on each change and have strict rules on warning and raising budget as soon as we see it.

Questions:

• How can we handle urgent hotfixes in the middle of a sprint?
• How do we handle the specialized technologies developers which often has tasks on a lot of different change requests - which would mean they need to be in multiple teams? Or small 1 man teams (which makes no sense)?
• How is the delivery manager integrated with the Scrum teams, so we can report progress, budget issues etc. with the client? Note that the product owners are not capable to do this job.

Answer 1

The biggest clash you'll see is likely with the fixed scope and deadline. Locking in those two will only leave you open to modify resources and quality. Changing team compositions generally is not something you want to do often but if you have enough breathing room there's no reason you can't say use one team on the project all the time and the other only in the beginning of the release cycle until you are reasonably sure you can accomplish the commitment. But all of this would be an issue with waterfall as well.

How can we handle urgent hotfixes in the middle of a sprint?

This is not uncommon and there have been other questions about it here. In short: Keep a separate pipeline of urgent bugfixes and just do them as they come up. Your velocity in scrum will suffer temprarily but again this is nothing that wouldn't affect you in waterfall equally. If you're getting swamped with bugfixes then you can renegotiate the scope of the sprint

How do we handle the specialized technologies developers which often has tasks on alot of different change requests - which would mean they need to be in multiple teams? Or small 1 man teams (makes no sense)?

Ideally you should be working towards cross training in these disciplines. (I always bring up the 'hit by a bus' scenario for such situations) How to integrate them depends on the nature of their work and how much of their time is consumed with specialized work.

• If your changes can easily be given to them as a whole to be completed that would favor integrating them as normal team members.
• If they provide their specialty only as small parts of many different items but you can assign all of those changes to one team, then again you can integrate them as normal team members.
• If they have a hand in pretty much every change and have almost not capacity remaining for "normal" development then it gets more complicated. You should probably keep them outside the normal scrum teams then and use them like you would an external resource but aim to cross train their skills with the goal of integrating them into the teams.

How is the delivery manager integrated with the scrum teams, so we can report progress, budget issues etc. with the client? Notice that the product owners are not capable to do this job.

Officially, not at all. All the information necessary for this role should be available from the normal scrum workflow so theoretically any interested party with access to the scrum board, burn downs etc. should be able to serve as this role. The PO's would be the logical fit due to their existing relationship with the customer. Why are they not capable of this? If it's an issue of lacking insight into the project then that can be remedied.

---

Overall though it seems to me you are operating inside a very tightly controlled environment. Transitioning to scrum AND keeping your existing controlling intact is probably going to cause a lot of friction and duplicate effort. This is IF you have the organisational support to pull it off in the first place. I'm not sure how much benefit you stand to gain from such a switch unless your customer is open to chaning to a less bureaucratic contract model as well (Like "Money for Nothing, Changes for Free")

Answer 2

How can we handle urgent hotfixes in the middle of a sprint?

By adding them to the Sprint Backlog. Realize that this is an impediment to the value of Focus and can result in inefficiencies due to context switching.

How do we handle the specialized technologies developers which often has tasks on a lot of different change requests - which would mean they need to be in multiple teams? Or small 1 man teams (which makes no sense)?

Not everyone can be be an expert in everything, nor should they be expected to be. However there needs to be overlap in knowledge. (Related: Paint Drip People) What happens if that sole "expert" is hit by a bus?

How is the delivery manager integrated with the scrum teams, so we can report progress, budget issues etc. with the client? Notice that the product owners are not capable to do this job.

The delivery manager would be updated via transparency, the Product Owner, Sprint Review, etc.

Read The Scrum Guide and understand the framework; I do not believe this is the best solution for your situation.

From a process perspective, Kanban would probably be a better choice based on the information provided. Hot fixes can easily be prioritized to the top of the queue to be pulled. Different application functional areas may be able to be addressed through separate Kanban boards. The delivery manager is minimally affected.

From a technology perspective, break the monolith into many smaller, focused applications which interact through APIs. This also has the advantage of modular solutions that sales can exploit.