If you only want slow, surface-level change, don’t read this
But read to learn how to make an omelet.
When I was in school, I never got an “A” for messing up and breaking the rules.
This drove me to cautious behavior. I was fearful of trying anything extreme that would tarnish my report card. I — like everyone else I knew — played it safe and did what would get me a good grade and little else.
This “playing it safe” behavior continues for most of us as we enter the workforce. My chosen profession as an Agile coach puts me face-to-face with it daily. Breaking through the old, rigid ways at the organizations I coach eats most of my time.
Most companies hold onto norms that may have once awarded them an “A”. They approach all change with caution in small, safe ways — never straying too far from their status quo. And this is their Achilles heel as they face an ever-shifting context for staying relevant.
The change they need is fundamental. And it is urgent if they are serious about embracing change to remain competitive.
Here’s what I‘ve seen work better for fundamental change than cautious, plodding methods.
Start with radical change
Yes, you can start with incremental change on your Agile journey. It may feel safe. But the result is a piecemeal, diluted, compromised version often worse than before.
Most companies new to Agile have structures and behaviors contrary to Agile values. Incremental approaches to change the fundamentals of this ingrained system take too long. And the old behaviors overcome and extinguish the new behaviors before they have a chance to flourish.
In my experience, most organizations don’t have the patience for incremental change. They often give up, claiming, “Agile does not work here.” The failure of the incremental approach is cited as evidence the Agile mindset does not work.
A better way exists, rooted in lean thinking. This method promotes a radical change of all system fundamentals at once. It is called Kaikaku.¹
Kaikaku uses radical change to alter and reset the fundamental system to a better path. You may have heard of the popular change approach called Kaizen. Kaizen is the application of small, incremental continuous improvements by everyone.
Kaikaku does not replace Kaizen. Rather it complements it. Kaikaku resets the system to a solid foundation. Then Kaizen performs incremental tweaks to improve the system over time.
Here are some examples of situations to apply Kaikaku to reset the system:
- Form cross-functional feature teams: If you organize your teams in functional silos, your teams will not be able to deliver value on their own. Break down these silos. Form cross-functional feature teams with all the capabilities to deliver a customer-facing feature.
- Break external dependencies: If your teams depend on external teams to develop features, break the dependency. Bring the capability into the team or find a work-around so the dependency goes away.
- One-by-one feature production: If your team members each work on a feature alone, change your work-in-progress limit to one. This will create a prime environment for swarming, mobbing, and pairing on one feature at a time. Collaboration goes up, improving your flow, cross-pollination of knowledge, quality, and teamwork.
- Throw away status reports: If you have an unhealthy focus on staying on target to an up-front plan, stop focusing on the status of output. Instead, increase your feedback loops and focus on the achievement of outcomes. Invite stakeholders to frequent in-person inspection points, such as Sprint Reviews.
- Engage teams with customers: If you have a separate group or a person external to the team engaging with customers, remove this silo. Instead, allow the product teams to have direct engagement with their customers. They will gain empathy and deliver better products their customers need.
- Use goal-oriented roadmaps: If your product roadmaps are a list of features to deliver by a certain date, stop the madness (read what Maarten Dalmijn says about the perils of bad roadmaps). You are only creating the illusion of predictability. Instead, use goal-oriented roadmaps with specific metrics that show goal achievement. Then, have a frequent reflection on how well your output meets the goals, and pivot as necessary.
- Allow the team space to self-manage: If your organization has a command-and-control culture, make space for teams to self-manage. Instead of requiring complete transparency so you can control behavior, give teams privacy. This allows them to learn how to make decisions on their own. Teams will still ask for help when they need it, and managers free up to remove obstacles the team can’t remove.
Apply radical change in a small way
Radical changes make deep, fundamental shifts to jump-start the system onto a new path. I see most companies shy away from this because of one critical flaw in their thinking. They see it as an all-or-nothing proposition.
Companies assume the entire organization needs to change. This makes the change seem scary and stalls action. Many would rather wait — until the organization matures or the timing is better.
Timing never gets better.
Radical change does not have to be large scale. Applying radical change through a small experiment has a lower blast radius. Less chaos ensues, and results reveal faster to build confidence or prompt you to adapt.
Here is one thing to remember: as you start experimenting, give the radical change a chance to normalize. Your first few tries may be failures until you get the hang of it. Be patient and keep at it.
Here are some ways to apply big change in a small way:
- Create one cross-functional feature team and reflect for many Sprints on the results. Adapt as you go.
- Pick one external dependency, and break it, bringing the capability into one of your teams. Inspect your cycle time before and after the change.
- Have one team try a User Story WIP limit of one for one Sprint, and inspect the results.
- Try no status reports for one or many teams for one Sprint and reflect on the results.
- Perform one experiment of direct engagment of the team with its customers. Do this for one Sprint and reflect on the results.
- For one product release, enact a “no due date” policy. Use a goal-oriented, empirical approach to adjust your course based on evidence.
- For one Sprint, commit to a Sprint Goal instead of a Sprint plan or list of product backlog items.
- For one Sprint, let one team manage itself and inspect the results in the Sprint Review.
The takeaway
If you are hanging on to your pervasive, old patterns and stagnation has set in, you are on life support. Your survival depends on fundamental, radical change rather than small, methodical tweaking. You need to take extreme measures to orient to an Agile mindset.
Radical change does not have to upend your entire company. You can isolate the change to a specific team, for a short duration, or for one experiment. This allows early inspection of the new way to build confidence and adapt your mindset.
Today’s product development world is not about following a recipe. Now, to get an “A” you must try new things, shake up the existing status quo, and make a few mistakes. You need to embrace change and learning to come out on top.
As the saying goes, breaking a few eggs is the only way to make an omelet.
For more content like this on my pursuit of Lean Leverage, delivered to your inbox, you can just join my email list. Or see my other related posts below to dive even deeper.
References
- Kaizen vs. Kaikaku, Gemba Academy, Jon Miller, March 3, 2020
Related Posts
For similar topics, read the posts below:
