Succeeding with Innovation and Maintenance

By Roman Pichler, 6th August 2013

Innovating existing products is a common challenge for many enterprises: New features are developed to enter a new market segment, to increase the market share, or to catch up with the competition. But while the product is being updated, small improvements and bug fixes have to be made to maintain the current version. This post shares my thoughts on balancing the innovation and maintenance work.


Creating new features and maintaining existing ones are different types of work: The former requires dealing with uncertainty, acquiring new knowledge, and carrying out experiments. Making small, incremental changes entails few unknowns, and the work should be done with minimum effort and no failures or mistakes. I therefore prefer to apply different approaches for the two types of work, as the following picture illustrates:

InnovationAndMaintenance

The picture above shows two workflows: In the upper workflow, a feature team turns new features into a new product version using a cyclic process. In the lower workflow, a maintenance team fixes bugs and carries out small enhancements using a linear process.

The bugs above are taken from: http://yprl.vic.gov.au/sites/default/files/uploads/blogs/mill-park-news/ladybugs.jpg

Separate Teams

To deal with innovation and maintenance work for the same product, I have a preference to work with a feature and a maintenance team, as this creates focus and it reduces task switching. It allows the tem members working on new features to carry out focussed experiments, and it makes it easier for those doing the maintenance work to fix the bugs quickly. If you work with one small team, then consider forming two sub teams – particularly once the maintenance effort consumes more than 25% of the team’s capacity.

A danger of employing separate teams is the creation of a two-class society with the cool feature developer doing rad innovation work, and the poor old maintenance guys slaving away at mind-numbingly boring bug fixes. To mitigate this risk, the feature and maintenance team members should rotate regularly. This also encourages knowledge sharing and collective ownership.

How often and how many people rotate is best determined on a case-by-case basis. For instance, two to three people could swap places at the end of each week or at the end of each fortnight, depending on which solution best balances team cohesiveness and knowledge sharing.

Separate Processes

Innovation and new feature development requires the ability to develop and test assumptions, to gather and analyse data, and to leverage the new insights. In other words, the feature team requires an iterative process such as Lean Startup or Scrum. (Please see my post “New Product Development with Lean Startup and Scrum” for a discussion how the two approaches can be combined to create new products and features.)

Making small enhancements and bug fixes, however, does usually not require a cyclic, feedback-driven process, as there is little uncertainty present. Instead, the changes should be implemented and deployed in a fast and efficient manner. A linear, Kanban-based process is ideal for this job in my experience.

As a consequence, you may want to use a Product Canvas to capture the new features, and a product backlog to describe and manage the maintenance work. Similarly, the two teams should use separate boards: one for the new feature development, and one for the maintenance work.

Joint Ownership

While using separate teams and processes for feature development and maintenance work can well be beneficial, separating product ownership is something you should avoid. I have intentionally positioned the product owner between the two workflows in the picture above, as the individual should own the existing product and the new product version. As the product owner, you should hence balance the two concerns and decide how much effort is spent on new feature development vs. maintenance in a given timeframe.

As the product owner, carrying out new feature development and maintenance work in parallel may be your only choice. But maybe you are able to focus on maintenance work for a certain period and do what I sometimes call a “Snow Leopard”: a maintenance release dressed up as a new product version. Use a product roadmap to manage the two types of work across product versions, and to document how much effort you intend to spend on maintenance.

If dealing with new feature development and maintenance is too much work for one person, then consider employing a product owner team with a chief product owner, or break up your product into vertically aligned parts with a product owner looking after one of the newly formed sub-products. Whichever solution works best for you, ensure that there is joint ownership so that both concerns are managed well.

Summary

The following table summarises my recommendations for managing new feature development and maintenance work:

InnovationAndMaintenanceSummary

You can learn more about succeeding with innovation and maintenance work by attending my Certified Scrum Product Owner training course.

Source: http://www.romanpichler.com/blog/innovation-and-maintenance/

RSS Feed

Tags related to this post:


11 comments on “Succeeding with Innovation and Maintenance

  1. Thomas

    Hi Roman,

    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

    • Roman Pichler

      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?

  2. Huimin

    Hi Roman,

    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.

    • Roman Pichler

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

  3. Leonardo Campos (@leonardocampos)

    Hi, Roman, we have a pretty big Agile implementation here, with several teams facing all sorts of problems, including the one this post talks about.
    Since the teams self-organize themselves, we’ve been able to see that some teams took your approach (subdividing) and some of them designed a Scrumban implementation, with different rules for differnt types of work and in some cases different classes of service.
    Both work well, but it seems to me that the Scrumban implementation had created better TeamWork and was better able to cope with variance in demand and its priorities (specially regarding bugs)

    Tks,
    Leo

    • Roman Pichler

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

  4. Mauro Bagnato

    Hi Roman,
    I’ve some concerns regarding the separation of feature and maintenance team mainly due to what you could lose in terms of:
    1) Product ownership. Having a 2e2 product responsibility (from idea to market) gives teams a very strong sense of product
    ownership and thus empowerment and motivation
    2) Waste reduction. Having teams working on feature and maintenance eliminates the handovers.
    3) Learning. Having teams working on feature and maintenance activity gives people the chance to increase competences
    (Consider that there’re many ways to reduce the task switching effect)
    Mauro

    • Roman Pichler

      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.

  5. Kristin Runyan

    Roman – our experience was that the New Feature team was working on a significant effort where the sprints build on one another so they wanted to stay together for an extended period of time (like a year) and this led to the Maintenance team feeling like second class citizens. Do you really think ownership can shift frequently? If so, are there some best practices to make it more manageable? Thanks and I am a big fan!

    • Roman Pichler

      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?

  6. Joerg Ihle

    Hi Roman,
    in already “restructured” teams, where only the specialists in their areas are left over, the split in feature and maintenence team is often hard to manage due to chaning mainetence effort and code ownership. In my expierence a mixed Kanban/scrum approach within one team is an alternative. dedicated effort for the Kanban tasks to not harm the scrum availability and velocity …
    BTW: your posts, presentations, etc are really good !
    best regards,
    Joerg

Leave a Reply

Your email address will not be published. Required fields are marked *