Thanks for your feedback and question Prabhu. The following measures will help you address the issues you raised:

• Break down the maintenance tasks so that they can be completed within one or two days.
• Encourage pair programming to share knowledge (and increase code quality).
• Ask one maintenance team member to stay on and phase in new members.
• Inspect and adapt the process in the sprint retrospective.

Hope this helps!

Hi Roman, this is a great article and a good approach. I have a question on swapping members between new development and maintenance. If we swap the members working on new development to maintenance, what happens to the tasks they are doing and its continuity ? If they are in mid of some tasks and if they are swapped, would a knowledge transfer be able to enable other person to carry on from where it was left? In this case, should we plan for swapping at the end of the sprint, so the in-progress tasks are logically finished ? Can you please guide me on this ?

Hi Thomas, Thanks a lot for your comment and for sharing your approach. Sounds like you have found a great way to deal with innovation and maintenance work. The only downside I can see is that urgent requests cannot be handled immediately (unless they are raised on a Friday). How do you handle those?

Your splitting is interesting.
I’m nevertheless not convinced about switching people from team because in the end it adds up knowledge transfer time…

What we ended up doing in my company is to have 1 single team which work on new features (via sprint) 4 days a week and the 1 day left is reserved for support and maintainance.
With that, we have always up-to-date people and also we don’t wait for a sprint to end to do maintainance that can’t wait.

Thanks for your posts that are very well written and cleanly presented.

Best,
Thomas

Thanks for your feedback and for sharing your experiences. Glad that you have found the post helpful.

Really like the highlight of choosing different processes based the nature of work and different goals of teams. We recently split our product team, and restructured us around 2 different business objectives. We let each team to decide their own process. It worked out pretty well.

I shared this article around my team to add to the conversation, great stuff! Thank you.

Hi Kristin, Thanks for your comment and feedback. I think it’s great when a successful team can stay together for an extended period of time. But I would also suggest that the team is responsible for maintaining the software. Is there a specific reason why this was not feasible for you?

Hi Mauro, Thanks for your comment. I share your concerns if separate feature and maintenance teams are used. I suggest, however, to frequently rotate the team members thereby encouraging joint ownership and learning.

Hi Leo, Thanks a lot for sharing your experiences. Did the Scrumban teams work on more mature or stable products?

Tks,
Leo