If your team struggles to complete trivial tasks or takes longer to deliver some types of work than expected, they could be suffering from high cognitive load. How can you be sure? And what can you do to help them? This post will help you answer both those questions and many more.

My personal heuristics for this are listening out for specific phrases in 1-to-1s, standups, retros, and all your other team ceremonies, things like:

• “It’s too complex…”
• “This is tricky…”
• “X keeps interrupting me.”
• “It’s hard because I keep being distracted by…”

Do these phrases sound familiar? If so, a lightweight exercise we’ve devised called “Cognitive Load Mapping” can help individuals and teams pinpoint where to invest their effort.

Cognitive load mapping is one of my favourite ways to categorise and appropriately tackle the different sorts of work to maximise your team’s ability to get stuff done.

To understand Cognitive Load Mapping, we must first understand its constituent parts.

Types of cognitive load

All of these things relate to how hard it is to learn, and they come from the context of education. There are three types of cognitive load: Extraneous, Intrinsic, and Germane. What even is cognitive load?

Cognitive load

Cognitive load is how hard it is to do any specific task. It is that tongue-sticking-out feeling you get when you’re focusing on threading the eye of a needle or the difficulty of the 46 times table (n.b. if people were supposed to do maths, we wouldn’t have made computers).

The reason you get that feeling is all about the information architecture of the human brain. When you save something to that massive hard drive on top of your neck, the brain works like this: alleged experiences come through the senses into your brain (little epistemology joke there for you), into your working term memory, this is then written back into long term memory. We call this learning. You’re doing it right now.

This is all well and good, but brains both read and write; they’re not read-only. To load a memory from long-term memory, it must be transitioned into working memory, where it is used in concert with current sensory experiences. It’s then written back to your brain combined with those new experiences. I find this intensely creepy because it means those much-reviewed memories are probably furthest away from their original experience.

This is why these concepts are important even in a business context. We constantly learn because that is how brains work: they read, combine new experiences, and then write those back into our brains.

Extraneous

However, there is something I am not mentioning here much like my junior school science teacher who taught me about the states of matter. What about plasma Mr. Trilby? WHAT ABOUT PLASMA?! I don’t want to list all the states of matter but for the record, I think that Bose–Einstein condensates are pretty cool.

There are things that can affect how difficult all of this feels and how successful you are in utilising your working memory. For example, if you were reading an article on cognitive load mapping and you kept being told terrible physics jokes instead. (Cool, as in it occurs near absolute zero, and cool means like… oh, never mind).

That feeling you got just now of whiplash and distraction - that’s Extraneous Cognitive Load.

Let’s break it down. Extraneous Cognitive Load is the easiest to define. It’s poor question design for a task or the person over the road in the VW Polo who keeps beeping in traffic while you are trying to code. It’s the bits you can cut away from a problem to simplify it.

These types of cognitive load are Extraneous, and there are two more types: Germane and Intrinsic. Combined, they make up the Working Memory Load

Intrinsic

Next up, we have the Intrinsic. This is the bit related to the task itself or the problem you’re trying to solve. For example, it is the difficulty in adding two numbers together, or two multiple-choice answers on that mandatory training vs 5.

Try it out; here is a list of 5 words. Look at them, then minimise this window and see how many you remember

• chrome
• missable
• dot
• resignation
• move

Now try it with 10

• transport
• real
• dice
• gyro
• son
• cup
• unbridled
• dice
• leap
• indemnity

That’s me increasing the intrinsic complexity of a task. Notice how I choose 5 items then 10. This is foreshadowing.

Germane

Finally, we have Germane. Germane cognitive load is the schema relating to the current problem at hand.

If I tell you that a trick to remembering words is to create a story to link them all together, I have given you a schema that can be used for Germane cognitive load. Humans are great at remembering stories, binding together words is called “Chunking” and can turn two words into one in your brain. That’s another schema your brain might use to make this task easier.

What’s more, typically, the human brain can remember between seven plus or minus two things. Now, this is more of a guide than an actual rule, and actually, it’s more about the duration of the words and your chunking skills, but it’s a good rule of thumb. I told you it was foreshadowing.

Here’s that list again. Try out those techniques to remember this list.

• transport
• real
• dice
• gyro
• son
• cup
• unbridled
• dice
• leap
• indemnity

Repetition can help increase the amount of Germane cognitive load too.

So Germane cognitive load is the tips and tricks you can use to make things easier for yourself. It’s the brain equivalent to knowing that the 10 times table is the number with a 0 on the end, or remembering the order of the planets is “My very easy method just speeds up naming planets”, or if you are an AI, that rulers are key symptoms of skin cancer.

These tricks aren’t always right, but are very fast for your brain.

Application in Teams

Teams don’t have one giant brain, but they are what we work with most in organisations. So, to apply this to a team, we need to look at generalities in the types of work being done.

There are structural things that can increase the likelihood of Germane cognitive load over intrinsic. For example, in a conversation with Sweller, one of my co-workers asked about the effect of cross-functional teams with experience in many areas. Sweller suggested that teams with this structure may be more able to transfer knowledge of schema between one another.

However, to start with, we need to examine a team’s activities and determine where they fall in each of the previously mentioned categories.

Running cognitive load mapping

Before you start, you want to frame your thinking in terms of the goal that your team is trying to achieve (and it’s never bad to find opportunities to remind yourself and everyone else of it).

I’ll run through this for a chef so you can see how this works.

Identification

The first step is to work out what you do, what disrupts you, and things that are “hard”. You can do this individually or as a group. I would recommend trying a first run alone, as I found that I needed a few tries to really understand the difference between the types of cognitive load. Alternatively, you could use 1–2–4-all with your team to pull together everything your team collectively does.

A good way to get a sense of these things is to keep an hourly journal, where you record hour-by-hour what you have done during the day. These don’t need to be shared with anyone, so no one needs to know precisely how much time you spend on TPS reports.

Another good place to look is your old retrospective boards. You can pull out the most common feedback about negative and positive things. Finally, a quick look through your calendar can jog your memory.

Sorting

Once you have the pile of “stuff” that you do, the next step is to sort them. Split them into three columns. Look at each thing and decide if it’s primarily Extraneous, Intrinsic, or Germane.

