Don't get lost in your plans

There are 2 things going on at this customer.

1. They're changing how they use their tools to better fit their needs.
2. They're changing their delivery process to improve collaboration in and among teams.

They're currently using Azure Boards to visualize their work, but the tool doesn't really matter. If they were using GitHub Projects or Jira, they would have similar issues.

Let me quickly describe their setup. There are 9 teams, they're loosely connected at the moment. Teams are working on their own Product backlog Items day-to-day, but those deliver a set of working functionality across the teams in the form of a Feature. Value is currently delivered at the Feature level.

In the past each team had their own backlog of Epics and Features and Product Backlog Items and this caused a lot of problems around ordering, setting priority, crafting common goals, managing dependencies.

One of the configuration changes made at the tool level is to show all Epics and Features on a single Backlog and a single Board. With this change there is now:

• a single view on the common order
• a single place to visualize work with high priority

With this change a few other things were also made transparent:

• There are only a few "Epics"
• There are a LOT of "Features"
• But worse, there are a LOT of "Features" in progress
• Their laptops have relatively small screens 😉.

That's why I got that call today. The client knows they need to change their processes, but that's taking its sweet time. So, for now, they were looking for ways to not get lost in their work.

6 tips to not get lost in your plans that won't require you to change your process.

1. Reduce the amount of data you show on your cards - The default settings of tools show quite a bit of data on every card. An issue number, title, who the card is assigned to, the parent item. and on top of that people tend to add more data: estimate of size, estimate of value, subtasks etc.
2. Adjust the board's settings based on your current needs - The settings of your Backlog and Kanban board are not static, you can tweak the fields based on the activity you're using the board for. For example, in refinement: show the estimates. In a scrum-of-scrums, hide most fields, except the Title. Some tools will let you quickly clone a board to make adjustments (GitHub Projects), in others you will need to manually tweak the settings each time (Azure Boards). Many tools will allow you to hide or collapse columns on your boards.
3. Naming is important - Instead of "As a grumpy project manager I want to improve the visualization of my work in progress in order to not accidentally miss important visual signals that would help me reduce risks" you could use a much simpler title such as "Reduce visual clutter". Then add all of the details in the card's description field.
4. Filtering - Every tool I've ever used offers filtering features. You can craft a query or a filter to show a subset of the cards on your board. In order to filter you may need to add some additional metadata to your cards in the form of a custom field or a tag.
5. Blow up & zoom out - Most tools either offer a built-in full screen feature as well as the ability to zoom in and out. If you're looking at the plan from a browser, hitting F11 will also remove the browser's chrome. While it may only give you a little more space, it's the small things that count.
6. Use the right visualization - Most tools offer multiple ways to visualize the work. Backlogs, boards, at every level, for a single team or across all teams. It's important to know which visualization is right for the activity you're doing. Doing cross-team-refinement to reduce dependencies? Use a view that visualizes your dependencies (Delivery Plans in Azure Boards for example).

While these tricks to tweak the tools can provide some relief, they simply hide the actual problem: there is too much work on the board at the same time. It's well known that having a lot of Work in progress (WIP) causes work to take longer (longer cycle time). It increases context switching. It reduces collaboration between individuals and teams. Usually the end result is: fewer things get delivered and they all take longer.

6 tips to change your process

Instead of hiding the problem, here are a few tricks to fix things for good.

