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 -
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 -
- Production defects get the highest priority and are directly inserted into the Ready column at the start.
- 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.
- 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.
- 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.
- 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 -
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 -
- Start with what you have today (current workflow and actual work being done)
- 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)
- Manage the flow of work
You might end up with a board that looks like this -
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!