My rule of thumb is this: Does it primarily elicit positive feelings of ease and completion? Well, that’s probably Germane. Is it hard but important? Well, that’s Intrinsic. Could it be cut away or replaced, and it elicits negative feelings? Well, that is probably extraneous.

Experimentation

Once you’ve identified Germane, Intrinsic and Extraneous cognitive load, you can start to make improvements. The best way to do this is to use a practice from lean product design, the experiment. Firstly, select one of the items to work on. Dot voting is how I recommend doing this, but you could also use the cost of delay to rank the importance of each activity if you are alone.

You want to maximise the Germane, minimise the Extraneous, and simplify the Intrinsic. So, for each of these categories, we have a way to improve the situation.

You can simplify the intrinsic through training courses and building the schema to enable germane cognitive load. Other examples include deliberate practice and peer-to-peer learning.

You can optimise the extraneous by either reducing or eliminating it. Sometimes, this means no more TPS reports, other times, it might mean moving to a quieter meeting space or moving meetings to a single day in the week.

The germane is what you can look for success. To maximise the germane, look to what it does and then see if you can apply what makes that a success to other activities that you do. Alternatively, find ways to simply do more of it. If the continuous delivery pipeline made deployments easier, add it to more projects.

Once I have some ideas in this section I like to plot them onto an experiment sheet. Coming up with a “Learning Goal” about what we want to achieve with this experiment, what our assumptions are regarding the experiment, the metrics we will record, what will indicate failure or success, and an early stop mechanism to help us fail fast and move on..

I’ve attached an example of the template I use for this, made by another AK-er, Benedict Steele.

It’s also important to note down the constraints of the experiment, your plan for monitoring it, the duration, and how you will share it with others.

Conclusion

And that’s it! You’ve run your cognitive load mapping session. I find this a really useful tool to ideate on how to reduce the cognitive load on a team. I have used a template I created for this example, but you can just as easily do it with a whiteboard.

How can I take this further?

A great place to start is the work of J. Sweller.

How to run a Cognitive Load Mapping session was originally published in Cloudnative.ly on Medium, where people are continuing the conversation by highlighting and responding to this story.

The language inside the technology industry has a habit of suffering from semantic drift. Words lose their meanings over time; DevOps stops being about bringing together Dev and Ops and instead becomes what we previously called Ops, TDD starts meaning there are (probably) tests, and what we call Agile begins to mean Waterfall.

Even seemingly ubiquitous language drifts over time, even words so familiar that they almost become wallpaper, such as “Team.”

Try it out, and ask someone nearby for their definition of a Team. Was it the same as yours?

One of the most common stumbling blocks within large organisations is the need to understand the purpose and meaning of this most foundational concept.

If you, dear reader, aspire to lead a high-performing organisation, misunderstanding these words is one of the most common problems and has disastrous consequences.

One of the most well-known effects is Melvin Conway’s law: “organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.”. For those unfamiliar with this law, Eric Raymond brilliantly rephrased it: “If you have four groups working on a compiler, you’ll get a four-pass compiler.”

If you get this wrong, not only will your delivery be chaotic, mirroring the communication in your organisation, but its implementation will be chaotic, leading to bugs and poor user experience.

This is mirrored in my own experiences. I have seen “teams” ranging from individuals to hundreds of people, working on common goals or not, representative of the work flows in the organisation or not, grouped by product or technology or seemingly randomly. Often, the root cause of many organisations' problems comes down to a poor understanding of what a team is and how to make it effective.

So, what is a team? If everyone has a slightly different definition, can we define it more clearly to maximise its usefulness?

The most basic definition of a team is simply an abstract grouping of people. This definition is easy to understand, but why do we form these groupings? They are so universal that there must be a reason behind it.

Let’s think about what these groupings are doing in the software industry; it might be some design activities, coding, or ensuring a product complies with some law. Work. This definition holds even if we move away from the software industry: Imagine a team of farmers, a team of people in a doctor’s surgery, or even a team of track and field athletes competing in a relay.

This is mirrored in the dictionary definitions. This is from the Cambridge Dictionary

A number of people or animals who do something together as a group

“Teams exist to do work” seems obvious, but it tells us something important: Teams form to maximise the work a group can do, at least in a business setting.

Let’s rephrase our definition: A team is an abstract group of people who combine to maximise the work done.

A 2019 study of two data sources proved this by looking at two “planetary-scale collaborative systems,” GitHub and Wikipedia, titled “Collaboration Drives Individual Productivity“. They found that team “productivity of smaller groups scales super-linearly with group size,” but you stop gaining performance gains after a certain point when these performance gains are “saturated.” This result mirrors a study (the link is to the paper, but you might be better off with the Wikipedia page) by Maximilien Ringelmann (an agricultural engineer) in 1913.

Thanks to “Collaboration Drives Individual Productivity”, we know that this benefit of teams is that performance gains from collaboration stop once the team size is between 10 and 15 people, and the optimum size is around six people for maximum gain by adding someone new to the team.

Let’s rephrase our definition. A team is an abstract group of people who come together to maximise the work done with a maximum of 15 people, but optimally around 6.

So why does this effect happen, why does performance drop off, and how can we get the most out of the people on our team?

Plants have a natural height limit. If they grew any taller, their own weight would become too much for their supporting structures to handle, causing them to collapse.

You have seen this effect in action. Within organisations, it looks like a mysterious slowdown in delivery as the company grows its hierarchy like a plant reaching for sunlight. The more complicated the organisation’s communication, the more roles you need to include to handle that until delivery grinds to a near halt.

John Forsyth, a social psychologist, found that the factors that affected this in teams were “identifiability” — the ability for work to be linked back to an individual — common “goals” to reduce coordination needs, and increasing involvement by identifying the overall reason behind the local goals or a grouping to a broader meaning.

Daniel Pink restated this in his hit book “Drive: The Surprising Truth About What Motivates Us”. Finding that essentially motivation, after money reaches a level to cover basic needs, is primarily driven by

• Purpose — The desire to do something that has meaning and is important, being the most critical of the 3.
• Autonomy — A desire to be self-directed; it increases engagement over compliance.
• Mastery — The urge to get better skilled

