Software Delivery in Small Batches

Adam presents the language used to call the plays from Leadership is Language as told in The Project Banana episode. 

Learn More
★ Support this podcast on Patreon ★

Creators & Guests

Host
Adam Hawkins
Software Delivery Coach

What is Software Delivery in Small Batches?

Adam Hawkins presents the theory and practices behind software delivery excellence. Topics include DevOps, lean, software architecture, continuous delivery, and interviews with industry leaders.

Leadership is Language
Hello and welcome to Small Batches. I’m your host Adam Hawkins. In each episode, I share a small batch of software delivery education aiming to help you find flow, feedback, and learning in your daily work. Topics include DevOps, lean, continuous delivery, and conversations with industry leaders. Now, let’s begin today’s episode.
The past two episodes have focused on leadership, communication, and collaboration. Two episodes back, I told a fictional story of a team completing the migration of their services to a new infrastructure. The previous episode, I introduced the concept of redwork, bluework, and the plays to transitions between the two.
This episode rounds out the trilogy by covering the language used to call the plays. I’ll demonstrate the language through parts of the story from the Project Banana episode.
The story kicks off with Brian, the team lead, talking to his team prior to launching the migration.
This is a period of bluework. The aim is connect with the team about the path ahead and commit following period of redwork. That means initiating the launch sequence.
Brian chooses his words carefully. Here are some examples.
He shares information, and not instructions as much as possible. Example: “We’re aiming to complete the migration without impacting production.” instead of: “don’t break production”. Sharing information allows people to draw their own conclusions and behave in their own way.
Brian is also aware of the power gradient. He wants the team to know that’s OK, in-fact it’s encouraged to adapt to changing conditions. Everyone has a vested interested in completed the launch safely. This dove tails into the next part of his initial monolouge.
He declares two exit points from the period redwork. Each is an offramp into bluework. The first exist is natural because the launch sequence has built-in checkpoints. Brian reiterates the point to reinforce the idea of taking it one step at a time. Finishing each step is the point to stop and evaluate. This also set the expectation that team does not just blindly follow the launch sequence. Nope, we’re going to chunk the work and move carefully one step at a time.
The second exit is the andon cord. This offramp from redwork is more important than first. The andon cord is the team’s method for the “control the clock” play or calling a pause.
They all understand an andon pull to mean: “Oh no, problem! Stop everything and swarm!” Brian mentions the andon cord because it demonstrates the team will adapt to changing conditions. They will not blindly follow the plan. The proper action is stop on problem then collaborate on a way forward. More importantly do not ignore problems. Surface them.
The opening monologue contains a lot, so here’s a short recap.
Brian gives a clear statement of next steps of redwork to commit to. The redwork is bounded by completion criteria so the team knows when to move from redwork to bluework. The andon cord is the predeclared “control the clock” play to exit redwork and move into bluework.
Now we’re into the story’s second act: the launch itself. Surprise! There’s a problem. Adapting to the problem is the story.
The engineers Lindsey, Diego, Jean, and Marko detect at major problem. They already know how to exit the redwork because the the control the clock play is predeclared. That’s the andon cord. The team executes the escape hatch to maintain production safety, then pulls the andon cord. This signals the transition from redwork to bluework.
Brian responds to the andon pull by saying “Thank for your surfacing this problem. I appreciate your focus on launch safety.”
This statement reinforces the importance of calling the pause, surfacing problems, and stopping for collaboration. It also celebrates the behavior and not the characteristics of the other person.
Next, Brian facilitates the collaboration on solutions with an aim to commit to next steps.
This act in the story demonstrates the difference in redwork and bluework. Reworks wants a controlled environment. Bluework wants divergent thinking. Brian understands this, so he coaxes the team to consider the challenge from multiple angles attempting to get the team to consider a menu of possible countermeasures, instead of latching onto a single one.
Brian asks many how questions during this act. “How” questions give the other person enough space to answer. One of the teammates asks: “How big of a problem is this?” They respond with their reasoning on why it’s only a warning level. Compare this with a binary question like: “is this a problem?” followed by a simple yes or no response. Clearly, asking “how much” or “how confident” allows for a richer response.
These questions fuel divergent thinking needed in bluework. At one point, Lindsay starts a sentence with: “Let’s start with the mental model of the system…”. This powerful statement reveals the assumptions she makes about the system. That’s catalyst for identifying one countermeasure to the original andon pull.
Brian wears a few hats during this act. We see him switch into his coaching hat. He asks Jean: “what’s the the real challenge for you in vertically scaling the proxy?” This question is specifically used to identify the obstacle in the way for the specific person, not someone abstract. This is Brian trying to coach the team through analyzing the problem and proposing countermeasures. The first step is identifying the actual challenge.
Jean is befuddled by the question because she’s never considered it. She responds that she simply don’t know how to do that. Brian knows that the challenge question always comes preloaded with a follow up question: “what do you want?”
That question is specific enough to cause Jean to revisit the constraints in the proxy that prompted the original andon pull. That’s the aha moment that turns an abstract idea into something concrete. The problem is that Jean doesn’t know how to actually do the thing she wants. So Brian switches hats and goes back into facilitator mode by prompting the team: “How can we help Jean?”. Again, asking a “How” question.
This question passes the ball to the rest of team. It’s opened-end enough to allow exploration. Luckily, Jean is supported by a team who can figure out how to vertically scale the proxy.
The discussion concludes when Brian leaves the team to discuss one countermeasure with management. He says he’ll review an updated launch plan based on the countermeasures when he returns. Again, this is Brian sharing information, not instructions. The information is the actions required to end the “Collaborate” period of bluework and transition into redwork.
Brian returns with approval on the countermeasure. He celebrate the team’s work on the updated launch plan. In fact, he did not need to instruct everyone to iterate on the launch plan. The team had the information. They were intrinsically motivated in their own ways. Brian is sure to celebrate this by saying something like “I notice how each of your analysis contributed to the updated launch plan”.
The next step is wrap up the bluework and commit to the next period of redwork.
Brian gives a similar, but shorter, version of the monologue in the first act. He predeclares a pause with the andon cord and bounds the redwork with the completion criteria in the launch plan.
He gets the team to commit with simple red/yellow/green vote. Everyone is green, so the team is committed and ready for the next step. Brian hands the reigns to Jean to execute the updated launch sequence, says when he’ll return, and leaves.
This is the end of the second act.
The third act begins when Brian returns to the team. The team tells Brian the launch is complete. This marks the end of redwork and the end to massive years long project. Something definitely with celebration.
He speaks to celebrate the positive outcome of the team’s work. The outcomes is a huge win for business and positive impacts on the daily live of the whole engineering team.
Brian does not say things like “Great work” or “I’m proud of you”. Instead he chooses to emphasize the team’s contributions to the outcomes by celebrating with them instead of for them. This reinforces the behaviors that delivered the outcomes.
Brian indicates the next period of bluework will be improvement focused. This is standard practice for any agile software team. Retrospectives are automatically built into the process.
Brian starts the retrospective by asking a simple question: “How can we get better?”. This is an open-ended question.
Starting with “how” gives anyone space to respond, and “get better” provides a trajectory. The language establishes that as good—or as bad—as anything is, there is always opportunity for improvement. This is a learning organization in action.
The retrospective is a period of bluework. Again, the aim is divergent thinking to create a set of possible solutions, then converge on the best outcome.
This requires questions and the physiological safety needed for the challenging ones. The team asks each other questions like: “How would that work?”, “How confident are we this would work?”, “How quickly could we test that?”, and “What’s something we’re not considering?”.
Brian stays mum because leader’s speak last. His silence provides the team space needed to probe the problem areas. Plus, Brian knows he has another role to play: the coach.
He observes the team getting ahead of themselves. The proposed countermeasures are good, but the understanding of the current condition is not. He knows it’s time to call a pause to exit this period of bluework, to commit to the next steps. If there is no pause, the team could end up spinning their wheels.
The pause happens verbally when Brian says “timeout”, explains why he called a timeout, then asks if there are any volunteers to drive the problem solving process using an A3.
Volunteering to take on the A3 is the commitment that signals the end of that bit of bluework. Once that thread is closed out, the team can revisit the original purpose.
Brian prompts the group with “How else can we get better?” and the next iteration kicks off.
End of Act 3. Alright, let’s recap to finish out the episode.
The story beings with a connect play with the team. This is a period of bluework. The aim is commit to the next period of redwork. The commit play happens when the team initiates the launch sequence. That starts a period of redwork.
The team calls a pause by pulling the andon cord when a problem occurs. This is the control the clock play that signals the end of redwork and begins a period of bluework. That’s the collaborate play.
The team collaborates on solutions to problem form the andon pull. This is a period of bluework where creative thinking is needed to solve problems. The team creates and then commits to an updated launch plan. That transitions the team into redwork.
The redwork ends when the launch is complete. This is complete play that signals the end of redwork which sets up the next period of bluework.
The team holds a retrospective to improve future redwork. This is the improve play. The team members commit to go further. That signals the transition from bluework to redwork.
And the process continues again. Redwork-bluework-redwork; bluework-redwork-bluework.
----
You’ve just completed another episode of Small Batches. I hope you’ve enjoyed this series of episodes on leadership.
I’ve applied the lessons from The Coaching Habit and Leadership is Language to my own daily work. It has been challenging and rewarding. Choosing my words purposely and carefully requires a certain stillness of mind. I’m working on cultivating that.
My current practice is improving my questions and celebrating with and not for. I’m also integrating the concepts of rework and bluework into planning sessions. Learning to see the plays and knowing when to call them has helped me grow as manager and leader.
Leadership is Language is a wonderful book for managers and leaders. Managers can benefit from learning to see and call the plays with their team. Leaders, like tech leads, or engineering leads, will benefit from learning to ask the better questions to keep projects moving.
My copy of Leadership is Language covered highlights. In fact, I’ve been referring to their handy summary for constant reminders on things I should say or not say.
Anyways, find links for everything on these books and more software delivery education at SmallBatches.fm/82.
I hope to have you back again for the next episode. Until then, happy shipping.