6

I'm a Scrum Master of a team that is working on developing a software & maintaining its production issues.

I'm planning to combine Scrum and Kanban. Where Scrum is for development, and Kanban is for production support, as suggested on many posts here.

I started with creating two separate boards for the product, but then I realized I don't know if there is a designed method to coordinate developers time/capacity between these two boards. I thought of following the "Batman Approach" where one developer is dedicated to production support each sprint, and it rotates to share knowledge between team members. Would that work?

  • Are there non-developers involved in support or is the kanban only used when developers are involved? – JeffO Dec 18 '16 at 12:00
  • @JeffO only developers, as it will only have software-related reported bugs. Of course it will be filled by the support guy. – Shadin Dec 18 '16 at 17:20
1

The beauty - and the true utility - of Kanban is that you don't have to separate out Scrum from it. You can apply Kanban on your Scrum-driven work as well as use it for your production support work.

The key thing is to "start from where you are" as Kanban says, visualize your work, implement WIP (Work in Progress) limits to encourage and improve flow, and overall, make changes as needed to your overall process including resource assignments, etc. so that you have better business outcomes.

We ourselves are a product team and do exactly what you do - build multiple products as well as support our internal and external production environments. (Our staging server is our internal production server so before we make a real production release, we put a new release on staging where everyone hammers it for a week to 2 weeks, we iron out issues and then make a release to production.)

For the team, we have a single board with multiple swim-lanes, for different types of work - such as different products (we support 2 specific products) as well as other work that we get asked to do such as customer-specific data queries as an example. We use our own product (SwiftKanban) for managing our work of course :)

To design our board, we simply applied the actual workflow our team uses once a user story or enhancement or a defect (both production or internal) is pulled by a team member. We use a Test Driven Development model - and both our products follow the same workflow. Here is how our board looks -

enter image description here

I am not sure how your product dev releases are organized but for us, we make a SaaS (external production) release every 3-5 weeks. During this time, our team works on both new features (User Stories and Enhancements as we call them) as well as Defects (internal/ customer reported) as also what we call "Engineering Tasks" which are more like tech debt items such as perf or security related. We don't do sprints. However, since our release cadence can be as short as 3 weeks, we are not really that different.

The key set of policies we follow are these -

  1. Production defects get the highest priority and are directly inserted into the Ready column at the start.
  2. User Stories and Enhancements flow from an upstream board that's used by our Product Owner to prioritize the features we want to take up in up to the next 4 releases. These items are pulled into our Dev Board during a Replenishment Meeting we do every 2 weeks.
  3. While Product Owners (Product Management) gets to decide the set of features we finally select, we also have Sales, Support and Engineering weighing in with their priorities such as customer-requested features or critical engineering tasks to be done. We have a rough allocation of the Ready column capacity made to each function - tho' we are not too strict about enforcing them.
  4. We take our WIP limits seriously - both Minumum and Maximum - and make sure work keeps 'flowing'. We track reason codes for why WIP limits may be exceeded and also, why cards get blocked - and do some root-cause analysis based on that about once a quarter.
  5. We make releases every 3-5 weeks on average. The release includes both features and bug-fixes as well as any engineering driven changes we complete during a release cycle. So, our product dev and production support releases are one and the same - except of course if we had a critical server crash type of a problem that required a "hot-fix". Fortunately, we have not had too many of those!

So far, in the last about 5 years, our Kanban board has gone through several revisions as we have tweaked our processes. A key area of (re)organization has been our upstream work - of identifying, prioritizing and final selection of features - which we have learnt is a critical aspect in the functioning of an agile team - or any team for that matter!

Each product has its own swim-lane - and be it new features or production-support related work, it flows through the same lane. Based on priority - and developer expertise needed/ available, work is pulled and completed.

Overall, I'd advise that you start with a Kanban board that reflects your current actual process. Since the same team is working on both enhancements as well as defect-fixes, you might want to have a single Kanban board and different colored stickies to show the different types of work. At best you might want to separate it into 2 swim lanes for new features vs. production - since that appears to be your team's way of thinking about the work they do. Later perhaps, you could merge the two lanes if it makes sense.

In our case, we have release and sprint planning capabilities built into our product, so we use that for planning releases (and we can filter our board and metrics such as velocity/ throughput, etc. by sprint/ release as needed). Depending on what tool you use - or a physical board - you could just tag sprint/ release ids as stickies on each Kanban card. As each sprint or release is done, you will get to see that visually on the Kanban Board as the sprint or release bunches up on the right side of the board. You can track your sprint/ release velocity easily using something like this -

enter image description here

If you just follow the 3 steps as the Kanban Method by David Anderson recommends (highly recommend reading his book if you haven't yet!), you will be able to design the Kanban board for all of your team's work -

  1. Start with what you have today (current workflow and actual work being done)
  2. Implement Pull and WIP Limits (tho' WIP limits can come later after you have had a chance to observe your team's work for some time)
  3. Manage the flow of work

You might end up with a board that looks like this -

enter image description here

Or you could start with something much simpler as well - a single lane board with all work in it!

You are welcome to check out our Kanban guide for more on Kanban. Finally, there is also a very systematic approach (somewhat advanced) to doing Kanban board design by Mike Burrows - called STATIK - or Systems Thinking Approach to Implementing Kanban - that you should also readup about in his book Kanban from the Inside.

HTH!

  • 1
    Truly appreciate your thorough response! – Shadin Dec 24 '16 at 17:46
  • You are very welcome! – Mahesh Singh Dec 24 '16 at 18:26
1

Tracking both isn't really the problem once everyone learns both systems. The problem is, how do you equate support work done (tracked on a Kanban board) with the work expected to be completed in a sprint? Or you may discover there are so few support items, they don't interfere at all.

There are many concerns that this can address, but until you identify what is more important, it's difficult to design any system. Here are some examples:

  1. Support Items are Top Priority - The Kanban board is perfect for this. Everyone can see new items as the pop up. You know who is working on what and whether or not it has been completed. Fewer items slip through the cracks. Team members know they should stop what they're doing and pick up an item on the board ASAP.
  2. Support / Production Time Prediction - When you know this, you can adjust how much work you can expect to get done during future sprints. Can it help you adjust staffing? You have to be able to determine if this item was recognized at the beginning of the sprint, how many story points (or whatever) would we have given to this item? If I fix a problem on a Monday morning when I'm half brain-dead, ideally I would equate it with the amount of work I could have honestly completed (not much).
  3. Adjust Sprints on the Fly (Now we're really being agile.) - For some sprints, the amount of support completed could be negligible. Maybe a developer was able to skip some meeting, so no real loss of development time. Everyone now knows Developer X is working on a support item, so I can take something off her list if I have time. For other sprints, the support work may pile up so much almost the entire thing is scrapped. The work on the Kanban board becomes a footnote to what happened.

You're going to have to adapt this to your teams and projects and adjust as you go along. Dedicating developers to support could work if you feel there is a certain amount of predictability to support volume. I may not mind doing support for the whole week if I know I'm not expected to produce anything else. Being interrupted can turn into a soul-sucking experience. The temporarily dedicated support person(s) may not always be available (illness), so be prepared to adapt.

Through the course of a project, the estimation should improve and you have enough data in your sprint along with your support Kanban to learn how to balance both of them. After all, that's the age old problem you're trying to solve.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.