Let’s rephrase our definition again.

“A team is an abstract group of people who come together to maximise the work done with a maximum of 15 people, but optimally around 6, where team members can maximise mastery, purpose and autonomy.”

It’s clunky but more helpful. However, it needs something added. We have a clear direction for the team size, but how can we help people achieve the latter part?

Well, the purpose of Daniel Pink’s book is a practical constraint. A team only has a purpose if it can produce something meaningful. A team of developers that only ever writes fragments of a system, for example, a web designer without an HTTP server, can never have a purpose because the work has no purpose.

To achieve something with a purpose, we need a team with enough functions baked into it and enough different capabilities to create something functional and meaningful. A “cross-functional” team

John Sweller is, perhaps, the most famous educational psychologist working in the field of Cognitive Load Theory. Recently, my colleague, Andrew, asked him about the effect of cross-functional teams on cognitive load:

“Engineers do have a problem with economics and vice-versa which is why putting them together can work. The engineer does not have to learn economics and vice versa. Learning economics or engineering puts more of a strain on working memory than using someone else’s cognitive system!”

Of course, this effect isn’t possible if the person you want to use the brain of is unavailable at the moment because they are on an entirely different team.

Cross-functional teams are doubly effective when you bring in Eliyahu Goldratt’s work on the theory of constraints. His work shows that a system is constrained to move at the pace of its slowest component (the bottleneck). Suppose we have a cross-functional team that can deliver something by itself; you have simplified the number of elements within the system and reduced the complexity of identifying and optimising the bottleneck.

In addition, it also minimises the amount of work in progress. If a designer designs something, that design is unfinished until the design has been coded up by a developer and tested by a tester. If somebody stops this imaginary project tomorrow, a cross-functional team limits the amount of in-progress work to what is local to that team rather than everything into a broader system, enabling you to be nimble, or rather “agile”, in the face of a changing business environment because the costs of being so are low.

Let’s take one last look at that definition.

“A team is an abstract group of people who come together to maximise the work done with a maximum of 15 people, but optimally around 6, where team members can maximise mastery, purpose and autonomy through cross-functional teams with a common goal.”

If you want a high-performing organisation, you need to cultivate teams in cross-functional groupings of between 6 and 15 people who share a common goal and can achieve that goal.

Everyone is missing the point of teams was originally published in Cloudnative.ly on Medium, where people are continuing the conversation by highlighting and responding to this story.

In August this year, McKinsey released an article called “Yes, you can measure software developer productivity”. This created a lot of reactions from people saying that McKinsey had completely missed the point of recording metrics, why we record some metrics, and why we don’t record others.

And I broadly agree with those commentators critical of these metrics (Dave Farley’s analysis is particularly good, and there’s one from our very own Andrew Gibson finding the good in the metrics). However, what has happened here is not limited to McKinsey, or even to metrics.

I have not met a developer without a story where they have joined a team that claimed to be doing agile but instead were doing something else, usually waterfall. This is another example of the same problem, an organisation missing the deeper reasoning.

So how does this happen?

In 1985, Edgar Schein published a book called “Organisational Culture and Leadership: A dynamic view”. In it, he hoped to explain how organisations decide what is and what isn’t a priority issue for them to fix. It provides a great model for understanding why organisations misunderstand.

He proposed a model of three layers from most visible to least. On the outside, we have Artefacts; below this, we have Values, and below that, we have Assumptions.

Artefacts are the things you see in your organisation day to day. This might be tickets in Jira, or your daily standup, or even the tests in your codebase. These are the easiest things to see around your office and are often tangible or visible to the casual observer.

Below this we have Values. These are harder to experience, they are the things that the creators of the artefacts value. A great example of when people have considered this and written it down is the Agile Manifesto.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Manifesto for Agile Software Development

By the way: think back to your experience of that organisation that missed the point of agile. Did they hold these values?

Under all of these are the fundamental assumptions needed to make these values work. These are even less visible than the values. In the case of the Agile Manifesto, the assumption is that developing software is as much about discovering the requirements as implementing them and that working in small iterative chunks will produce better results than other methods.

When McKinsey wrote this article, they fell into the trap that Schein’s model exposes. They have looked at the fantastic work of Amy C. Edmondson and Nicole Forsgren in researching how organisations create effectively and seen the Artefacts: metric frameworks and not the Values or even the Assumptions below them.

It isn’t that McKinsey stupid, or malicious, it’s that they only saw the most visible part of the work. So when they came to build on those metrics, adding their own, they were unable to iterate on that work. I think that’s a very natural misstep to make.

My reading of the values underlying these metrics is that while metrics are important, they are merely the outward manifestation of the underlying value of using scientific research to identify, on aggregate, what the best indicators of organisational success are.

However, even Amy Edmonson and Nicole Forsgren are making assumptions. One of those is that organisations, when exposed to metrics, will react to them in a logical way and that we can perform scientific research to discover what these metrics should be.

I suspect that both of these are true, but they are very much assumptions.

So, next time you are learning something new, try and dig a little deeper and see if you can discover the values and assumptions of the thing you are trying to learn, and if someone is struggling to pick up what you are trying to teach them, make sure you have signposted your assumptions and values as best you can — it’ll help.

I will end this on a tip: Think of an artefact that you use. If you were to ban yourself from using it, what could you do to give yourself the same effect? Now ban that too, and come up with another. Do this enough times and the common thread between them is what you value.

You can likewise use this approach for assumptions too. List all the situations you don’t think the value applies, the common thread is what your assumptions are.

I’d love to hear about your experiences of discovering things you valued that you didn’t expect.

Why organisations misunderstand things was originally published in Cloudnative.ly on Medium, where people are continuing the conversation by highlighting and responding to this story.

Team Topologies is an increasingly popular topic in organisations looking to improve delivery speed. It is fascinating; It has that perfect combination of ideas to hook me, both practically in my daily life and well backed up by scientific research I can dive into.

When I find something interesting, I write. I love to get more people excited about things I am excited about. However, when writing this article, I struggled to articulate the experiences of those who are coming to these ideas for the first time.

So I did what any AK-er would do in this situation: I reached out to someone with a different perspective. Victoria has been helping a bunch of organisations get their first taste of Team Topologies, she bridges that gap between being an expert and knowing what her attendees experience, so can replay their experiences of coming to Team Topologies for the first time.

In this article, I want to report her experiences and what attendees of her workshops are telling her. I want to use them to tackle those first problems you experience as you dip your toes into the Team Topologies world.

So why are people turning to Team Topologies?

According to Victoria, what she hears most often from people attending her workshops is that people turn to Team Topologies because organisations are struggling to get teams to deliver.

“Organisations are created for a reason,” Victoria says “they have a mission, and they bring in the best people they possibly can to help them to deliver on that mission”. However, as time passes, something is lost, and people, the team, “the powerhouse of delivering on that mission”, become hampered by layers of bureaucracy that made sense in previous iterations of the organisation but are just causing teams to split their focus now.

This problem has many names: the frozen middle, the build trap, a lack of agility, a lack of DevOps or a lack of Domain Driven Design (DDD) practices. What can be frustrating with this is that we have been finding solutions to these problems for years, and we have a lot of tools to help, but very few that work beyond just one team (without excessive bullshit, I am looking at you SAFe and Scrum).

Organisations need the help of Team Topologies to help them solve this problem, as Victoria puts it, “the key thing about Team Topologies for me is unravelling that knot and refocusing organisations on the importance of setting up the teams for success”.

What are the core components?

Team Topologies brings together a lot of thinking from the Agile and DDD Communities. In particular, it combines the ideas of a Team Topology (or type), Cognitive Load Theory as applied to teams, and Conway’s Law into one usable and, perhaps more importantly, explainable package.

If you are familiar with these communities, much of it will already be familiar. However, for those who are not, I’ll quickly introduce them.

Conway’s law is probably the easiest of these to grasp. In 1967 Conway said, “Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure.” My favourite rephrasing of this is by Eric S Raymonds, who wrote The Cathedral and the Bazaar. Eric said, “If you have four groups working on a compiler, you’ll get a 4-pass compiler.”.

Conway’s law is a foundation of Team Topologies and is useful to remind us that how organisations design their teams impacts their output, so let’s use that to our advantage.

But I thought this was called Team Topologies, so what are these topologies? There are 5 (or 3, depending on how you look at it). Let’s go over the primary 3:

• Stream Aligned Teams -These teams align themselves with the flow of work or their value stream. They take ownership of the process from conception to delivery to their users.
• Enabling Teams — These are teams that work with other teams, with one important feature: they facilitate capability uplift rather than doing the work for them, and their engagement with the other team has an end date that is soon.
• Complicated Subsystem Teams — These teams work with another team but are a specialised group of experts to simplify a complicated problem, reducing the cognitive load of a Stream Aligned Team. Usually chock full of brilliant domain experts.

And the two that are not quite direct team structures

• Undefined topology — An absence of any defined topology, not a desirable state in Team Topologies, but most people’s starting point.
• Platform Group — This grouping of other team types allows the topologies to be fractal, something we commonly see in resilient structures in nature. This topology is a grouping of teams that delivers a service accessed in a non-blocking way to accelerate the flow of other teams. For example, a database provisioning team. The critical thing to know is that these teams should be able to be competitive with what public services can offer — that means being customer centric, and understanding the users needs. Think of it as a box that a group of other teams fit in.

These come with some defined effective communication styles.

• Facilitation: almost exclusively provided by Enabling Teams — a time delimited interaction that uplifts the capability of another team.
• X-as-a-Service: most frequently provided by Platform Groups or Complicated Subsystem Teams and consumed by Stream Aligned Teams — the provision of a service in a non-blocking way.
• Collaboration: most frequently between two Stream Aligned Teams, or between a Complicated Subsystem Team/Platform Group and a Stream Aligned team at the inception of an X-as-a-Service — collaboration is costly, so it should be time delimited with defined outcomes.

These patterns allow the limiting of team cognitive load by limiting handoffs, but also to let teams say, “Talk to us like this, so you don’t disrupt us”.

Team Cognitive Load is also a fascinating idea; it builds on the work by Australian Psychologist John Sweller, but instead of applying it to the individual, we use it for the team.

Cognitive load theory as applied to individuals works like this, when a person is solving a problem their brain is under differing sorts of pressures. These types of load are Intrinsic, Germaine, and Extraneous.

Think back to the first time you did algebra. Was it hard? The existence of mental models that let you solve problems fast, and reduces effort needed to solve a problem. This is called the “Intrinsic” cognitive load.

Ever tried to focus while in a noisy office? Pressures from the environment are called “Extraneous” cognitive load.

Finally there is how hard this particular instance of a problem is to solve. This is the “Germane” cognitive load. For example adding 3+3 is easier than 7543565+654334, but it uses the same skills.

So let’s apply that to a team.

• We want to “Simplify the intrinsic”. This isn’t about solving less hard problems, it’s about building those mental models in our team members that make the intrinsic load in individuals lower, so that might be solving a problem more often, adding an expert to the team, or doing some training.
• We want to minimise the extraneous by removing environmental noise for the team (such as bureaucracy),
• Finally we want to maximise the work which is germane to the problem.

Put all these concepts together, and you have Team Topologies, a set of patterns you can apply to your organisation.

But trying this out isn’t all smooth sailing.

When first introduced to these ideas, it’s tempting to take whatever your team currently does and label it with one of these names.

Victoria told me about the confusion from attendees at her workshops, a common question is, “So how do we fit into this model that you’re trying to teach us?”.

An essential thing to say here is that a team won’t just magically fit into these topologies, you need to evolve it intentionally. As Victoria puts it “When we’re asking a team to define themselves as a platform group or a stream aligned team or an enabling team, frequently the answer is, ‘but we do a bit of all of that’…it makes a lot of sense to us, but we can’t put our square peg into this round hole.”

To solve this, Victoria’s advice is, “Take some of those core concepts and make small changes. Proving their value at a small scale is a good place to start, and then start rolling it out.”

Some practical resources

This article aims to answer some of the questions that commonly come up when talking about Team Topologies based on Victoria’s and her attendee’s experiences, making it a bit easier to get started with the topic.

