News

Back in my day times were hard. I don’t want to shock you, but my corporate life began last century before even Twitter and Slack existed. You can imagine how slow-moving and inefficient we were, but we knew we could do better and so we focused on improving.

We came up with many new ideas, both large and small. Some were great, like empowered work cells, while others turned out to be ineffective and were quickly forgotten.

We also learned from our corporate elders, some of whom lived so long ago that they remembered communicating by paper-based letters. Paper-based letters were kind of like emails but it took over a day for the person to receive your message.

One of the ideas that was already around when I started work was “double-loop learning.” Apparently it originated in the 1970s and it was already old news when I started work. But it is something that I learned from my corporate elders and it has stuck with me ever since.

Double-loop learning is differentiated from “single-loop learning,” which is also a good thing.

Single-loop learning

We learn by observing the result of our actions.

Single-loop learning is based on the idea that you learn as you work. For example:

• You respond to an event and then pause to reflect on what happened;
• You do something and reflect on how it went or seek out someone to peer review your work before you send the email/paper-based letter; or
• Someone tells you how to do something, you try it and then you seek feedback on how well you did it.

This was all happening back before agile became mainstream. Tyrannical leaders thought they were more important than the unfortunate teams they micromanaged and ignorant workers still relied on “waterfall” and other “old” ways of working. Fear was as common as trust in some places if you can believe that.

But single-loop learning still exists in agile teams. We hold stand-ups, showcases and retrospectives. We test our work as we unleash the outcome on people and we seek frequent customer input as we build awe-inspiring solutions.

Adding another loop

So what is double-loop learning then?

Based on my understanding, double-loop learning starts with the idea that our actions (code writing, testing, stand-ups) are related to our assumptions, values and our understanding of the problem we are trying to solve. In “agile” that translates as our mindset and goals.

Actions follow expectations.

A bureaucratic team would have a stand-up because it is in the scrum guide, while an agile team would have a stand-up because they intend to improve collaboration and obstacle-clearing. Even the running and outcome of that simple meeting would be different for the two teams because they expect different things from it.

Here is a more generic example that was in the article I Googled this morning.

If a teacher thinks that his students are stupid, then this will alter his teaching approach, which will alter the outcome of the teaching. The students will fail to learn, confirming to the teacher that the students are indeed stupid. The teacher might continue to refine his teaching approach and curriculum, but since it is based on the assumption that students are stupid, he will always get the same result.

"Whether you trust people or not, you will usually prove yourself right." 

"Whether you think you can do it or not, you will turn out to be right."

- Common sayings in my family.

This is where the second loop of the double-loop learning comes in. Whatever the official goal that we claim to be pursuing (eg the teacher tells the parents of the students that all the kids have potential) it is the “theory in use” that we act (the theory that the kids are stupid) and our after that follows on from the result of our actions (the kids failed to learn, in spite of my hard work. I guess the next step is to set an exam before we accept students into this class, to weed out the stupid kids).

Whatever the teacher says officially (we want to bring out the best in all kids), the teacher’s learning is forever inhibited by the constraints of his current theory in use. Even if the next generation of kids do better, the teaching approach will always be based on flawed (or invisible) assumptions.

Questioning our expectations leads to new learning.

The second loop of learning is where the teacher pauses to reflect on his own thinking and learning.

"I wonder how my attitude to the kids might be impacting their learning? Kids keep struggling to learn at this school. If it is not because they are dumber than the kids at other schools, what might be different that I can change to help them learn better?"

- A teacher who is likely to learn to teach better.

Double-loop learning requires us to consider why we even have our processes, not just how to make them faster and less error-prone. It requires us to pause and reflect on the assumptions that we make and the reasons behind our actions.

Agile and double-loop learning

All of this double-loop learning is possible in an agile approach. In fact, I would argue that the reason agile has become mainstream is related to this. It is not the cool jargon nor the “faster to deliver” claims we all pretend we don’t make that led to agile teams to succeed.

Agile teams succeed because of the way they systematically review assumptions and opportunities through action rather than analysis. The constant testing can be described as constant learning, while constant collaboration could be described as constantly having to confront our differing assumptions and then finding the shared truth in our different views.

This deeper learning goes beyond simple error correction in the actions we take and allows us to reflect on the reasons that we do things in the first place.

All this learning is awesome, but a few years ago there was a hint of trouble.

Back in 2004, Philippe Kruchten proposed that to “scale agile up to large projects” we should actually scale the work down to suit the team. He published this pretty good guide to feedback loops and proposed an approach that would allow learning across teams (including double-loop learning).

Rather than simply executing at scale, teams would learn and adapt at scale. Or, in the absence of the ability to learn at scale, teams could identify obstacles and erroneous assumptions that would inhibit their ability to become agile.

