Moving at the same pace involves ongoing growth

By introducing effective feedback loops rather than long slow pieces of work, teams learn faster and thus have the opportunity to substantially improve the value of the product that they create or the service that they provide.

But this is only half of the advantage of implementing effective feedback loops.

If you believe that team members, with all their diverse skills and abilities, are valuable assets, then the same feedback loops should also allow the team to more effectively invest in their own development, becoming an ever stronger team over time.

To me, this is actually the greatest advantages of operating in an agile way.

Some teams are happy to stay the same

Not everyone sees growth as the greatest advantage of their way of working though.

Some teams are great at removing impediments and changing work practices, but do not have time for honing and sharing their skills and talents.

I guess this would be OK if the team were skilled enough to do their work and the world they operated in was not changing.

A fictitious stable world

Some dodgy mathematical modelling

I have some bad news though. All the teams that I work with exist in a changing world.

In a changing world, if the team’s skills stay the same while the world is continually changing, then their skills are gradually becoming less relevant and this decreasing relevance has a large impact over time.

If the team becomes 1% less relevant each month, then they are 12% less relevant at the end of each year.

They are less safe in their roles, they are adding less value to stakeholders and they are less resilient if a major shock or change occurs.

A sad team working hard but becoming less relevant

Where the gap is small, the team can make up for it by working harder and by increasing their reliance on one or two key people. But where this is the case, the team are becoming less resilient and if they do face a major shock or change, then the impact will be worse and the time to get back on top of things will be longer.

In the extreme, one major shock can leave the team reeling, struggling and working even harder and while relying even more on one or two key people … when the next shock hits and then one after.

It follows then, that if your skills stay the same and the world keeps changing, then you are effectively depreciating the value of your people. In my last article I said that you can depreciate your team and then sell them for scrap. But I concluded, as I hope you would, that this is a bad way to manage valuable resources like talented humans

On the other hand …

If each team member becomes just 1% more skilled each month, then each person is 12% better at the end of the year.

But actually there is a compounding effect here for cross-functional teams, because each team member can now rely on people who are 12% improved as well. This means that each person can actually see a 25% improvement over the year (1.12 * 1.12 = 125% improvement compared to the year before).

Note that this does not even need to be a new skills being added. It could be some more people being able to do something that only a few could do well, or it could be a better ability to work as a team. It can even be honing existing skills instead of allowing them to plateau.

In this scenario we have increased capacity to give value to our clients, increased resilience in the face of shocks and change and increased capacity for the team to expend less effort getting the work done.

You might not agree with the exact figures in my dodgy models, but hopefully you agree with the over-all trends. So let’s assume that there is at least a chance that I am right.

But do you have time to act on this?

The team are probably quite busy, so if they see personal development as something they have to do on top of their existing work then they will probably not find time to do it.

But if they can integrate development into the work that they are already doing then they can probably achieve that 1% improvement in a sustainable way.

That is one of the key messages in the book “Atomic Habits” by James Clear. But even if you don’t read the book, you can simply use agile approaches to maintain good habits in your team.

A simple fix is to talk about what skills, traits, experience etc helped you deliver success and which skills and experience could enhance your ability to deliver value next time. But there is a subtle point to remember here.

If you agree what skills you need and only talk about who you can exploit use to deliver work, then you are effectively treating people as consumable resources. If instead you ask who you can involve to both deliver the work AND learn about it then you are treating people as valuable and you will have a stronger team each month.

That much should be easy and should be common practice.

Other approaches

Skills that do not need improvement?

In some cases you can use a team of expendable people who you want to use for one short piece of work. You could use the people in your team to continuously do simple work without growing. Unfortunately I still think they will become bored and stale.

A better approach for this kind of work might be to go to a website like . Explain what you need to people who do that kind of thing for a living. They will then let you know if they think they can help and then you then pick the people who seem well suited, use them and pay them.