If you (like me) find this fascinating and would like to know more, I recommend the following:

• Read the book!
• Attend one of Victoria’s workshops
• Take a look at Team Topologies Infographics

I would love to hear from you about your experiences, you can get in touch via the Team Topologies page on the Armakuni site, or just drop me a message on LinkedIn. I love feedback, and learning about the perspectives of people with the same passions as me.

Beginning Team Topologies was originally published in Cloudnative.ly on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today I will share the secret sauce of how we deliver and why it works — a blow by blow example of the current thinking we have on agile inside Armakuni.

I am limiting my scope for this article: I will focus on “building the thing right” rather than working out what “the right thing” is.

Before I get into this, though, I want you to know this article isn’t like the SAFe or the Spotify model. I am describing is a snapshot in time, and as a learning organization, we are, well, always learning, so this will change. This article is probably already out of date.

I will try to give you the reasoning behind each of the activities in this process, and if you can find something else that achieves the same ends, or those ends aren’t a concern for you, go for it, chop it, change it, grow it, and tell us about your experience.

Many at Armakuni (we call ourselves AKers) describe our style as “little ‘a’ agile with XP flavour”, we are, and continue to be, influenced a lot by the thinking from the Extreme Programming movement. But what does that mean? One way to look at it is the feedback cycles that help us build the right thing.

Our most extended feedback cycle is the Inception, which happens which every quarter by default, often more frequently than that (more on that later). The Inception, unless it is the first, is followed by a retrospective on how it went.

Within the inception cycle, we have many Iteration Planning Meetings (IPMs). These happen weekly or once every two weeks. A demo and then a retrospective precede the IPM.

Within this, we have the daily standup, which we position as a mini planning session for the day. The standup is an opportunity to find collaborations and use what you learned the day before to plan today. A daily, forward-looking feedback cycle.

Finally, we have pair programming, which gives a second by second feedback cycle. We believe in pair programming not only as a tool to enable quality software development but also as a method of creating shared ownership. I will not be talking about this much here, but we have a more detailed look at pair programming on our blog.

I’ll dig into each of these loops in a moment, but the thing I want you to notice here is that we optimize for feedback loops. This is because we are trying to learn every day, every second, as a team and as a community. We’re doing this by creating frequent opportunities for safe spaces to talk about how well things are going and places where we can raise problems, share what is working, learn what isn’t, and make constant small low risk, low friction changes based on that learning.

The inception loop

People are often wrong about software projects. They have this idea that they will come up with this grand idea, and then in 6 months, they will have precisely that. But, unfortunately, reality gets in the way.

A great model for explaining this is the Cynefin model.

Software development is all about taking and learning from humans and implementing replications of behaviours a human might have taken. To make this more challenging, humans might not know why they are doing specific behaviours, and if they do know why, those reasons might not be valid.

We are tackling problems that often have no good answers and that we need to discover the path with every step. To enable this, you need to create an “experiment, evaluate” loop that will drive you to a place that you can more effectively serve a customer (that will also be learning about themselves and constantly changing, I love the goalposts moving). The Cynefin model calls this the Complex space. There is an excellent summary of Cynefin in this Cognitive Edge video from Dave Snowden.

The Inception is the acceptance of this fact.

Inceptions happen whenever your project no longer has reasonable goals. You run out of goals when you’ve implemented all of the current ones or learn something drastic that invalidates your existing assumptions.

You’re always chasing the current business goals with this model, you are always moving forward, and you have a way to re-evaluate when that isn’t happening.

The inception loop is the hand of direction ©and alignment. So we’re aligning and learning about the direction that we are travelling. We will also agree on how we will work as a team and create the initial Backlog.

The Inception starts with defining goals, non-goals, actors, and risks. Once we have discovered these together, we can take them and pipe them into a story mapping activity to generate our Backlog.

One of these I want to dig into a little more: Non-goals. Non-goals fall into two types; firstly, we want to make explicit what works against what this project is trying to achieve. Not everything clear to you is clear to everyone else. State your mental model. The second category is things that we know we want to do, but just not yet. We might bring these in in another future iteration, but we’re not going to do them this second (Starting work on a non-goal is a way you can tell it’s time to Reincept).

Story mapping allows you to draw a line and try and sketch out rough epics you will be implementing and, significantly, the first two iterations of stories. I will not look too deep into story mapping here; you can read more about it in User Story Mapping by Jeff Patton.

Why two iterations? Defining stories is hard. If those stories sit in the Backlog and ever get developed, you have wasted that effort; what’s more, you’re leaving yourself susceptible to being locked into implementing them (plan-continuation bias is a human default)

On the other hand, you don’t want to be unclear on the future as it motivates, lets us optimize for cost of delay, and critically a lack of stories leads to work disruptions.

The other part of the Inception is agreeing on ways of working. Ways of working are essential because they define the conditions under which transitions in the upcoming project occur and define feedback loops to help software developers meet standards and offer an opportunity for product owners to get feedback on the quality of their stories.

The whole team comes to the Inception, which is everyone working on the project on a day-to-day basis, plus individuals from outside the team who are vital to the team’s success.

This process might seem short term, but it’s what lets a team be agile and responsive. Also, with the engagement of all team members, you think with the entire team, rather than an individual within the group (like the bit from Power Rangers where they combine they become the Megazord — hey, it’s backed up by research!).

An Inception will leave you with:

• Goals, Non-goals
• Actors
• Risks
• Just enough prioritized backlog
• Agreement on a Definition of Ready (DoR) and a Definition of Done (DoD)
• Commitment from the entire team

The next day, you start your first iteration.

How to build an Iteration

Within a team, we have a few key roles. These roles may be rotating, may end up being more like hats you wear, but they are primarily fleshy squishy people. Those two roles are the product owner (PO) and the technical lead (Tech Lead or TL).

Both these roles have different responsibilities and are there to advocate for competing positions. The product owner is responsible for making sure the recipient for the work is well understood, getting what they need, and constantly learning more about them and tailoring our activities to their needs.

On the other side, the Tech Lead is responsible for ensuring what gets out to the customer is of good technical quality, providing sustainable iteration and development into the distant future. As you’ll see later on, we give this role a reasonable amount of power to balance it against the Product Owner, an implicitly powerful position.

