Some program level board tips:
1/10 While you should visualize as much of “the work” as possible, you will almost certainly need to sacrifice a bit of detail for accessibility. Can anyone looking at the board see where their work fits in?
1/10 While you should visualize as much of “the work” as possible, you will almost certainly need to sacrifice a bit of detail for accessibility. Can anyone looking at the board see where their work fits in?
2/10 Consider rate of range and cognitive overhead. If items on the board need to be moved by the second/hour/day...well that will be hard to process. But if items don’t move for days/weeks...that will not not be useful and actionable. There is a balance.
3/10 Model the work, not the workers. It is tempting to structure the board around teams, team lanes, etc. Why? The information is helpful! Knowing who is working on what is useful information. But, you run the risk of obscuring dependencies and global priorities...
...You also subtly discourage cross-team collaboration. Instead, consider lanes for value streams, and use markers to indicate who is working on what. This is one nice aspects of digital boards — you can just switch views.
4/10 Dependencies. Be cautious when you split a meaningful piece of work into pieces (to assign those pieces to teams, for example). You run the risk of obscuring how things actually fit together. Whenever possible, try to reflect the “real” relationship between work items.
5/10 When visualizing work at the program level you will have to make some decisions about column headers (stage headers, whatever you want to call them). You want the columns to reflect “reality”, so...
... if you have lots of different types of work you will either need 1) broad column headers that are general on purpose, or 2) lanes and subsections to reflect different “flows”. There’s no one-size-fits-all solution here.
6/10 Depending on the organization and type of work, it is very common to have “streams” of small, reactive tasks. One temptation is to leave this stuff off the board. Don’t! But, to an earlier point, you will need to get creative about keeping clutter manageable...
... One solution is to visualize the streams with a single one-pager or card with an expected volume of flow (e.g. 15 requests for data/30d). Then, use an operational review to actually understand what happened.
7/10 “Discovery teams”. When initiatives are in the early stage you may have two layers of “ownership” — the team shepherding the effort through to kickoff, and the team (or teams) expected to “work” on the item in the future. Both bits of information are important
8/10 Teams are often hesitant to visualize “research” or “discovery work”. There are many reasons for this: fear of micromanagement, the sense that “it isn’t work yet”, and turf wars: getting to do this type of work is a protected status symbol. Try, try to resist all that.
9/10 Open-ended missions. What if spending *more* time on something is a sign of progress? Of success? In ideal world, your program view is amenable to these more open-ended missions. Consider if some work needs a “definition of keep going”.
10/10 Finally, I’ve gotten reisitance from large teams that are MOSTLY comprised of small independent teams. They feel a board is unnecessary/detrimental. They have their own roadmaps. Why worry? Except they are actually all overwhelming some shared teams. You need a board!