There is nothing wrong with this and I often think we should do it more. Especially where we want to access generic skills or access capabilities that we do not have in our team without having to go to a lot of trouble to bring new people into the team.

Or you can look for ways to make the services “self-serve,” teaching your customer to do it themselves and equipping them with some simple tools instead of you having to repeat the work each time. This increases their skill and leaves you open to improve yours.

But where your work relies on cross functional skills being integrated together, or where you want to use the same people again and again, then you want them to learn from each experience, rather than just submitting their work and moving to the next assignment.

In my view it is part your job as a professional is to continually work on your own capability, as well as teaching others.

James King

Integrating learning into your story wall

Many agile teams use Kanban wall and things like that to make their work visible. But if the team see improvement of team skills and career prospects as part of their work, then they should probably be making their personal development work visible too.

Some teams do this by adding some user stories for team members and tracking them as part of their sprint goals each sprint.

As a junior developer I want to learn more about the Assyrian Numerology Framework so that I can improve the magical alignment of my code when it is used by mortals

Attributed to Developer Dan – Possibly not a real quote

However, some teams use the structure of their story wall to also facilitate their ongoing learning. By adding a column or an additional row, the team can track the learning involved in stories as well as the value delivered to clients.


The way you work involves habits and opportunities. If you deliberately build in habits that build capabilities and you find ways to make your skills and abilities visible so you can scrutinise them, you will continually grow stronger.

If you make your skills invisible and build in habits that restrict the opportunity for personal development then your team will slowly grow less resilient and less effective, even if you work hard.

So even if you want to maintain your current results you should be using your way of working to maintain and invest in your ability.

Of course, if you have been reading my recent articles, you will notice that all this improvement comes from single loop learning. If we add another loop we will see even greater gains. So if you take time for succession planning and capability improvement outside the daily grind then you will see an even greater return on your investment.

If people are assets, can we claim depreciation on them?

I sometimes talk about people as resources, even though I am told not to.

Apparently people should be called “talent” or even “people,” but I have an old mindset and I still think of them as people who should also be useful if they are in this team.

I also still think about questions like:

  • Are we the right people to get this done?
  • What do we really need to Excel at here?
  • What can we do at a basic level? and
  • What should we learn from this to do this better next time?

These sound like people focused questions but I am not really being nice – I am looking to exploit the right resources and also acquire and build the resources I need to create value.

Bare with me though, I have a finance degree and studied some economics, so I learned to see things a little differently.

People have intrinsic value

I believe that people have a right to freedom and happiness, because of the simple fact that they are human. I also think that they deserve dignity and other rights.

But I actually think there are two reasons that people deserve things:

  • Because of who they are. All people deserve dignity
  • Because of what they do. If you are naughty you might deserve to go to jail and at the opposite end of the spectrum my friends and I used to rate favours as a “one-beer favour” where I would buy you a beer if you came to the party to me or a “carton” if you looked after my dog for a weekend. You earned the right to a drink if you did something you would rather avoid, but that helped me out.

So – I should treat all employees, customers and suppliers with dignity. This is not because they are useful resources for my team to use, it is because they are people.

But if they want to be people who work in my team, or vendors that I rely on, then I expect something more. If they want to be in the team then they must, through their actions, be useful to the rest of the team.

Here “useful” might mean people who bring energy to the team rather than sucking energy from it, or perhaps they have skills I lack or a viewpoint I would not have come up with on my own. Either way, I expect that they bring value to the team and in return the team should provide value to them.

Why are these people in the team? Do we really need him? Why am I in this team?

Me right before people suggest I word things a little more gently

If I want value then I must provide value

I expect people to pull their weight and contribute if they are in my team.

However that cuts both ways. If a team member is contributing to the team but we are providing them with nothing in return, then that is exploitation.

What do you need from me to do your best work? What are you hoping to learn while you are here?

An early manager I had

Pay for expenses but invest in assets

In economics you can exploit resources if you think of them as expenses (we pay per hour for this resource so that is all the value we need to exchange for their services) or if they are Consumable resources (something we can dig out of the ground until the mine runs dry … then dig another whole somewhere else).