1. Don't scale - As my colleague Laurens Bonnema puts it: the first rule of scaling: don't. As my friend Simon Reindl says in his Scrum classes: Nail it before you scale it. Or as I often bluntly put it: If you scale shit, you get heaps of it. Try to form one or a few teams around smaller objectives and coordinate each of these collectives with their own board. Improve your tools, techniques, architecture and collaboration patterns before trying to scale up further, if you even want to.
2. Improve in-team and cross-team collaboration - Reducing WIP and refining as you go will greatly reduce the number of things your teams are working on. There are examples from organizations practicing Mob Programming (aka Ensemble Programming or Whole Team Programming) where each team works only on a single item at a time. In that case, if you have 9 teams, you only have 9 cards in progress. Possibly those 9 cards all contribute to only 1 or 2 "Bigger items" such as a feature. To achieve this your teams will need to be composed of the "right people" to deliver a piece of valuable work. It may require that those people are capable of doing more than 1 element in your work process.
3. Reduce WIP - All of the tools offer setting a Work-in-progress limit on each column of your board. If you set a limit and actually stick to that limit, you'll have fewer items on your board and it will be easier to keep an overview of the total work in progress. Having a Kanban board or a Sprint board with 30 cards in a column and a scrollbar is a recipe for reduced transparency. Ensure you do not only reduce WIP at the Product backlog Item or Task level. Reducing WIP works best if also applied at the "Feature" and "Epic" level, if that's what you're using. Or at the "Project", "Theme" or "Saga" level. Try to do as few things in parallel as you can.
4. Optimize effectiveness, not busy-ness - The goalkeeper in soccer has one important job, and that is to protect their team's goal. Yet, if the ball is on the other side of the field, they don't suddenly start reading their email, coach the kiddy-league or walk over to another field to protect another goal. They remain engaged in the soccer match, even if they aren't actively handling the ball. The same principle should apply to the people on your team. While the team is working on delivering their Sprint goal, if an individual can't immediately contribute, there is really no need to find less important work to keep them busy. Busy-ness is an epidemic in modern organizations. In increases WIP, it reduces collaboration and it reduces motivation and commitment over the long term.
5. Refine & plan just-in-time - Many organizations practice a Quarterly planning cycle on top of their bi-weekly sprint cycle. As does this customer. If, during this quarterly cycle, work is planned for the whole quarter and most of that work is immediately broken down into actionable Product Backlog Items, then each quarter starts with a completely overloaded board with way too many cards. Instead, try to make a rough selection of "large" items that may need to be delivered that quarter, order them and then start decomposing the top 1, 2, maybe 3 of these into smaller items as you go. This will greatly reduce the clutter on your boards.
6. Use the right "levels" - If you're using a product Backlog decomposition across multiple levels. I personally prefer a single, short, flat backlog over a complex tree with dependencies between branches. But my customer has chosen to decompose their work across Epics, Features, Product Backlog Items and Tasks. Their biggest problem is currently at the "Feature" level. That's where work from multiple teams comes together and that's where they're working on a lot of things at the same time. The big question of course is, "should this have been a feature"? They have very few Epics they're working on, a LOT of features and Product Backlog Items. There is a possibility that redefining what constitutes a Feature may simplify things. Maybe multiple features can be combined? Maybe some could be relegated to a Product Backlog Item and be moved out of this overcrowded visualization?
7. Improve the definition of Workflow - The process this customer follows has a few issues where large batches of work may occur: they plan a large batch of items at a quarterly level, decompose work far in advance and it may take them a while to get work accepted and moved to Done. Yet their workflow is relatively simple and only has a few columns with a pretty generic definition like "development". As a result, as soon as work starts on any item (at any level), cards are pulled into "development". And even though the column was defined with a WIP limit of 10, last week they had about 30 cards in that column in various sub-states. There are 2 things one may do in such a case. reinforce the WIP limits, or to better understand where work is "stuck", further decompose these columns into 2 or more (sub-)columns. This may help visualize any bottlenecks (and would reduce the need for vertical scrollbars 😉) even if it adds opportunity to set a total higher WIP limit.

2 tips in case of emergency😜

1. Buy a bigger screen - Instead of trying to squeeze your whole plan into a 13" HD laptop screen, connect an external 8K 80" screen or a decent projector. Heck, a 46" ultra-wide screen can visualize a LOT of columns on your Kanban board.
2. Buy multiple screens - If a bigger screen isn't an option, maybe using multiple smaller ones may help you better understand what work is in progress,

Conclusion

Knowing you have a problem is half the solution. There is only so much you can tweak with tools. Instead of trying to work around the problem and possibly hiding it for a bit longer, try making the real underlying issues transparent and addressing those.