Agile culture is about the ability to change. (You need to know why you want to change, but once you know that, agile cultures promote change.)
We (as agile teams and organizations) deliver something to get some feedback and learning. We use that feedback and learning about what we just did to challenge our assumptions and experiment with our next (small) batch of work. That’s the essence of double-loop learning. (Teams deliver features, Support delivers fixes/workarounds, and managers deliver decisions.)
Many organizations—and people—are not too facile with change. Some organizations have multi-year plans, rely on predictions without feedback for project planning, and leave people in the same positions for years and years.
You may have heard of companies that didn’t realize they needed to change their product lines over time. (Xerox might be one of them.) You might work for one of these companies and they want to use an agile approach.
These organizations have the same products for years and years. They can’t seem to create new products. And, they don’t retire old products.
It doesn’t matter if these organizations have research groups, or something called “advanced products” if the organization can’t deliver something new. All too often, these organizations have the same products, the same people in the same positions making the same decisions, year after year.
No wonder their agile transformation gets stuck. The organizational culture works against organizational change.
One way to use agile approaches is to practice small changes. You might even start with yourself.
When I work with managers on their agile transformations, I ask them what they can personally change to get some feedback and rethink that process or product. I sometimes use the word experiment, but not always.
One manager said he could change how he drove his route to work. A week later, on our coaching call, he had not managed to change his drive yet.
He had reasons, some of which were:
- He liked to check his voicemail on the way into work and if he changed his drive, he would have to pay attention to his drive and not the voicemail.
- He had already discovered (eight years ago!) the fastest drive. He didn’t want to take more time.
- He forgot. He worked more by checklists/remote control/not really thinking in the morning. He had trouble thinking.
I asked if he wanted some coaching or did he want to consider something else to change. He laughed a bit and said, no he’d take the coaching. He realized he was going to learn something from this.
I’ll spare you the actual coaching conversation. He decided to try these things, which we did not call experiments, but were:
- Research three alternative routes, write down his expected trip duration and the actual trip duration. He would try these routes on his workout days (Mon, Wed, Fri).
- Because Tuesday and Thursday were his non-workout days, he felt as if he had more time then. To prepare for Tuesday morning, he left this sticky on his steering wheel on Monday evening: “Try a different route. Turn right out of the driveway instead of left.” His sticky for Wednesday evening was a little trickier: “Instead of taking the country route A, take country route B.” He was supposed to write down his expected duration and actual durations for the Tuesday and Thursday drives.
- Wear sneakers to drive instead of his normal dress shoes every day. I wasn’t sure if he could do this, but he decided this was an alternative he could live with.
He discovered some fascinating results:
- Every single drive beat his “regular” drive time by at least two minutes. He hadn’t noticed that the construction and changed roads had increased his drive times by 10-15 minutes over the previous 8 years. When he researched and tried different alternatives, he discovered he was not faster.
- He couldn’t leave the house in sneakers. Just could not. He wore his dress shoes.
Here’s the problem. If we want an agile culture of collaboration and experimentation, we have to learn to embrace change, to use experiments and create new possibilities.
This manager’s experiment with drive times—not products, not how he made decisions at work, just driving—helped him see he had many more alternatives than he’d originally thought. He learned the value of experiments and collecting data. He learned about challenging his assumptions.
And, he learned how difficult change can be. He lived the Satir change model that week. (Read Defining “Scaling” Agile, Part 6: Creating the Agile Organization for a fuller explanation of this change model.)
Teams practice change when they finish one item and move to the next item on the backlog. Managers can practice change in many other ways, almost always with experiments.
When you use experiments, especially small, safe-to-fail experiments, you can practice change and become good at it. Each experiment minimizes your risk.
You can help your agile transformation in the same way. If your agile transformation is stuck, or you are in the messy middle, please check out the Influential Agile Leader workshop in Boston, June 7-8, 2018. The super-early bird ends Mar 1, 2018. We can help you articulate your why and what that means for your transformation. Do join us.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Agile Transformation: Practice Change, Part 2 Opinions expressed by Java Code Geeks contributors are their own. |
