Westrum Breakdown Series: Cooperation
DevOps is a culture, not a role or technology. What is culture? Culture may be many things, but we define culture as the practices of the people. In the research of high-performing cultures, some specific traits and behaviors predict high performance. Characteristics and behaviors that nurture high trust and prioritize information flow are critical.
Through the work of DevOps Research and Assessment (DORA), Nicole Forsgren, and many others, we know that a generative culture as described by Dr. Westrum in A Typology of Organizational Cultures predicts high-performance. This series will break down Westrum’s typology and explain practical actions to improve our culture and outcomes.
Cooperation Power Up: Working Together
For trust and information to flow freely, cooperation must be high. Cooperation comes in two flavors. The first is when one individual acts on a request from someone else. The second is when a group of people works together to complete work. Both can increase trust and information flow. At Merely, we focus more on the second flavor. The reason is that focusing on the first flavor can reinforce power-oriented and bureaucratic behavior or abuse by those in positions of power.
Ways to Work Together
Working together happens less often than we might think. Perhaps it results from messages we take in as school children or a short-sighted focus on immediate efficiencies. I’ve heard the advice to let single engineers do all the work in a single module. I’ve seen the warnings about too many cooks in the kitchen. They do address actual risks, but they don’t enhance our goal to work together more.
As we learn to work together, we also reduce the danger of having too many cooks. What problems emerge when more than one person works on a module? Different design paradigms? A lack of coherency? A lack of knowledge leading to poor choices? We address all of these by learning to work together effectively.
Here are some of the more or less novel ways we work together at Merely.
Paired Programming
I’m an engineer with a tendency to get into a state of hyper-focus. Headphones on, door closed, and reaching for a form of “flow.” While I’m “doing my part” of the work, this is working solo, not working together.
Let’s get literal! We can pull a play out of the extreme programming (XP) book and work on a task or story with another engineer. Pair programming techniques vary. Each variation has strengths and weaknesses for different kinds of work. The advantage to pairing is compounding. You’ve got two people who might have different interpretations of the user story, acceptance criteria, or technical requirements. Resolution of these differences gives you direct collaboration on implementation. You’ve got information flowing freely and the opportunity for engineers to increase their trust in each other through the free exchange of ideas and action.
Pairing can be awkward at first, but it’s a skill that we can improve with practice. It increases cooperation, trust, and the flow of information at a very tactical level.
Event Storming
Event storming is a practice in Domain-Driven Design where subject-matter experts and the development team visually document the business processes and logic to be executed by new software. Unlike most user story mapping, user interviews, and other typical requirements gathering activities, event storming includes the whole team. It’s an antidote to the product owner sitting in an ivory tower and the development team turning into a feature factory.
At first, these events can be chaotic and time-consuming. Over time, the benefits of increasing cooperation within and across teams far outweigh the growing pains. The result is a development team and software that speaks the same language as the subject matter experts. Powerful.
Whole Team Product Strategy
While the Product Owner ought to be accountable for the success of the product strategy and have full ownership of the strategy, there’s no reason they can’t share responsibility for creating, inspecting, and adapting it.
Here’s what that might look like:
- Make sure you have the whole team. Our team must include people representing each skill needed to take a product to market: marketing, subject-matter experts, support, and whoever else is needed.
- State the perceived opportunity. Even better, put it up at the top of a whiteboard, digital or analog.
- Layout three columns: Customer Problems/Solutions, Market Challenges/Solutions, Technical Challenges/Solutions
- Use a liberating structure like “1-2-4-All” for each column's problems and solutions. So, six rounds in total. If each is 10 minutes, that’s an hour.
- Take a break and clean up your columns.
- Make two more columns: Do and Won’t Do
- Use another liberating structure to storm out which challenges and solutions the product will actively address and which it will actively avoid. After all, a good strategy has both.
From the wisdom of the whole team, you can craft a refined strategy. The team probably thought of things you wouldn’t have alone. You’ve included everyone, and everyone worked together. High marks for cooperation, trust-building, and the free flow of information. However frequently you adapt your product strategy, you can use variations on this practice.
Spread Work Around
Pulling work is a Lean/Toyota fundamental. It’s one of the practices that enable just-in-time delivery. We can do the same with our Sprint Backlog. If you find that the same members work on the same kinds of tasks, or someone on the team assigns out work in advance, it’s time to introduce the pull method.
Here’s the mantra: The next item in the sprint backlog that you can work on is yours, even if you aren’t the “ideal” person to do that work.
The hard limit defining “can” is a sprint. If someone is 80% confident in delivering the acceptance criteria within the sprint, they can take the work. Sound radical? A one or two-week investment in cross-functional training pales in comparison to the gains.
When you grab something that’s outside your wheelhouse, let the resident expert know you’d like their input, their review, or to pair up once they finish their current work. Then you get multiple levels of increasing cooperation.
Our goal is to increase cooperation which will increase trust and the flow of information. Hoarding work or assigning it out along the lines of specialization works against the purpose. Siloing tasks by discipline might create a more efficient feature factory, but it won’t make a high-performing team or product.
Customer on the Team
One of the most effective agents to fight against us-them thinking and behavior is to embed a customer on the team. Where embedding is impossible, consider hiring someone onto the team whose previous work fits an ideal user persona for your product. Not everyone needs to be an engineer on the team. You need people who can market, support, and sell your product too!
Get creative and embrace learning through experimentation!
Connect with Us
We’d love to hear from you on our social channels. Have you tried these activities? What do you do to work together to solve problems? How did it go?
Follow us and tell us all about it!