To clarify these roles, I want to frame them in terms of the iteration board.

Our default sprint board looks like this Icebox, Backlog, In-progress, Delivered, and Done. The card types we have are Story, Chore, and Bug.

By default, all of these card types go into the Icebox. The Icebox is a free-for-all. Anyone can put stuff in there. It’s called the Icebox because some work needs to be done by the PO and Tech Lead to thaw out the stories that are in there to be ready to use.

The product owner creates stories that represent features (though sometimes tiny ones) and customer-focused work. They have sizes and can come from the Icebox into the Backlog with agreement and design work from the product owner and the tech lead.

A story can only move from Icebox to Backlog with enough design done by the Tech Lead or other technical person, and the product owners, and tech leads agreement. We need agreement between these two roles because we ensure we have representation of technical quality and product direction. In addition, the story must match the requirements of the “definition of ready”. If a story isn’t ready, the team can say no. It’s a feedback loop that transfers the mental model from the PO to the developer.

Chores are a technical task that needs to get done but has no visible impact on the customer — for example, creating a database or reformatting the codebase with a code quality tool. They have no estimates and don’t need the Product Owner to review them before or after. They do, however, need to be visible and present on the board.

Chores made by the Tech Lead may skip the Icebox, inserting them into the Backlog without input from the Product Owner and positioning them as the Tech Lead sees fit (so the product owner can’t constantly put them last). Product Owners almost always have a lot more power than technical people; chores let us go some way to rebalance the deck to ensure that technical quality is built-in. The more mature a team, the fewer chores needed. Early on, these are vital to exposing the hidden work that many technical people do that the product owner may not have considered.

Chores let us bake in quality. However, they also teach the technical people not to assume that everyone knows everything about what needs to be done and give just enough technical detail to the product owner to appreciate the hidden effort involved.

Bugs are flaws that simply aren’t working right that need fixing. They need to go to the top of the Backlog and give us a way to track metrics around change failure rate. Like chores as we learn as a team, these start frequently and reduce to nearly nothing over time.

Rejecting a story is preferable over creating a bug, but a story is done, create a bug.

The start of an Iteration

At the start of the iteration, the team sizes and commits to the stories in a SHORT Iteration Planning Meeting (IPM). Going into this session, the product owner and tech lead should have made all of the stories ready, leaving only the breakdown of the stories into tasks (a simple todo list inside the story) outstanding. This will keep the session short and make sure that the research has been done in advance.

The session needs this preparation beforehand, and it does not work well without it. Therefore, I recommend the product owner or tech lead spends 15 min every day refining the Backlog.

Once a story is in the Backlog, when a pair picks it up, it moves into in-progress. Developers pull work into the column at a limit of 1 ticket per pair. Developers are almost always the constraint in this system. They get to decide the rate work is delivered, not the product owner. If they stop working on something, it goes back to the top of the Backlog.

If your developers are not the bottleneck, move this pulling behaviour to the step that is.

Once the developers make the appropriate blood sacrifices (vegetarians can substitute beetroot juice) to implement the feature, the feature moves into the Delivered column for the Product Owner to review.

The Developers add to the story how the product owner should see the story working. The delivered column serves multiple purposes; firstly, it serves as a prompt for the pair to check that they have implemented the acceptance criteria through writing a “How to accept” guide.

Secondly, we make it easy for the product owner to try the feature out and create a prompt for the product owner to call over the person who this feature impacts and show them the cool stuff that the developers have delivered. Instant feedback!

If it isn’t working as expected, the Product Owner sticks it back at the top of the Backlog with a note where the POs and the developer’s mental models are misaligned

Once done, stick the ticket in the done column and party.

It’s a great fast feedback loop, but it’s a super dopamine hit showing people the cool new stuff you and your team made.

This transition is also the opportunity for the product owner to push back and make sure that the developers do the work as agreed in the definition of done. Here we are, making an often implicit relationship explicit and changing an implied to a negotiable relationship.

I want to mention now that team-wide demos are still a vital part of the development process. A demo is an alignment tool, the first opportunity for sponsors and those delivering on the same mental model. Letting interested parties call out when things aren’t helping them solve their problems, or maybe missed the point.

So a week looks like this: an IPM consisting of the team quickly agreeing and sizing the next iteration’s work (less than an hour, your Backlog should be ready from the constant small planning preparation done by PO and Tech Lead throughout the week), a week of daily standups between pair programming, a demo and then retro (These together usually take 1:30min) at the end of the week, followed by the IPM again.

Feedback loops

The cornerstone of any learning organization is training yourself and everyone else to learn and not base your actions on assumptions that you have consciously or unconsciously left unchallenged. We try to solve this hard problem using the same technique as Continuous Deployment. Continuous deployment tackles the hard problem of deployment by doing it a lot, so we get good at it. We break the cycle of making assumptions by giving ourselves feedback loops that can break them a lot.

Generally, those loops are:

Daily loops

• Standups
• Pairing
• Backlog grooming
• Product Owner accepting stories

Weekly Loops

• Retrospectives
• Planning
• Demos

Quarterly (Ish) Loops

• Inception Planning

At the start, I said I would give you the secret sauce to how this works. The only secret sauce is to learn and create as many opportunities as possible to learn and challenge your assumptions. So now you know our current model if you like, copy it and change it, but whatever you do, don’t stay with it. We won’t have.

How to agile dead good was originally published in Cloudnative.ly on Medium, where people are continuing the conversation by highlighting and responding to this story.

Armakuni has always been a Cloud Native company. We rode that first wave of being able to take advantage of easy to use self-service PaaS systems, and turned them into commercial benefits, for our customers, and their customers as far back as 2012.

But 2012 was nearly a decade ago now, so what does it mean to be Cloud Native in 2020. To understand how Cloud Native applies now, we need to go back and look at what makes something Cloud Native.

There’s no official definition of Cloud Native, so let’s lean on this one from the Cloud Native Computing Foundation, vendor agnostic shepherd of the Kubernetes project.

“Cloud native computing uses an open source software stack to deploy applications as microservices, packaging each part into its own container, and dynamically orchestrating those containers to optimise resource utilisation.” — Cloud Native Computing Foundation

