Beats in the DevOps Dojo Loop: Plan (1 of 4)

This is part one of a series on how iterations work in a dojo challenge. See Part 2: Do, Part 3: Share, and Part 4: Reflect for the whole story.

A dojo team challenge operates on a quick tempo of cadences the community calls "hyper-sprints." These are short iterations, usually lasting 2.5 days / 2 per week, in which we identify work and the learning we want to attach to it, go after it, share our results with stakeholders and the broader dojo community, and take the result of that sharing into the next sprint. Rinse and repeat. If you're familiar with Scrum or XP, it should feel pretty familiar (if not a bit compressed). That said, there are some important differences in the beats within this loop, differences that support the learning mission of a team.

In this series, I'll cover each of these beats: planning, doing, sharing, reflecting. I'll share some basics on timing but go deeper into each beat with some of the tips, tricks, and hacks I've found useful over the years.

Let's start with "plan."

Plan

The hyper-sprint begins with a short planning session. By short I mean anywhere from half-an-hour to a few minutes. At the start of the challenge, expect a bit longer planning session; the team is coming together with a coach and there might be some valuable discussion or even explanation as the team gets used to the pace of their challenge.

Once you get going, you might not find a need to plan. Right-sizing planning and getting to a minimal-yet-useful balance is a pretty regular learning outcome in challenges.

Finding the Work

In planning, the team identifies which items are important to pursue. These items can be typical delivery-oriented user stories that create value for customers or stakeholders, investments in the team's rig (building pipeline, say), or one-off sessions such as knowledge transfers or walkthroughs given by enablers within an organization ("this is how we provision a new environment in the cloud"). It's all on the table. If there's ongoing product discovery, I ask the team to capture all work in their backlog and plan it alongside the delivery work. No invisible work, as we say.

It's good practice to refer to the team's challenge frame, their product and learning goals, and any discovery artifacts they may have created (story maps & journeys, example maps, event storming canvases, etc.). These artifacts help the team make choices about what's next in iterating on the product they're evolving.

Creating an Iterative Feedback Loop

Another source of inspiration for planning work should come from the "Share" and "Reflect" beats in the loop. It's common to get feedback from stakeholders - clarity or new ideas - that we can take into our planning efforts.

Work-in-Progress Limits & Sizing

I'm a fan of starting with a WIP limit of 1 for small teams (5-7 people) and maybe 2 for larger teams (7+), especially in the beginning. This gives every person and role on the team a chance to see how a particular work item gets done. It also creates a single group for coaching to engage with. As the challenge progresses, increasing the WIP limit is normal.

We don't really estimate in the dojo. It's more sizing. Coaches, ask your team, "do we think this item fits within a single 2.5-day iteration? Two?" Over not too much time, you'll find this natural way of breaking things down leads to smaller, less risky stories.

The Importance of Collaborative Volunteerism

We've decided what to do and given stories enough context to move forward. Now the team decides how to divide things up, who will work on what, and how we'll rig collaboration. We always prefer volunteerism over assignment. Some teams work this way naturally, others need a little encouragement.

For example, if there's a story that leans heavily on development, why not encourage your test automation teammate to join the group working on this? They get a chance to see how development goes down and, most importantly, a chance to elevate their skills. Developers in this situation get a chance to practice valuable social skills for good teamwork – patience, teaching, and taking turns coaching one another.