I have previously been the Scrum Master for a team that was developing two products. The covered the same market space so it was understandable we would work on both of them.
We created roadmaps and developed stories independently and then combined them into a single backlog. That way we always knew which product took priority and could select items to work on appropriately. It was much more work for the Scrum Master and Product Owner, but made it easier on the rest of the team since they just viewed each story as a bit of work and didn't give much thought as to which product was more important.
The biggest challenge for the Product Owner was nailing down the priority between stories. One product had a larger installed customer base, but was in sunset because of technical limitations and the other had a long list of "must have" features. It was a balancing act to keep getting out new releases of the old to hang on to existing customer while providing new features in the new to attract new customers and (more importantly) get existing customers to migrate. In the end he had worked it out so the backlog was a pattern of 4 product A stories followed by 1 product B story. We had played with it a lot to that point and I know that since I've left they are still making adjustments based on the business needs.
His other big challenge was determining what frequency he wanted to release updates. Although both products were kept shippable at the end of iterations, it became as much a strategic decision of how releases would appear to the customer. In the end he settled on quarterly releases of the new and old, with the old coming out a week or two later. I can't say if that was the best decision or not.
In my role as Scrum Master, running interference for the team from outside forces was more complicated as people outside the team were frequently a positive influence on one product, but a negative on the other. For example, people we needed to consult with regarding the technology in the old product would sometimes try and make demands on changes to the new product in the middle of an iteration. So I needed them to sit with the developers, but keep focused on why we had them there.
There was also a lot of work in getting the team to see value in working on either project. While there is always better and worse assignments within a project, getting someone to pick up a dull task in a dying project for an iteration means you really need to sell the value of the work. Sometimes you had to highlight the dollars involved in the change.
Another issue the popped up every few months was a suggestion from upper management that we split the team into "vision" and "maintenance" teams. This was a group where people had been members for 3-10 years and they were suggesting splitting it just to make the resource allocation look better on paper. In reality, it would have hurt to take anyone off the maintenance permanently and by the same token not making someone part of the vision would have left them jaded or worse. I was constantly selling the value of the team as a whole was greater than the sum of its parts.
Estimating stories was difficult whenever we were picking up an area that hadn't been touched in a long time. It became difficult for the team to remember easily what other work had been done there and how they had sized it previously. This just meant that before estimation meetings I had to spend a few hours digging around through our old iterations to find similar stories so I could remind them of what else we had done in that area. How it had been sized and how the story had worked out in reality.
Another mechanical issue with the Scrum was running daily stand-ups in a way that kept it clear which product we were talking about. We adopted the approach of talking down through the stories rather than around the room to keep it clear. This was especially important when both products were updating the same technology in the same iteration.
At the beginning of the sprint there is nothing to test yet
Really? You have no requirements to validate? No discussions to have with your customer? No wire-frames to evaluate? No test plans to think about?
at the end of the sprint there is typically nothing or very little
left to develop/fix
I have never been in that place in a project. No more work to do? There is always something. Are all your tests fully automated? How is your CI looking? Could the database access layer be refactored to be simpler? And I've never worked on anything with an empty bug list and backlog. What did your developers used to do in a waterfall testing phase?
I know some people get very religious about what is and what is not 'SCRUM'. I couldn't care less about that. But I think you have two issues here:
A 'traditional' QA department that test code once it is 'finished' by developers rather than working with customers and developers to make sure you are building the right thing as well as building it right. Take a look at the agile testing quadrants by Lisa Crispin. The best testers are involved in every stage of the software development lifecycle and the best developers write their own tests.
Trying to stick too closely to a SCRUM timetable of 1 week / 2 week sprints without having a prioritised and sized backlog that is split down into tasks that are easy enough to complete within a short amount of time within a single sprint. If you had this then there would always be more work to get on with. Maybe the last feature you work on in this sprint doesn't get in to this sprint's release, but it can always go in to the next one.
Aside. If you have a small cohesive team then the roles matter less. Instead of having someone with the label tester who isn't allowed to write production code, or someone labelled a developer who thinks they are above testing, everyone should be doing whatever is necessary for the team to succeed, including the dreaded project management tasks when they are necessary, this is called a cross functional team.
One extra point brought up by @Cort Ammon in the comments. The agile manifesto talks about customer collaboration over contract negotiation. You say that:
the client may be disappointed to see the team waste time on something that does't bring immediate value
It can be difficult to explain and I understand customers can be very difficult at times but this would be a big red flag for me. They are trusting you with their source code / client relationship / business / whatever you are developing for them. If they can't trust you to act professionally in their best interest then either you have a problem or they do.
I have written a post that talks about software developers not being considered professionals. A professional doctor, lawyer, civil engineer faced with a client who changed the requirements on them part way through would not just reduce the quality and moan about it. They would tell their clients that it would be a problem. If the client pushed then a professional would not just blindly do it to a dangerously inferior standard because they would be liable. We don't take professional entrance exams and so are not liable. That doesn't mean we shouldn't try to be better.
In summary, I wouldn't worry too much about trying to get people to be more efficient at the beginning and end of a sprint but rather see it as a symptom of a wider issue within the team. Have you heard of eXtreme Programming (XP). I'd say the principles from XP to apply here are communication and respect:
- Respect your team to do what they think is best. I would argue that if there is a lot of watching cat videos then either you have poor developers or you are treating them poorly.
- Communication. If your developers are talking to each other, to the testers, to management, to the customer, then everyone should probably have a good feeling of what is up next and if they don't then they can just ask.
Best Answer
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 -
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 -
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!