Let’s pull this apart a little bit.

“Deploy applications as microservices” is the first part. Microservices are the breaking down of applications into small independent chunks which communicate via the network. Microservices are possible on any networked machine though, so what it’s saying is more than that, it’s that this behaviour must be natural and encouraged.

“Packaging each part into its own container” which means using container-based isolation. Isolation gives us the confidence to cram more onto each machine and reduce the number of wasted CPU cycles without worrying about leaking information between processes.

Once we have the confidence that we can utilise more of each machine’s resource, we don’t want to manage that manually. Once we have that it follows we want to reduce the amount of work that takes by automating, or as CNCF puts it: “dynamically orchestrating those containers to optimise resource utilisation”.

However, this definition doesn’t go far enough. We’ve fallen into the Engineer’s trap of thinking of the technology and not the people. So what are the principles that CNCF implies in this definition?

When we are using these tools, we’re able to move a lot faster. I can’t stress this enough: the human is now the bottleneck. To take full advantage of these tools, we can look to another fast-moving environment.

The year is 1806 and Nepolean is marching on Jena and Auerstedt. Napoleon’s army is massively outmatched in soldiers, 110,000 Prussian troops to his 50,000.

Prussia has a problem though, their command structure is a mess. Multiple senior staff hold the same position in the army, leading to uncertainty as to who orders to follow, and making it slow to react.

The battle came to a head when Prussia ordered their main force to hold the Kösen Pass, Louis Davout, one of Nepolean lieutenant colonel’s leading a single Corps of 27,000 men defeated the main Prussian army of 60,500 troops.

What made the difference here, wasn’t a difference in technology, but rather strategy. It doesn’t matter if you have the latest, shiniest new technology, if you’re still using the same training drills from Frederick the Great.

Prussia had to go back to the drawing board with their army’s organisation. Over the next years, they formed a new doctrine, lead by Moltke the Elder: Auftragstaktik, or “Mission-type tactics”.

Auftragstaktiks most crucial aspect is Forward Control, the idea that the “man on the ground” can make better judgements on the situation than someone removed my multiple levels of rank. Commanders were given goals to achieve but left to decide the method on their own.

“Diverse are the situations under which an officer has to act on the basis of his own view of the situation. It would be wrong if he had to wait for orders at times when no orders can be given. But most productive are his actions when he acts within the framework of his senior commander’s intent” - Helmuth von Moltke

This sort of “Forward Control” is implicit in being able to take advantage of this increased speed of delivery.

To give people that control, we need to first delegate the responsibility to how to develop software systems in the most effective way. Meaning we need to teach people how to do it safely, and make it easy to perform actions safely through training and automation.

The next part of this is if we’re able to do all these things faster, we need our organisation to be able to learn from them, rather than making the same missteps over and other again.

An organisation that can’t retain institutional knowledge as fast as they can experiment will only evolve at that same speed that they can learn.

When we first came into the industry, we were massive advocates of Cloud Foundry, and we still see it as a very influential tool. It wasn’t the first PaaS platform, but it was the first large one that took advantage of containers, meaning to achieve isolation you no longer needed to have a VM per process, massively reducing the total cost of ownership.

It automatically orchestrated running and scheduling the containers and took advantage of building and maintaining the environment they lived within. Utilising Bosh, a tool for deploying software onto Virtual Machines, it was possible to automate nearly all aspects of platform ownership.

It was a game-changer. Using Cloud Foundry helped us develop microservice platforms; the isolation and utilisation making is cost-effective and fast. Most memorably for Red Nose Day where we took payment platform that was massive for a single night of the year, to a group of easily understandable Microservices, that could handle anything the public could throw at it.

But the tech industry does not stand still; it can’t. As Lehman put it “an E-type system must be continually adapted or it becomes progressively less satisfactory”. Change is necessary to survive in the tech world.

Cloud Foundry has a high total cost of ownership. We’re looking at at least 20 Virtual Machines. Meaning the amount of productivity you need to get out of it needs to be notable before it starts to break even, making it unsuitable for most smaller companies.

Into this space walked Kubernetes. Now Kubernetes has container-based isolation with Docker and easy automation points, but it only has four components: kube-apiserver, kube-scheduler, kube-controller-manager, and etcd. This simplicity makes it cheap enough to be financially attractive to organisations that operate with small IT budgets.

The compute overhead is low enough so that developers could play with it on their machines, and mirrored how Virtual Machines worked so closely it was an easy transition. This simplicity made it the smash hit it is today.

Unfortunately, it was too easy; like with the initial creation of Virtual Machines, people applied their existing processes from physical machines to the utility-based world of clouds computing.

When you have weeks to have a physical server delivered, you have plenty of time thumb-twiddling and rarely scheduled meetings, with drawn-out processes. In the Cloud Native world with no delivery times, these still live on as echoes of when hardware was physical.

There are two sorts of change. One is easy and essentially involves taking a new tool for an old way of working; this is often how most people initially try to apply new technology. They shoe-horn it into their current mental models. The second requires us to unlearn previous habits, practices, and ways of doing things. It takes significantly more effort — and can be challenging in environments where we don’t feel psychologically safe.

This cloning of practices from physical hardware does nothing to encourage Auftragstaktik. The organisation does not need to learn to experiment faster, because it can’t move any quicker.

Step in Serverless.

Serverless is Utility-based computing provided at a FaaS (Function as a Service) level; this means thinking in small chunks of code. Under the hood, we’ve seen before, but they’re abstracted away from us. Containers, automation, now entirely supplied by the hosting provider, significantly reducing the amount of time needed to be spent by developers on non-value producing activities.

The technology isn’t what makes serverless unique, though: Serverless force you to use Auftragstaktik’s Forward Control. To use these services, you need to be able to have direct access to the platform. This direct access causes a shift in thinking away from Physical Machines.

This transition isn’t always easy. Remember the Prussians? Well, I left out a part of the aftermath of the victory at Königgrätz, the commanders pursued their troops for insubordination, describing their actions as “barely concealed contempt”. What’s more, during the battle some commanders had no knowledge of Moltke the Elder’s strategy, and some treated it with open contempt. The road to high performance is often bumpy.

