What is the best methodology for a multiproject and multiteam environment?

Question

I'm working in an enterprise that realizes several dozens of projects based on its own system. The problem is that there are:

• several projects
• several teams
• several modules that are associated with teams

Currently, PMs work as coordinators of their projects between Teams - the same project can be done by several teams, and sometimes one part of a project depends upon other teams.

Currently, we follow a Scrum-like approach:

• Teams up to 9 members
• 2-week sprints
• planning of work is done at the beginning, but there is much unplanned work delivered by PMs

All this leads to some factors:

• Low morale of Team members; it is very rare (~0%) that a Sprint is done in time
• One worker got an idea to just ignore all Scrum activities

As I see at this moment, the main problem is in many-many relationship between Teams and projects; even when there is no product itself, it spreads over the projects.

So my question is the following: maybe the best way would be to use Kanban? Workers will only pull work items from the backlog, just organizing flow. Maybe we don't have VERY complex projects, to justify using Scrum, and Kanban will be useful.

I want to discuss this with my bosses. Are there any obvious disadvantages that I've missed here?

Answer 1

Given the way you have described your situation, I would say you have the following challenges -

1. Too much demand (work) on your teams, across multiple products/ projects
2. Constrained capacity to deliver. Your teams have not only planned product features to deliver but also a lot of unplanned work that comes up on a regular basis
3. Unrealistic/ optimistic Sprint planning leading to Spring scope not being delivered
4. Too many dependencies between teams and due to other possible external factors
5. All of the above leading to dissatisfied customers/ management and poor team morale

In this situation, it seems to me that the Kanban Method will really be very helpful to implement. Here are the following ways you can use it to streamline your flow across the entire system, set expectations with customers/ management and help teams deliver based on their natural cadence. Over a period of time, Kanban will help you identify and eliminate bottlenecks and improve throughput, thereby helping your teams deliver more product features.

An important aspect of implementing Kanban is to implement it in the Upstream processes of product/ portfolio backlog management and ensuring that the right features/ stories are prioritized at the right time and scheduled on a regular cadence.

The second aspect of this would be to look at the actual nature of the current demand on your teams. This is comprised of both value demand (new features) and failure demand (issues/ bugs/ etc.) - as also intangible work such as tech debt. You need to identify the various components of your demand and provide for adequate capacity to do this work - and thus identify the true (net) capacity your teams actually have to do new value add work.

At the risk of jumping into a solution without further discussion, here are some suggestions.

Using the STATIK approach (Systems Thinking Approach to Implementing Kanban), you should consider implementing three levels of boards - Portfolio level, Product level, and Team level.

The Portfolio and Product level boards will help your stakeholders prioritize and coordinate work across multiple products and strategic priorities - and ultimately help your teams get prioritized backlogs that they can work on without confusion.

The team level boards, combined with WIP limits, will help you streamline the team level work - by helping identify specific points of cross-team dependencies and bottlenecks within their own processes.

One key thing that you already have said - instead of committing to a sprint/ release scope up-front, simply decide on a sprint or release cadence (2-3 weeks - a month at most) - and release/ deploy whatever is ready every3-4 weeks. Use the pull mechanism to take whatever is the next most important thing from the prioritized backlogs.

As you probably already know, there's a lot more to Kanban than just a board and stickies on the wall! If you need more help on the Kanban Method, please read up here. For more on STATIK, here is a great article. Third, please see this article on Kanban Flight Levels, which helps you model Kanban boards at multiple levels. (Since it was originally written, it has been updated and now refers to 4 levels of boards.) Finally, there is a lot of great training options at Kanban University.

All the best!

Answer 2

Low morale of team members, it is very rare case if sprint is done in time up to 100%

This statement is worrying. In Scrum there is no concept of 'done in time'. The team pulls work into the sprint that they are confident they have the capacity to get done. If they find they consistently cannot complete the work they allocate to a sprint then the solution is typically to reduce the amount of work they bring into a sprint.

As I see at this moment, main problem is in many-many relationship between teams and projects, even there is no product itself, it spread over the projects.

Regardless of the methodology or framework you adopt, having a lot of dependencies between teams can be challenging.

My suggestion would be to:

• Consider doing fewer projects at a time - this will reduce dependencies and complexity
• Try to have team members dedicated to a particular team and don't move them around between projects
• Use an approach such as scrum of scrums to help synchronise across the teams