If you’re like many of the teams I meet, you’ve sort of got a handle on things. You can release. Your product mostly works.
And, then Something Happens. And, your team has trouble recovering.
That’s brittleness in the system. You can build resilience as a team. In this post, I’ll summarize how your team can build resilience.
Start by Working as a Team
If your team works in flow efficiency, as in Part 1, your team collaborates and learns from each other. And, when teams use flow efficiency, they see these benefits:
- One person doesn’t act as a bottleneck for their function or expertise. If you only have one tester, the team collaborates to test when that one tester is busy. Or, if the team needs the database expert and that person isn’t available, the team learns together. The first couple of times, they might have to wait for the expert, but they learn enough to integrate that person’s expertise for the future.
- The team can see where they are. They don’t need standups or status meetings.
- The team’s cycle time improves. They release their work faster.
In my experience, the project also ends faster. (This is any lifecycle, not just an agile approach.)
Shorten Feedback Loops
Next, I suggested that the team find ways to shorten their feedback loops, in Part 2.
I suggested that first, you see your feedback loops. (I used the image from Capitalizing Software During an Agile Transformation as a way to think about the feedback loop realities in a serial approach.)
I recommended various ideas with “testing” in their names (TDD, BDD, ATDD). The testing part is really about using examples and small tests to guide design. I offered how I use the examples/tests in my writing now.
Learn to Work in Multiple Locations
The third recommendation was that teams build an environment so they don’t have to work in the same place, at the same time. See the “work anywhere” ideas in Part 3. The more organizations that want to have people work from home, especially now with the coronavirus craziness, the more teams need great workspaces.
BTW, I don’t advocate people work all hours to try to create a “team.” All teams need sufficient hours of overlap to work as a team.
Let me explain again why resilience is so necessary.
Resilience Helps Us Create Options
When we notice a problem, we need to generate options to solve that problem. If we always work the way we’ve always worked, we have no options.
I prefer using the Rule of Three to generate and test my options. (One option is a trap. Two is a dilemma. Three options start to offer real alternatives and maybe help me see even more options.)
We need to believe in ourselves enough that we are ready to take that small step and experiment.
If we don’t have the support of our team, we might stay stuck. We can’t continue because we’re judged by our individual contributions. Think about this a second: Does anyone work without a “customer” or a “supplier”? (Nope. Everyone has at least one of those. Otherwise, you’re doing work that no one wants.)
The more we practice taking those small steps and experimenting, the more resilience (and adaptability) we can create.
When we shorten feedback loops, we can tell if we’re working on the right work. Or, if we’re working right. We learn as we proceed.
And, in these uncertain-health times, I recommend every team learn to work in a distributed way. (If you want more information, please see From Chaos to Successful Distributed Agile Teams.)
Build Resilience
My call to action: build resilience in your teams. That resilience will offer you options at the organization level, not just in your teams.
We need managers to help build resilience. Managers will have to spend a little money on licenses and maybe on tools (for Part 3). Managers will have to reward technical excellence so the teams can use all of the “test” approaches I suggested in Part 2. And, most importantly, to work as a team (Part 1) managers will have to work with HR to stop rewarding individual work and reward what teams create.
In my experience, all these ideas not only build resilience, but they also make work more fun.
The series:
- 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 Summary (Part 4) Opinions expressed by Java Code Geeks contributors are their own. |
