You’ve decided to create a board to make your team’s work visible: are people aligned in their understanding of the rules we follow to work together?
The Rules of the Game
Whether we're aware of if or not, all the work we do is done according to some predefined rules. Those rules are certainly not static; they change over time, and evolve to accommodate various circumstances. They also come in a variety of degrees of formality and flexibility: from strict corporate policy to agreements, convention and ritual, habit, and rule of thumb.
Something is certain, though: when people have different understanding of what rules we follow to "play" the game of work, it will lead to clashes of all kinds. It can also lead to the conclusion that decision making needs to be centralized, as a way to ensure consistency and appropriateness.
We can address both of those concerns through visualization of the rules, or policies, we agree to (or must) follow in order to do some collaborative work. We've come to know this as the principle of "making policies explicit".
Although many different kinds of policies can be made visible, two broad categories are of particular interest here: the conventions used to read and populate the board, and those rules used to guide decision-making.
A third category, reminders about expected interpersonal behaviour, is also usual amongst (especially) Agile teams. This includes things such as "team agreements", the team's "code of conduct", meeting logistics, etc.; they are an important aspect of aligning behaviour, but they are out of scope for this series since they go beyond visualizing aspects of the work itself.
Conventions to Use the Board
This is perhaps the most commonly used practice when it comes to visualizing policies, and it usually takes the form of some sort of "legend" attached to the board, to inform team members (and casual observers of the board) about the meaning of tickets of different colours and shapes:
Often, the tickets used on the legend also give guidance on how to create new tickets for the board, by showing the expected format, example data used to populate the ticket, other conventions to follow, etc.
Sometimes colour is not enough, and the legend is used to post more "formal" definitions of the work types, to align people's understanding of them:
In some other occasions, work items of a given type may need to be further classified for tracking purposes, or to give different treatment to them. In the example below, the legend explains that small colour dots are used for that purpose :
When hierarchical work types are used, this legend is also the opportunity to show the relationship between different types, how they are related, batched, etc.
For teams that represent multiple teams collaborating, showing team affiliation may be important. In the example below, different board sections were used to segregate work types, and colours would show which team was working on a particular item:
Rules to Guide Decision-Making
This category of rules is frequently overlooked, possibly because a significant portion of them are implicit, or more difficult to articulate. However, precisely because of that, they are the more powerful.
Perhaps a good place to start is by documenting the transition rules between columns: essentially, what needs to happen for a ticket to move from one column to the next?
Teams frequently have “Definitions of Done” and “Definitions of Ready”, so it’s a matter of mapping them to the various steps in the workflow. Making these transition policies explicit helps us make sure we agree on how we work, but more importantly it also help with team self-organization: people can come to the board, look at the work and rules and make autonomous decisions taking the context into account.
Can I move a ticket to the next column? What are the “rules of the game”? Do we all agree on them?
The transition from “To Do” to the first “In Progress” column is special, because it requires answering two questions: "what could I pull in next?" and "can I do it now, or should I wait for later?" One speaks about the problem of “selection” and the other about “capacity.” Full coverage of those two topics is out of scope for this article, but the general idea is that you should think about the rules you have around those two concerns, and make them visible here.
As an example, a common approach for dealing with the selection problem is to use Cost of Delay profiles to assign a Class of Service to various items, and then use that as the selection criteria.
By visualizing these profiles on the board, and then tagging individual work items with one of them (or some other mechanism to indicate how they are related), a team member looking to make a pull decision can autonomously make a selection decision in front of the board.
A common approach to deal with the capacity question is to use WIP limits to constrain the amount of work allowed to enter the system, or to move between columns. The most widely known way to visualize WIP limits is by using numbers at the top of each column. WIP limits can also be established by type of work, usually by segregating them in lanes, and indicating the limit as a number in each lane.
There are, however, other options for visualization of WIP limits. A simple one is to physically constrain the amount of work by having "slots" in the board, where only a single ticket can fit.
Yet another option is to give each team member a fixed number of "avatars" they attach to the tickets they are working on. Work is allowed to enter the board, or move to another column, only when the required avatars are available.
What could I pull in next? Can I do it now?
This article is part of a series is based on a presentation I delivered at the Toronto Agile Conference 2018. The slides from that talk can be found here.