6

I would like to restructure my development teams so that they can work in a more agile way, however each of those teams needs to develop changes for multiple products in their business area.

I've seen many comments on here on how that is an "anti-scrum" pattern, which is fine except the solution appears to be hiring 50+ developers so I can have a team per product.

So, how do I organise 5 teams of 4 to work on roughly 5 products each team. Planning is not the issue, its how to put multiple products into a backlog and plan sprints.

Currently I am running with 1 dev on one product for 1 sprint. That could mean 2 devs both working on the same product for 1 sprint, and the other working on another product. This works when there is a sprints worth of velocity, but when that comes in at less than a sprint, how best to manage this?

Is it better to put everything into one backlog for all products and then pick them off in a more kanban way?

4

4 Answers 4

2

I had the same problem in my organization, and I can share my experience.

We had three projects running simultaneously in a six person team. I was the ScrumMaster and all projects had the same sprint length and all sprints start at same time. We had one day for Sprint Planning, Sprint Review and Sprint Retrospective for all projects, Planning and Review with the respective clients and just one Retrospective.

We had a collective code ownership so every team member could pull a task for any project. Our rule, no project could stop, in other words, we had the have at least one task in "Doing" for all projects. We had a single board with the selected backlog for each project and each team member pulls a task from the board, respecting our rule. Each project had it own product backlog on TFS and we used a physical board for our current sprint.

It has worked very well for our team, and we could deal with bugs in production software and we also have dealt with team idleness. If one project stopped, we focused our efforts on the other projects, until a new one arrives.

2
  • This is an awful idea. Doing it this way will lengthen the time to completion of all the projects. I would avoid this if possible. That said, there could be political reasons that this is the best way to keep all your stakeholders reasonably happy. You'll never delight any of them though.
    – RubberDuck
    Jul 2, 2017 at 11:20
  • Well, in my company we don't have a steady project's flow, so, this solution helped to solve this problem, avoiding idle time. Regarding project schedule, it was the opposite, most of then were delivered in the desired time for our clients. Jul 3, 2017 at 17:41
3

We had a team of ~8, well over a dozen products, and 6 different product owners. I won't claim this is the best way, the best way is to staff enough people to properly support all your products, but I've had experience similar to yours and we worked out a system that worked really well for us.

We kept two Kanban boards:

  1. Epics (1-3 month projects)
  2. Currently played stories/backlog

We normally kept our Epic WIP limit to 2, but would raise it to 3 as an Epic was nearing completion. This allowed a graceful transition between epics by giving us time to groom & plan the next project as the last one was being polished off.

Weekly, we'd meet with any product owners of active epics to have them prioritize their stories in the backlog. Monthly, we would meet with all the product owners so they could collectively prioritize the Epics.

This may sound like a bad idea, but we found that people generally would do what was right for the company. I heard very often, "Oh. Yeah... no. My thing isn't as important as Bill's thing. Do his first." I think the huge benefit was giving everyone visibility into all of the requested work. Our product owners could easily see how their pet projects may not be the most valuable thing for the team to work on and gave them an appreciation for just how much we were being asked to do. In the long run, they became some of our greatest advocates. We didn't have to go begging for more staff, because our product owners were doing it on our behalf. They wanted teams dedicated to their products so there would no longer be so much contention over our time. When I started at that company, there were two of us, soon after I left, there were 3 teams of 4.

Anyway, having a team of 8 soon gave way to having 2 teams of 4 working mostly under the same model, but having 2 teams (each with fewer products to support and prioritize between) resulted in a much reduced overhead. It allowed us to specialize more. Once we had split into 2 teams, we reduced each team's Epic WIP to one.

I feel like this is a good approach because it dramatically reduces the context switching for everyone. Yes, some people will get anxious waiting for their project to be next, but if they want it done sooner, they need to convince their peers and the CEO that it should be next. In the meantime, we were able to give a single problem our full attention, which seriously reduced our cycle times.


Again, the best way is to have enough staff to support all your products, but I understand how hard it can be to convince a non-software company that they require that staff to support all the things they build. Just recently I had a hard conversation with a client about some scope creep. It basically amounted to "To meet system parity, you need to build this tool that doesn't exist in the old system." ... uhhhh huh... Anyway, we asked them if they were prepared to spin up an entire team, Product Owner, Scrum Master, Dev team, to build and support this product indefinitely. The answer was obviously no, but they had not considered the true cost of this new product until we mentioned it. Just some food for thought. I've always found that people want want want until they see the price tag. Show them the price tag.

1

One of our product engineering teams (which has 4 sub teams, with 3-5 members each) have this problem. We go by (since 4 years ago) one backlog per (sub-)team (we drew our decision from this article of K. S. Rubin), it reduces the cost of maintaining multiple backlogs and strengthens our focus. Take note that, Scrum advocates a sprint goal, not multiple. At the same time, I always encourage my teams to reduce WIP using single piece flow.

The most difficult part, in my opinion, is to group and assign relevant products, and properly leveled. Tools like matrix for operational/business relatedness and BCG matrix could help you with your decision.

Currently I am running with 1 dev on one product for 1 sprint. That could mean 2 devs both working on the same product for 1 sprint, and the other working on another product.

Depending on how comfortable you are in swarming, the more focused the team is has both short and long term benefits, e.g. lower WIP leading to shorter lead time per story, and cross training. I will strongly encourage that.

Since you are using sprints, which is some kind of fixed repeating schedule, you can also borrow some concepts from manufacturing in perfecting your flow towards single-piece flow, which is a life-long journey, so to speak:

  1. Separate higher-risk products from teams with a larger set of products with high predictability and incremental work (aka green/red stream).
  2. Reduce sprint length, focus on learning and improvement on the pipeline. A lot of waste reduction here, e.g. reduction of "changeover"/build/deployment time.
  3. Allow mid-sprint scope change, and eventually build the muscle that allows you to continuously deploy (See also Type-C Scrum).

Hopefully my response sums up the important concepts and practices (esp. on focus, on smaller batch size) leading to building multiple products concurrently.

-1

Changing the approach may have benefits. However it rarely solves the root problem of not having enough people. Having the same technologists switching between projects decreases efficiency.

If you truly want to be agile, start with the Agile Manifesto. Self-organizing teams are essential. Have the technologists who are doing the work be a part of finding the solution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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