The Unwritten Rules of Baseball, um, Working Together
Kanban Practice 4: Explicit Policies - Find a way to work together that works, and write it down...
Hey, my name is Tristan Hood and I love helping leaders and teams find new and better ways of managing work. I believe continual, organic change is far superior to large transformation, unless absolutely necessary of course. As such, I created this blog with the intent to share my experiences, wins, and losses. Today we discuss the Kanban Practice of making your working agreements explicitly.
We’ve discussed how visualizing your work and workflow creates massive clarity. Once you can see those two things, you can limit how much work moves into that workflow, creating capacity and massive focus. With focus and a truly limited workflow, you can begin to measure and manage how work flows through that workflow. So far, so good. Work should start flowing at this point. We can assume everyone is on the same page and just get to work.
Not so fast.
There’s still a lingering devil that can catch even the most “well oiled machine” unawares. That devil, a literal demon trickster, is assumption. Specifically, assuming that everyone on the team actually understands how the work inside your workflow moves. Questions like, “Who adds work to the Kanban board? How does it move from one status to the next? When is work blocked? When should it be expedited and what does that actually mean.”
It’s a lot like the unwritten rules of baseball.
No stealing a base when your team is up by more than 5 runs. Don’t swing at the first pitch after the pitcher has given up two back to back homers. Don’t show up the opposing team, or your own for that matter. (Just for fun, I researched the unwritten rules of baseball and even those are written down.)
At this point, you and your team have probably encountered some of the workflow equivalents of these questions, answered them, and moved on. (I’d love to know how you handle back to back homers, hahaha.) But what happens when someone new joins the team? What happens when a deadline comes up? What happens when someone just plain forgets. Or worse, assumes they know what should happen?
That’s where practicing visualizing explicit working agreements, becomes so powerful. And I don’t mean rigid policy.
Here’s a quick story.
Callie’s Dilemma
I remember sitting down with one of my favorite Kanban enthusiasts, Callie Bral, to walk her team through a Working Agreements session. She had the typical list of questions, including the ones mentioned above. She felt like the team wasn’t on the same page, work wasn’t moving, and that there was ultimately a lack of ownership. Most managers would address the surface issue and demand the team take some ownership. Or, perhaps, that golden oldie, “How about we do some work to increase our efficiency.” Talk about a one way ticket to gridlock.
Callie, on the other hand, thought perhaps there was another way. Thus, the Working Agreements session. She started running through a list of questions about how the team managed their Kanban board, how work moved, how to define certain things, and various others when she came to the question of when to block a card. “We block a card if we moved it too far,” someone said immediately. “Wait, I thought we block a card when we stop working on it and move to another piece of work,” was a second, more skeptical reply. A few moments later, one of the more quiet people on the team said, “I’m not even sure how we block a card. I thought only Callie did that.” Finally, some real difference of opinions. The meeting was getting fun.
Regardless of whether you know what in the world blocking a card or work item means, you can see there was some confusion about a right or wrong way to do it. (In fact, there is no right or wrong way to do it. And all the Scrum acolytes head’s just exploded.) Callie, in that patient tone that could simultaneously be mistaken for being on the brink of snark, asked, “Well, let’s define it and just write it down and see how it works.” That’s not a direct quote. It’s more how I remember Callie. She had a level of patience and kindness when valuable conversation was happening, but as soon as it turned to nonsense she’d had enough. That works great in one of these sessions, for sure.
The point here is that these types of assumptions are always there. Always. Floating amongst the team like seagulls when a tuna fisherman is chumming the water. And like the chum, these assumptions stink. They lead to all kinds of chicanery and tomfoolery that can cause even the best teams to slow to a grind when it comes to delivering great work. Taking time to clear the air and ask some clarifying questions brings alignment. And fast. I’ve been part of numerous agreement sessions and, without fail, the team leaves not only understanding some basics around how they want to handle work, but with a little bit more ownership and accountability.
Decide, Commit, Evolve
In every one of these working sessions I coach and facilitate the same way.
I start with a list of questions that include, but are not limited to:
Who can add work (cards)* to our Kanban board?
What goes in a work item (card)?
Who moves cards on our board?
When is work “committed” work?
When is work “done?”
When do we “expedite” a work?
When is work “blocked” and how do we treat that?
There can be dozens more, and the conversation can take several sessions. And that’s okay. The goal is not to have it all chiseled in stone immediately. The goal is to create clarity.
In the meetings, I don’t ask these questions as though there is a right answer either. I am actually looking for how the team does it currently. The purpose is not always to change to a new way of working. In fact that can cause even more of a slow down as people learn the new way of managing work. Instead I like to say:
“How do we do this now?”
Then I write down the response and ask:
“Everyone okay with continuing to do it that way, or should we talk about it?”
And that’s fine. Write it down. Commit. Move on. You will evolve these over time when you do retrospective type conversations, which is the subject of an upcoming Tidbit. This working agreement is not a form of law enforcement. The policies you write down are indeed explicit, but they should be regularly reviewed and only kept insomuch that they help you and your team deliver value to your customer in quick iterations. Toss the ones that don’t support that and evolve the ones that do.
If you want a more comprehensive list of the questions you can ask during one of these sessions, I have a PDF version I would love to share with.
Until next time,
Keep on Learning, Keep on Growing.
*If you are new to the world of Kanban, a Card refers to a work item, similar to an item on a “to do” list, that goes on a work or job board called a Kanban board. Check out the Visualization practice for more on that topic.