I’ve been working with clients who have brittle environments. Their brittleness doesn’t show up all the time. When everything is good, they’re able to finish work and deliver.
But, someone checks in code that breaks something “over there.” Or, someone gets pulled off to work on production support issues and is no longer available to the team for weeks. Or, they have a weather incident and the people can’t get to work.
The managers originally thought each of these was recoverable. The teams can recover. However, they can’t recover fast.
The teams have little resilience.
The teams take weeks at a time to recover. The managers think that’s “too long.” I agree. And the managers didn’t realize their decisions created these problems.
Define Resilience
When I talk about resilience, I mean the ability to experiment with an alternative. Sometimes, that experiment is one small step (as in the image). Sometimes, it’s an entire experiment with a hypothesis, etc.
(If you want a deeper dive into resilience, read What’s the Difference Between Resilience and Adaptability? on my other blog.)
Teams can build resilience in many ways. I’m only going to discuss these three problems for team resilience:
- The team doesn’t work as a team—they work as individuals.
- The team has long feedback loops.
- The team doesn’t have the ability to work “anywhere” and certainly not “anytime.”
This post is about the problem of when people work as individuals.
Individual, Not Team-Based Work
Company A is working on its umpteenth “agile transformation.” I put that in quotes because the managers want the teams to change. In reality, managers need to change first.
One of the big problems is that the managers think agile approaches will give them faster delivery. Yes, and, that delivery arises from fast feedback cycles—fast learning.
Software product development is about learning, first. The faster we learn, the faster we can deliver something useful.
When we don’t learn together, we ship garbage. Or, we don’t ship and it’s garbage. I don’t know which is worse—the shipping or the not shipping of garbage.
Company A managers don’t believe in flow efficiency. The managers give people individual objectives. And, the managers expect people to deliver “their” stuff, meeting those objectives.
The so-called Scrum Masters (who look to me as if they are old-fashioned command-and-control project managers, not facilitators) ask people when “their” work will be done.
That emphasis on individual work means the teams at Company A cooperate—when they can. The teams do not collaborate.
Cooperation is Not the Same as Collaboration
These teams cooperate mostly through code review. They do a pretty good job of code review—when they do the review.
However, the way they do code review has at least these problems:
- They don’t always do code review because a developer is “late.” (Often because the code was more difficult than he or she anticipated. Yes, that’s exactly when the developer needs the review more.)
- I asked the teams to measure their cycle time. That’s when the teams realized they sometimes waited days for code review. No one could meet their objectives with these delays.
The team members try to collaborate. However, the personal objectives create disincentives for each person to collaborate.
(I’ve suggested pairing, swarming, and mobbing before to help reduce cycle time and increase collaboration.)
Why This Emphasis on Individual Work?
When I explained the concepts of resource and flow efficiency, the managers nodded. They understood.
What prevented them from using flow efficiency? The performance management system and HR. Also, software capitalization issues. (The faster the people got to shipping something, the faster they could capitalize.)
The managers need to change how they work. The managers need to resolve these impediments.
I asked the managers which goal was more important to the managers:
- Measuring an individual’s work.
- Shipping working product to gain more revenue.
No, I did not offer a third option as in the Rule of Three. We were not in problem-solving mode. We were in identify-the-problem mode.
After much discussion, they agreed that shipping product was more important than the ability to measure a single person’s contribution.
Phew!
Now we could work on alternatives to solo work to address the teams’ resilience. We next attacked the feedback loop problems.
The series (I’ll add links as I publish):
- Build Team Resilience: Work Together (Part 1)
- Build Team Resilience: Shorten Feedback Loops (Part 2)
- Build Team Resilience: Work “Anywhere” and “Anytime” (Part 3)
- Build Team Resilience Summary (Part 4)
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Build Team Resilience: Work Together (Part 1) Opinions expressed by Java Code Geeks contributors are their own. |