This cold blooded approach might work if I simply hire people for temporary physical labour or if they provide a clearly defined service for a fixed price. But that is not the case with the people I have in my teams.

People are assets

If we are not simply exploiting resources then where does that leave us? If people are not merely expenses, then perhaps we can think of them as assets.

Assets are things you invest in so you can gain some value. I used to hear people say that “people are our greatest asset.” I assumed this meant that, of all the ingredients we need for success, it is the people that I should spend the most time protecting and growing.

But sometimes it seems like this is not what people mean. Sometimes it seems as if people are thinking of team members as Fixed Assets.

A fixed asset is one where we invest something in them (some training, kindness and stuff for humans or a purchase price for a machine). Then we claim depreciation on them until they burn out, at which point we sell them for scrap and purchase a new asset.

People are our greatest asset, which means that we can claim depreciation on them. With that in mind, we should burn them out at a rate that ensures they can still function for the life of the project and then we can sell them for scrap at the end of it.

Said no manager ever

Nobody I work with would suggest that and people assume I am joking when I say it (which I am). But if I observe people’s actions then sometimes I wonder.

If we thought of people as fixed assets, then we would bring people on board and flog them as hard as we could without them collapsing. If some were willing to work each weekend then we would let them, saying its a shame we can’t hire more fixed assets but not really looking for a resolution since people were still capable of delivering.

Then, ideally, they would be exhausted and unable to really give us their best work again – right when we finished our project, completed our mission or delivered something to our clients. We would have gained the maximum return possible and the asset would be disposed of. It sounds so bad when I say it that you would imagine nobody would do it but I have seen it in practice with good people doing this to themselves and others.

The depreciation approach to “fixed assets” might sound like an attractive option if you are, in fact, quite a nasty person. But it is deeply flawed, not just ethically but also economically.

Not all assets depreciate over time

This is because people are not fixed assets that deteriorate with time. They are “Growth Assets.” This kind of asset is worth something today and you pay that value to gain access to the asset, but then the asset increases over time and is worth more in a year than it is worth today.

For example if you buy the right stocks and shares they increase in value. Some of these assets are “fire and forget” and you simply buy them and hope for good fortune. But other assets, such as a company’s brand, require ongoing investment to help them grow in value. This is similar to buying a house and maintaining or renovating it rather than letting it deteriorate.

Team members (people in our teams) are really growth assets like these. They are resources that help you get the job done today, but rather than losing value they should increase in value as you interact with them.

The more people know about the mission then the more they can contribute. The better you know each other, the better you collaborate. The more someone writes code or publishes research, the better they get at writing code or publishing research.

People are bundled assets

Unfortunately people are also “bundled assets” rather than un-bundled. This means that we take them on as a whole. We cannot just but their knowledge, their enthusiasm, their perspective or their personality as a separate thing. You cannot take Mary’s enthusiasm but discard her lack of expertise and mix that with Michael’s skill in auditing while avoiding any investment in his annoying habit of talking about his hobbies.

So I get that people are human and that as such they have valid expectations that they will be treated with respect, I also get that they should be rewarded for their effort.

But if they are also human resources, then they can either be expenses (pay by the hour only when you need something) or growth assets (continue to invest in them so they increase in value).

In knowledge work and most team work, I think you will quickly see that the knowledge and capability people bring to the team will increase over time with a little investment in the right areas.

To me this seems pretty obvious, but it seems to be missed when some teams are busy. Let me give you some examples of the behaviour I would expect based on how I see the people in the team:

SituationPeople are nicePeople are expensesPeople are growth assets
RestructuresCommunicate well as you move people from team to team, introducing them to new friends as they moveMove people as needed to ensure you continue to gain revenue from them at all times.   

Put teams together on the basis of headcount needed to ensure you apply your expenditure to the right areas  

