Visualizing Work — Part 4: Making Commitment Visible
You’ve decided to create a board to make your team’s work visible: does everyone understand the promises made, and their implications?
The Point of No Return
Three meanings of the word "commitment" come up from a look-up at the Merriam-Webster dictionary:
a: an agreement or pledge to do something in the future
b: something pledged
c: the state or an instance of being obligated or emotionally impelled
We tend to associate "commitment" with "making a promise", but the third meaning in the list above strongly qualifies the nature of that promise. If we dig deeper into the meaning of the word "impelled", what we find is: "to urge or drive forward or on by or as if by the exertion of strong moral pressure".
So, when we make a commitment, we're making a promise that it's not easily broken: backing out of a commitment can carry a significant cost (moral, emotional, psychological, or even financial).
Teams of knowledge workers are regularly asked to make commitments to the people whose needs they serve, which suggests that it's in their best interest to have a good understanding of the nature of those commitments, and the rules around making them. How can visualization then support that process?
We can think about this by considering two aspects: clarity around knowing what work we are committing to do, and then, after the act of committing to something, transparent understanding of how far that commitment extends at this particular moment in time.
What Lies Beyond "To Do"
Moving a ticket from “To Do” into the first column of the workflow represents commitment: “we are doing this". To make this commitment point explicit, I recommend teams to visualize that point with a very visible red line.
But, is the intention to deliver to the end of the workflow? or are we going to allow the possibility of discarding work at some point in the middle? Ideally, we want commitments to be firm delivery promises, but it's not uncommon for teams to pull in work that is not ready for fully traversing the workflow (for example, it hasn't been analyzed to the level required to know if it's viable or doable at the moment, or to know that it's really what's needed or wanted.) These work items either "get stuck" half-way through, or are discarded after some effort has been spent on them.
To improve this situation, I encourage teams to visualize the workflow's end point (using a green line, perhaps), as a way to trigger a discussion on commitment: when we cross the red line, do we really have what's needed to move it all the way to the green line?
The act of visualizing commitment this way can pave the way to understanding the need to have a process, located "upstream" of the commitment line, where options are discovered, refined, selected and discarded if deemed unfit, so that when work "crosses the red line" it's ready to make it all the way to the "green line."
Do we know what we're committed to deliver? Do we agree on the span of our commitments? Are we committing too soon?
Uncovering a Hierarchy of Commitments
Commitment to deliver a feature may not be the same as commitment to start working on it. It's not uncommon for teams to find that all the work in their backlogs has been "committed" a long time ago, and that the only decision that is left for them now is when to start working on a particular item. That is still a request for a "commitment", but it's important to realize that it doesn't represent the total extent of the work they are committed to deliver.
By extending visualization to cover the end-to-end workflow (including all the upstream portions where delivery commitments are actually made) can help bring clarity about the nature of different commitments, who is involved in making each of them, at what point in time, etc. Visibility can also help bring awareness on the amount of work that is currently beyond the "point of no return".