I assumed as a result that Philippe would be a really agile guy. But when I met him he challenged my assumptions almost right away. He actually claimed that there was a pattern where agile teams were creating technical debt because they adopted an agile approach. They were often faster to start with and then slowed down to a crawl because they lost control of their architecture.

What an outrage to all things agile! Agile teams refactor and constantly remove waste – they don’t create systemic waste that leads to their inevitable destruction.

The cause was, allegedly, that technical teams were listening to their business stakeholders and building things quickly to meet those needs rather than taking the time to design something resilient and robust – in other words they were building features quickly but forgetting about their core architecture.

Don’t worry. Whatever you build will develop it’s own architecture no matter what you do. It just might not be the architecture you were hoping for.

In theory, evolutionary architecture should allow for double-loop learning. We test our architectural assumptions through actions and then adapt our assumptions and future action based on what we learn.

Ignorance is not bliss.

But if teams are ignoring their architecture then they are not learning and not adapting.

It could get so bad that the only lessons they are learning are from the showcase. This single loop of learning would then constrain the even see the more holistic impact of their actions.

They are, in effect, trapped by their limited grasp of the problem in the same way my example of a “bad” teacher was constrained.

Instead of saying “these kids are stupid,” the team is saying “we need to meet these tight business deadlines, so we don’t have time to integrate a long term view into what we are building.” This might not be the official line the team are espousing, but it is the “theory of use.” It is the thinking that is driving their actions and also limiting what they are learning from their actions.

This worried me a bit and if it makes you curious then there is a lot more to explore here. Philippe explores this a little further and looks at how to avoid systemic doom in some articles and a book.

• Some old articles that are still relevant.

• A new book that I am yet to read, but that should be good.

Our only hope would lie in the possibility that the robots would be bug-ridden and so full of technical debt that they were too slow to move and catch anyone.

From technical debt to burnout.

But then I noticed that some teams were rushing to be first to market, but forgetting to slow down to allow the team to recover after they got to market. People working long hours under constant delivery pressure are unlikely to have the time and bandwidth to reflect on their assumptions and values.

I think people might be mistaking activity for progress and they might be becoming victims of the systems that they are building.

The end result is a slowing unfolding tragedy that the team are kind of aware of, but ignoring:

People will start acting on deeply flawed assumptions (these students are stupid, or the team are coping and everything is urgent);

The flawed assumptions lead the team to embed bad practices (we better work late, we can’t test for performance); and

The current beliefs create negative learning. People learn to perform better within their flawed view of the world, but they never question or change the constraints that are holding them back.

In theory, the team eventually burn out and everyone is quite sad. But if our assumption remains that everything is urgent and it is up to the team to work hard enough to achieve the nearly impossible activity required today while ignoring the long term impact or the reasons behind why they are struggling …. the next team will start out working hard but eventually also burn out. It is frightening to say this – but it might be possible to burn out two or three teams in a row, before learning that the reasons for their failure had nothing to do with their ability or passion.

Oh dear – are we all doomed?

There is a saying that “to change the present we need to change the future.” 

In other words, if we simply assume that things will end well, then they will probably end badly and if we assume that we are doomed whatever we do, then we are probably doomed.

But if we actually think about what we want the future to be, then we can write that down and start acting in a way that makes it happen. In other words, we can expose our assumptions and thereby change the actions we take – changing both our willingness to adopt better practices today AND changing the future.

A simple way to do this is to do a “premortem.” I describe some simple approaches here, but essentially you just pretend you are doing a retrospective in 3-6 months and talk about what you think will have worked well or badly. Then you talk about what your future selves would tell you to do differently back in their past (ie what you should do now to optimise their retro).

If that sounds like a lot of work then don’t worry – the future will happen whatever you do, it just might not be the one you were looking forward to.

Another approach is just to ask a couple of different questions when your team gets together for things like retrospectives:

• What has changed in our environment over the last few months? If we knew that was going to happen, what might we have done differently? What can we do with that information now?
• If we got to start everything again from scratch, what would we do?
• What have we started/stopped doing over the last while? Was it deliberate? What changes should we implement in the future?
• What assumptions are we making about our work and our team? How might those be impacting how we act?
• What challenges are we facing right now? When have we seen things like that in the past? What did we do then that could help here? What did we not do that might have a positive impact?
• If I saw another team doing what we are doing, what would I think?
• What do I wish was true, that evidence is starting to suggest might not be?
• What do we think is going on here? What is likely to be causing it? If we were wrong about what is happening or what might be causing it, then what else might explain what we are seeing?
• If we were missing something at the moment, what would it be?

You can also alter your story wall to encourage a second learning loop, but maybe that is a story for another time.

For now – do you think we are still learning and adapting based on regular reflection of our values, assumptions and reasons for doing things, or have we locked those down so we can only get faster and better within the constraints of what we currently know (or assume we know)?

Posted by James King
Copyright © James King