Shed those who will not transition easily and find new resources to replace them.
Ensure if you move people around that you retain and build the skill, knowledge and relationships that you and they have invested in.  

Structure the organisation with this in mind, ensuring that these things are enhanced rather than diminished with each decision to restructure
Initiatives, sprints and business as usualHave fun and hopefully deliver value along the wayEnsure you get everything you can from people with the limited time and money you have to “spend”Deliver value by leveraging the assets you have (people’s energy, knowledge, relationships, intellect) and simultaneously build these assets so the team is stronger at the end of the initiative than the beginning
FeedbackAlways be nice to people and avoid unpleasant conversationsBe very clear on what you want so you only pay for what you need.
Complain immediately if you don’t get what you want
Give feedback on where you think their capability can be enhanced and ask for feedback on how you can help them to both build themselves as an asset and improve the value they can contribute in the current team

Ask them to do the same for you

OK that is my view. It does not really seem to matter and this probably sounds like me having some fun with terminology.

But I have encountered some agile teams recently who are working people really hard with the apparent knowledge that it is unsustainable. This only makes sense if the team can continue to provide value without depreciating in effectiveness and value (ie they are an expense) or you plan to invest in them later to help them recover and recoup their energy.

I have also seen some teams that treat each other well but are not actually giving people a chance to grow. They are too busy getting their work done to actually question what the team are doing to increase their value. They use stand-ups to remove impediments and retrospectives to look at changing their operations, so their is some growth.

But they are continuing to get more single point sensitive each sprint and they are struggling to find time for anything but delivery. Their backlog of work is slowly growing in complexity, their documented knowledge is way out of date and their products are suffering from technical debt (ie increasing entropy). The team are aware of this but too busy right now to cope. And along with that, they are no longer mentoring people as much (since people can now deliver adequately), people are no longer taking the time to hone skills or grow new ones and people are slowing starting to feel stale and burned out.

This is not the goal we want to achieve if ether we seen people as nice or if we see them as bundled, growth assets that provide a critical resource that we need to protect and grow if we want to create value.

So my next article will look at something that agile teams and high performing teams should truly excel at – succession planning.

If you live in Sydney you might have seen some of my material already and if you read my article on “second loop learning” recently then you know everything you need to know.

But I will still go through some tools you can use to introduce a little more second loop learning to team capability growth beyond going on a training course at the end of the project.

Using a story wall to add learning

A story wall helps us to focus our attention on the present, by allowing us to take a snapshot of the state of our work in any given moment.

Doing so allows us to see bottlenecks and priorities and generally take better control of our work in progress.

But in my last article I mentioned that we can extend the use of our story wall to help the team apply “second loop learning” as well as managing their daily work.

I do not intend to explore second loop learning here again in detail, but I do intend to show how a story wall can help people park information and then group it to observe larger patterns and learnings. Doing that will partially enable second loop learning and also support continuous improvement.

There are (at least) 3 simple approaches to doing this:

  • Adding an extra row to the story wall;
  • Adding an extra column to the story wall; and
  • Sticking stories onto a second “learning wall” to look for issues and opportunities that are common to multiple stories.

Adding a row to the story wall

An extra row

Some teams have multiple rows on their story wall. Perhaps a row for each team member or a different row for project work and BAU.

However it is also possible to have the second row as the “second pass” or “do-over” row. This additional row sits empty where things are working well, but comes into play when a story needs more work after it was allegedly finished or when the team find defects.

For example, team “A” release their features into production on Monday, but customers discover issues or make support calls. The release is placed in the second row and the team track the issues that were found as normal stories.

At the end of the “sprint” or warranty period, the team bring the done stories from the second row into their retrospective and discuss how they might improve their delivery of new stories to anticipate and reduce the issues that occur in production.

Team “B” do something similar but they use the second row for stories that fail in testing before release. They move the story to the second row and pass it back through each stage to re-assess, re-elaborate and re-code the story.

