Going from Scrum to Kanban near “release”

Question

I am working as Scrum Master on a large software project. We are currently running Scrum. We have about one month left in the development phase before we are supposed to end our implementation phase.

I am strongly considering switching to Kanban (Or GTD) for the last couple of weeks due to:

1. We have an absolute deadline
2. It is very hard to plan two (or one) week ahead now that we are this close to the end. The agenda, priority and outstanding tasks changes almost each day. We daily find new tasks we must remember to do before we can say our development phase is finished.
3. Kanban let me easier identfiy which tasks are waiting for reponse, which tasks are waiting for verification etc.

Anybody have experiences with this? Is this a good idea?

Our sprints are not entirely pontensial shippable increments (I know they should have been, but thats not what I want to discuss here)

Answer 1

Even though I can be considered a Kanban proponent I would think twice before making such move.

On one side:

• Kanban deals very neatly with rapidly changing task priorities. It is a good answer for environments where classic time-boxed approach, here: Scrum, doesn't work very well.

• Introducing simple Kanban system doesn't require much effort.

• Kanban itself isn't an approach to software development and/or project management and should be put on the top of something. However, it seems that you already have this "something" as, at the moment, you have your project organized.

On the other hand:

• Adding new tool to your toolbox always adds some hassle and, since you are at the end of the project, it may not be such a good idea to add the hassle now.

• Kanban, as pretty much any other tool, will give you value if and only if you get team buy-in before introducing it. I mean Kanban board is useless unless it is updated by everyone in the team regularly.

• If you are fluent with what you do, namely following Scrum, resigning from a part of it, namely time-boxing, may have a negative impact on team's productivity. At the same time it'll take some time before you get familiar with a new method, so there can be a question when you're going to get value of switching to other method.

All in all, I would definitely consider Kanban to such work as it gives you pretty good visibility and high flexibility in a situation where priorities are changing all the time. However, I wouldn't say that, in your case, it is a sure-shot decision. If you planned for it in a bit longer perspective it would be a no-brainer to try Kanban.

Personally, I'd probably try anyway and treat it as an experiment. If it works you keep doing it. If it doesn't you retreat back to what you are good at and eventually try Kanban in another project with a bit more preparation.

Answer 2

I would be hesitant to switching to a different methodology in the "crunch" of a deadline. Generally when you make this type of change the team slows down for a few weeks until they get into the groove. By the sounds of it you don't have that option.

Have you considered moving to a one week sprint increment given that your scope is in flux for the remaining work of your project?

As the scrum master have you talked with the teams delivering the work and ask them how they feel about the scope and what "could" be done to assist them in delivering on time?

Answer 3

Kanban won't help you to identify tasks, but it will make it easier to visualise and address them. I don't know how much you know about Kanban, but here are my hints and tips.

The biggest advantage for me is to make my Kanban board reflect reality. You may find it's more helpful to start by identifying and clustering the work that needs to be done, and then drawing the board up to reflect that work. If work is in different stages of verification, try to reflect those phases as close to production as you can - this will help you identify what needs to be done and who needs to do it.

Other than that, we finish what we need, and we don't start anything new - even if we need it - until we've finished the needed work that's already in progress. That helps us limit our work. It sounds like you've already exceeded any WIP limits that might help; however, you can work out who's busiest and help them (especially your testers!) and encourage the team to help each other finish before starting anything new. If you manage to get a flow of work going, put WIP limits in place at that point, but don't forget that the work needs to make it all the way through to production-ready.

If you're getting new tasks every day, you'll need access to your business experts more frequently than you used to in Scrum. Are they ready for that? You can have a separate cadence for engaging them, retrospectives, showcases, etc. - you don't have to be tied to sprints.

If at any point the team seems resistant it may be worth rethinking. Learning new things tends to slow a team down at first, and you may not have time.

Lastly, it may be possible at this late stage that nothing you do can result in a successful release - Kanban isn't a silver bullet. Best of luck with it, and I hope your project release is a pleasant surprise for everyone!