Many organisations will face the same internal struggles. What we have in Serverless is something that makes making the changes less painful than not. That is a mighty wedge.

You don’t get the benefits of Cloud Native without bringing these cultural changes. You don’t win a war of movement using tactics from a more static era. You can use the wedge of Serverless to make those changes easier.

Is Serverless the end of the Cloud Native story? No. “an E-type system must be continually adapted or it becomes progressively less satisfactory”. But is it the closest we’ve ever been to the dream? I think so.

Cloud Native means serverless was originally published in Cloudnative.ly on Medium, where people are continuing the conversation by highlighting and responding to this story.

As we started expanding, we found we had a problem; we were hiring and struggling to give new people joining our team a clear picture of how we operate. Particularly more junior members of staff (who are critical to any growing organisation), and they were struggling to articulate what “good” is in how to work.

We’re a consultancy. Which means to a great extent what we sell is how we work, so if we’re not consistently doing that, we are devaluing our product.

To solve this, we created the Ak Way Defaults Cheat Sheet.

We don’t want to be prescriptive. We know command and control is always going to hold your organisation back when compared to intent led organisations. While we needed to create alignment, we also wanted to make sure that we were talking in terms of purpose, but also give examples to ensure people who were experts in another area could still get on board.

Over time we have realised that it’s not the exact copy and paste practices that apply to each environment, but rather the principles behind them. So we needed to make sure we were talking.

To this end, we made a suite of safe defaults for teams to use in most situations. The purpose of the list is to act as guard rails, and provide defaults if none exist already. We believe that nobody knows the problem better than the people dealing with it — so if aspects of the list aren’t applicable then that’s okay. We are not creating a stick to punish.

It contains examples of practices because we want new team members to understand what we mean by each of these, especially if they’re coming from an environment that might not have used these practices.

It’s not enough just to create some dead wood though, we need to put this into action. We do this through the format of a retrospective.

How to use this as a retrospective

One way we find this cheatsheet helpful is when we want to run a more structured form of retrospective. It allow us to take a step back and think about our holistic approach to work.

When we’re running retrospectives in this format we ask everyone in the team to put a dot next to each of the principles — dots are coloured red, amber, green. They represent an individuals perspective on each point with regards to the current engagement. Red meaning we’re not doing this or its needs A LOT of improvement, amber meaning we could do better, and green meaning that we’re okay in this area.

Once everyone has voted we then go through each area where there isn’t consensus and discuss what could be done to increase alignment. We then focus on the areas that are mostly red and create specific, measurable, achievable, realistic, and time-boxed actions to improve them.

Find the full sheet at our GitHub

Aligning through Retrospectives was originally published in Cloudnative.ly on Medium, where people are continuing the conversation by highlighting and responding to this story.

Software Engineering Topic of the Day #27

Note: This was originally written and published on the internal Armakuni Slack, by me

This is another Video one. Today we’re going to see how to use TCR and what it’s benefits are

Q1: What changes in how you work has this exercise taught you?

Q2: How did it feel losing your code?

Q3: Are there other interesting ways to learn good development practices?

How do TCR was originally published in Cloudnative.ly on Medium, where people are continuing the conversation by highlighting and responding to this story.

Note: This was originally written and published on the internal Armakuni Slack, by Tom Oram

Connascence is a software quality metric and a taxonomy for different types of coupling. We can use it to inform our decisions about how and where to reduce coupling in our systems.

Connascence has three properties:

• Strength
• Locality
• Degree

Each type of connascence has a different strength, lower strength ones cause less problems. Locality is whether the coupled entities are near each other (e.g. in the same class or module) or far apart (e.g. different modules, libraries or services). Degree is how many things are coupled together. These metrics should be considered together; that is, something with high strength coupling might not be bad if it is very local and has a low degree.

There are two categories of connescene types, dynamic and static. Static types can be discovered by inspecting the code, dynamic ones require knowledge of runtime. The types, in order of strength from low to high, are:

Static

1. Name — things are coupled if you have to refer to the same name (e.g. function name)
2. Type — things are coupled when then have to agree on the type
3. Meaning — things are coupled when specific values have a special meaning (e.g. null means not found)
4. Position — things are coupled when the position (in a list or set of parameters) have special meanings
5. Algorithm — things are coupled when they must both understand the same algorithm (e.g. encrypt and decrypt functions)

Dynamic

1. Execution Order — things are coupled when a number of actions have to called in a specific order
2. Timing — things are coupled when order matter in accordance to time (think race conditions)
3. Value — things are coupled when two or more values are dependent on each other
4. Identity — things are coupled when a specific instance of something must be used
5. Manual Task — things are coupled when manual manual coupling occurs

Connascence gives us a concrete metric to reduce the coupling in our code. When you identify the type of coupling, you can then think about how to reduce it (this is especially useful when you identify dynamic types of coupling).

For more examples, see https://connascence.io/

Q1. Which types of connascence can be caught by the compiler with statically typed languages?

Q2. Can you give an example of how to reduce from one type of connascence to another?

Connascense was originally published in Cloudnative.ly on Medium, where people are continuing the conversation by highlighting and responding to this story.

Note: This was originally written and published on the internal Armakuni Slack, by Tom Oram

This Law of Demeter is a design guideline for developing object-oriented software. It’s goal is to reduce coupling in your code.

The law is formulated like so:

Each unit should have only limited knowledge about other units; only units “closely” related to the current unit.

Or:

Each unit should only talk to its friends; Don’t talk to strangers.

What this means is that an object should be able to call the methods/access the properties of it’s direct collaborators, but not it’s collaborators collaborators.

// Good
order.notifyCustomer();

// Bad
order.customer.notify();

// Cheating (also bad)
var customer = order.customer;
customer.notify();

This law is also referred to as “the principle of least knowledge” or “one dot per line”.

Q1. How is the Law of Demeter related to Tell, Don’t Ask and is there a difference?

Q2. Is it good to avoid this by having methods which just delegate down to the next object and are there ways to avoid this?

The Law of Demeter was originally published in Cloudnative.ly on Medium, where people are continuing the conversation by highlighting and responding to this story.