They can then focus on clearing the “defective” row before adding new work, which is nice, but they can also review the stories in the “done” column in their showcase and retro. They can assess the percentage of stories that failed in testing and also discuss what caused those failures. The aim, of course, is to also identify the reasons stories ended up in the second row and then identify ideas for reducing defects in the future.

Team “C” do not use the second row as a second pass lane but rather as a special story lane. When they commit to a story they choose to put the story in either the standard lane or the learning lane. Most stories go in the standard lane, but stories that involve single point sensitivity or special skills that some team members want to learn go in the learning lane.

These learning stories are treated differently because the team has agreed that they will slow down to let team members learn as they work on them – perhaps there is more peer reviewing, pair programming or even training and walk-through sessions as the work is done. Doing so highlights the capacity of the team for additional learning and also allows the team to consciously commit to learning on stories, taking longer to get work done today in order to build resilience for tomorrow.

Adding a column to the story wall

An extra column

Rather than adding a second pass row, the team can add a “learning column.” This is where stories go when they are completed but there might still be something to discuss.

For example, team “A” might put a sticker on stories that the team want to review. Then when the story is done it moves into the “learning” column to be reviewed in the next retrospective. Team members can explain why the story is there and what they want to explore – maybe the story bounced around between columns or failed testing several times, or maybe it just sparked curiosity.

Team “B” might leave all their stories in the learning column for 10 days after they deliver them to clients. After 10 days they survey their clients and then see if there are additional things to learn while the story is still new and fresh in the client’s mind. These learnings then feed back into the team’s approach for future stories.

While both the extra column and the extra row are easy on a physical wall, the extra column is probably easier to apply with an online story wall.

Team “C,” however, go a step further. They regularly take the stories from the learning column and move them to a separate “learning wall.”

A “learning wall”

A learning wall

Perhaps the team take all their defects and put them up on the wall, or perhaps they add any story that promises further learning.

The team put all these stories up on the wall without worrying about priority or structure.

Next, they take a step back and look at all the post-it notes. They group them into whatever categories they like and then look at patterns. You can follow this link to see instruction for doing this as an “Affinity diagram“.

Once the team see patterns then they can simply talk about what do with their new information. For example if there are a lot of issues for smaller clients then this might alter the discovery and analysis work the team does.

Perhaps the team only do this every few weeks or perhaps the clumps of stories stay on the wall and people review the new learning stories each week to see if they fit into existing clumps or create new groupings.

But seeing clumps of information might not be enough. The team might wish to move to action.

In my rough diagram the team are using a “CIA table“, which they teach in kindergarten, to look at what they can do. They grab one clump and then look at what they can control, influence or accept.

They might also use a “How might we” table, a “illness approach” or even the forgotten, complex but fun cause-effect clock.

Some teams go even further, using ishikawa cause-effect diagrams and pareto diagrams to be more scientific in their observation and learning. But you can look elsewhere to cover off those approaches. Once you do though, you can still start simply by taking stories from your learning column (or row or wall) and then stepping back to learn more from the stories as a group than you would looking at them as individual events.


All of these approaches involve a little more work, but you can experiment with them cheaply and you might find that they make new learning available to the team. You might also find that there are constraints and assumptions that you have been making that, once they are visible, are worth challenging.

So don’t commit to do them forever, just adopt one approach and try with your existing retrospectives to keep them fresh. Then see what happens next.

What happened to double loop learning in agile?

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 1970’s 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.

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.

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 “agilese” 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 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 does 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 the actions we take and allows us to reflect on the reasons that we do things in the first place.

This in turn goes beyond doing work faster. Constantly questioning around why we do things and even if our current journey is still worthwhile allows us to notice when the world changes or when priorities should change. This means that agile teams should, in theory, be learning machines that adapt as the world changes rather than continuing to execute on an outdated set of assumptions.

My view of the success of agile is that as the world changed radically, teams who could make themselves aware of that and then adapt became resilient and successful.

So it is all good then – right?

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).

Thus 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.

James King

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.

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 “pre-mortem.” 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 you 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)?