A learning organisation?
The term "learning organisation", it's often one of the attributes used to describe organisations who have or are looking to adapt to "agile ways of working". Reflecting on more traditional project based practices, the tendency is to focus on forward planning practices, tracking to that and perhaps a post implementation review when you're done.
Why a learning organisation?
Inability to learn and reflect is inherently limiting. If organisations cannot reflect on their products, how their customers use them, consider feedback & review how they work together they can get stuck in a blind push forward, unable to adapt to the surrounding environment- Blockbuster video?
How do we do this?
Scrum and Kanban have embedded practices to support learning and reflection.
Scrum is based on empirical process control theory- fact and evidence based, so transparency, inspection and adaption are built in through the scrum events. Sprint reviews to inspect and adapt the product and retrospectives for the team to inspect and adapt how they work together.
Kanban suggests feedback loops through 4 (of 7) meetings- Service delivery review, Flow review, operations and strategy review.
We use these to reflect on the product, look at the data, customer feedback, discuss how we work together, inspect and adapt, reflect and learn. We build back in what we have learnt about our product and team.
Ye Olde behaviours die hard.
However, despite these events embedded into workflows, invariably in times of pressure to deliver organisations quickly revert back to traditional behaviours that is, plan and execute with inspection and adaption becoming an afterthought.
The risky "Captain's call"
A few years back I was working with an organisation, fairly typical with multiple scrum teams. We were progressing well by delivering small product increments to their digital chanel, reviewing customer interactions and iterating.
Out of the blue we received a directive to shift our focus - there was a desire to deliver a feature that was successful for our parent company and an assumption was made that the same feature would be successful for us.
Curiously, the practice of slicing work down, validating what was of value to customers & to iterate were quickly thrown out, with the drive to build like-for-like in it's entirety.
This type of action comes with huge risk, aside from lack of user research & evidence to support this build, there was also significant development effort coupled with operational (change management) to deliver, marketing, legal. The only evidence being this worked for the parent company (whose products were aimed at a different customer segment #alarmbells. Culturally too, it re-introduced "big bet" risky behaviours and normalised it.
As it turns out, it was the wrong thing, it didn’t appeal to customers and bombed. The organisation was left with a whole product build (months of work), rather than a less risky smaller experiment (and associated cost).
The eagerness to deliver coupled with confirmation bias lead to blindness to the prospect of failure. Success shifted back from delivering outcomes to output. "Just deliver the thing".
In practice this is visible as a shift:
More this - planning & tracking.
Less this - slicing work and hypothesis, data, reviews, showcases, review and action feedback.
Visualising this. Consider Plan-Do-Check-Act cycle or Deming cycle (link below) as a way of embracing continuous improvement. Check and Act may get smaller, or disappear entirely and with it, the ability to continuously improve.
What to do about it?
At times of pressure, I like to consider our ability to answer some varied questions so to keep inspecting and adapting. How to balance a desire to plan forward whilst ensuring we are able to keep learning. Smaller not bigger.
-
How will we know we are successful?
-
What did we learn by doing this?
-
If we were to do this again, what would we do differently?
-
What do customers think of this?
-
Whats the least amount of work we can do to validate our assumptions?
-
How do our working practices best support us, do we have an agreed understanding of our units of work, how we slice work down?
What facts and evidence are we able to look at to help answer the questions? How can we reflect on that and take action to address?
Types of work may change, but it's important to be able to keep reflecting and learning.
Ref:
https://kanbanize.com/lean-management/improvement/what-is-pdca-cycle
Deming cycle https://deming.org/explore/pdsa/