Nurturing Innovation through Continuous Learning
Without continuous learning, innovation cannot happen.
At Agile Open Northwest 2024 (AONW), this theorem weaved itself throughout the open space, reinforcing the imperative that teams must relentlessly adapt to stay competitive in today’s fierce landscape.
Adaptability though doesn’t come out of nowhere.
It comes from a culture dedicated to continuous learning and turning that learning into meaningful change.
Change which makes doing the work easier, effortless, or unnecessary so teams can focus on building and monetizing customer value over working around inefficient systems.
Avoid Dogmatism
Heuristics are invaluable mental shortcuts, enabling quick and effective decision making.
But when they morph into rigid rules, they also morph into barriers to thinking and doing differently: a point underscored by Woody Zuill at AONW.
Heuristics are born out of trial and error.
When it is raining outside, one person may grab an umbrella while another wears a raincoat.
Both heuristics solve for keeping somebody dry, but, an umbrella may get blown away in a hurricane making the raincoat a better choice.
The environment plays a critical role in the effectiveness of a heuristic.
Just like umbrellas and raincoats, agile practices are heuristics learned by teams trial and erroring their way to uncover better ways of working in their business and cultural environment.
However, as their learnings cross the chasm into marketable frameworks, the majority focus on the rules and overlook the environment which made the practice successful: a learning culture which embraced evolution over following a rulebook.
So, many teams copy and paste practices never considering if it is the right practice for them, or, never try to continue to improve their own practices.
But moreover, whatever the practice is, every little glimpse of success hardens the heuristic until it feels infallible.
As Woody Zuill said at AONW, “Don’t be dogmatic.”
Always remain open minded, hunt for inefficiencies, and validate underlying assumptions to continuously improve and learn better ways of working.
A Team Must Monetize Customer Value
It is an inconvenient truth that, despite the mission of a non-profit or for-profit company, it must make a profit to survive; a mandate which trickles down to teams, and, a mandate teams often lose sight of.
Teams must know, deeply understand, and optimize for:
- How to create customer value
- How to monetizes that customer value
- How to know if a project was worth the effort
But, monetization metrics like these are difficult to measure.
So instead, teams fallback on activity metrics as a proxy for monetization because they are much easier to calculate.
Activity metrics like
- How many features were deliver last month?
- How many tickets were marked as done?
- How many bugs were fix?
measure the activity of the team.
But, activity does not always equate to customer or business value.
For this reason, it is critical for teams to deeply understand their customers, their market position, and their monetization strategy to answer questions like
- Which of those features returned on their investments?
- Which tickets created revenue-producing customer value?
- Which bugs were actually worth fixing?
to stay focus on the mandate to be profitable.
Activity is easy, but, activity is only one lenses to help optimize the flow and throughput of revenue-producing working software: don’t let it become the goal.
Throughput Over Utilization
Teams fixate on maximizing utilization at the cost of throughput.
It is a truth that to deliver revenue-producing working software somebody must write the code, but, if every capable person is 100% utilized then the next big opportunity must wait.
This creates an environment where work waits for people: increasing cycle time, increasing the cost of delay, and diminishing opportunity costs.
A common example is a product owner working across teams.
If Team A has a question for the product owner, but the product owner is currently working with Team B, then Team A is blocked until the product owner context switches back to Team A to answer their question.
Maybe this blocker is on the scale of minutes or hours at best, but, those are still minutes or hours increasing cycle time and missed gains because of the cost of delay.
Often though, maximizing utilization cascades into other wasteful practices.
For example, how much time did Team A spend crafting the prefect question for the product owner, and, was that more or less expensive then the product owner sitting idle so they could immediately answer that question?
If the salary cost of the product owner sitting idle is lower than the time spent by Team A crafting the prefect question, then having the product owner sit idle is the better solution.
However, having a mindset to maximize utilization of every person over throughput makes it difficult to see these tradeoffs.
Underutilization, on the other hand, creates a different environment where people wait for work.
This enables people to immediately answer questions or jump on the next big business opportunity; decreasing cycle time, decreasing cost of delay, and maximizing opportunity cost.
So instead of maximizing utilization, focus on creating an environment which maximizes the throughput of revenue-producing working software by intentionally underutilizing people to create slack in the system.
Capability Trap
Similar to focusing too much on activity or utilization over throughput, at AONW the Capability Trap was another reoccurring topic.
The Capability Trap is where teams focus only on doing the work: never doing the work better or more efficiently.
One reason teams may get stuck in the Capability Trap is because teams are 100% utilized and so they have no time to think about improving their process.
Another reason may be more dogmatic or complacent, like they believe they have already discovered the most optimal way to deliver revenue-producing working software and so they don’t feel compelled to do better.
Either way, when stuck in the Capability Trap the only way to increase output is to work more hours.
So, teams brute force their way through productivity problems until it rapidly collapses: people burn out, people quit, or more adaptable and innovative competitors eat their market share.
To avoid the Capability Trap, dedicate time to regularly reflect, learn, and adjust to changes in the environment.
Otherwise, teams and products plateau until more adaptable and innovative competitors eventually pop their bubble.
Tiny Improvement Habit
Tiny, incremental improvements compound into big change over long periods of time to make work easier, effortless, or unnecessary.
So cultivating a culture of habitual tiny improvers is a low cost way to nurture agility introduced at AONW.
Out of the box, teams question assumptions and experiment with new ways of working slightly differently which may yield big ah-ah moments.
But most of the time tiny improvements don’t come out of nowhere.
Instead, they come from learning from or with others in the form of reading, mentorship, or collaborative experiments: investments which require time.
So, invest time on a daily basis for people to learn and discover tiny improvements they are then empowered to incorporate into their daily work.
Over time, this investment into continuous learning will compound into big improvements which will make delivering revenue-producing working software easier and effortless.
Continuous System Improvements
Teams do not work in isolation: they work within systems and optimize for those systems, so, just like teams, systems must also continuously improve to make work easier, effortless, and unnecessary for teams.
But unlike teams which can easily self-organize, self-manage, and self-direct within a system, systems are imposed on teams by managers.
So to change a system, managers must be bought in.
Without active support and commitments followed by action, efforts to improve flounder: stymied by inertia or resistance to change.
At AONW, Woody Zuill highlighted three areas for managers to focus on for continuous system improvement:
- Work smarter by cultivating a tiny improvement habit within teams
- Make the work easier by maximizing throughput at the team level over utilization at the individual level
- Create a slowly expanding bubble protecting a fulfilling work environment
By focusing on these areas, managers nurture a culture of continuous learning which drives improvement, innovation, and adaptability in teams.
Conclusion
Without continuous learning, innovation cannot happen.
If teams get stuck in the activity, utilization, or capability trap, or they get trapped in dogmatic thinking, they stagnate.
Adaptability though doesn’t come out of nowhere: it comes from a culture dedicated to continuous learning from and with others.
A culture which encourages reading, mentorship, and collaborative experiments to uncover better ways of working to make the work easier, effortless, or unnecessary so they can focus on building and monetizing customer value over working around inefficient systems.
But, these same principles also apply to systems thinking.
So managers should be diligent to create a bubble which cultivates a fulfilling environment of tiny habitual improvers: a swarm of individuals dedicated to uncovering better ways of working slightly differently which will compound into big changes over time.
But, managers should also be diligent to focus on the right metrics: the throughput of profitable working software where learning, activity, and utilization are levers to experiment with.
In the end, continuous learning enables teams to think and work slightly differently, and when supported by managers, creates the environment where innovation is inevitable.
