Consider this; somewhere, right now, someone is filling in a form. It might be a nurse updating a patient record, a support worker logging a home visit, a technician reporting a repair.

They’re not thinking about it as a practice, but it is one. A practice is more than a task, it’s a pattern of doing. It is shaped by habits, tools, expectations, and social norms. We don’t just do a practice, we inhabit it. We pick it up from others, carry it forward, and rarely notice when it starts to shift.

Social Practice Theory helps us notice, it gives us a central unit of analysis. It tells us that every practice is held together by three things:

• Meaning: the shared purpose, value or belief that makes the practice feel worthwhile or necessary
• Materials: the tools, technologies, infrastructures and spaces involved
• Competence: the embodied know-how. The skills, timing, and judgement needed to carry it out

Practices change when these elements change, and increasingly, the competence we once had to learn ourselves becomes embedded in the tools we use. This is the materialisation of competence. Technologies begin to carry part of the knowledge for us.

Let’s look at how this plays out in a simple but familiar piece of work. A field technician visits a home and updates a job record after the visit.

Pen and Paper

From the 1980s to early 2000s, this meant paperwork in the van.

The technician would finish the job, sit in the driver’s seat, and write down the job number, the issue, what they did, and anything that needed follow-up.

• Meaning: The form was a record of work completed, it was proof. A signal of professionalism. It showed the job had been done and could be referred to if needed.
• Materials: Pen, paper, clipboard, often a duplicate pad, sometimes with carbon copy underneath. A folder or storage box in the boot.
• Competence: Knowing what to include, what to leave out. Legible handwriting. Writing concisely, but with clarity. Often in capital letters, in the little boxes. Technicians knew how to summarise events in a way that made sense to whoever read it next.

Here, all the competence sat with the worker. If you couldn’t write clearly, or frame the story well, the record wasn’t much use.

Digital Forms

Then starting in the mid 2000s to the present day came the mobile device.

Now the technician taps through a series of fields. Job ID, customer info, checklist items, text boxes. There might be dropdowns, date pickers, photo uploads, GPS stamps.

• Meaning: Still a record, but more than that now. It’s data. It feeds performance reports, dashboards, and KPIs. It is evidence not just of completion, but of timing, accuracy, and compliance. The form is no longer just for the next person. It is for the system.
• Materials: Tablet or smartphone, the app, signal, logins, chargers, the admin portal back at HQ. Often, a growing set of rules behind the UI that enforce how the form is used.
• Competence: Less about writing, more about knowing the system, where to tap. How to describe something in a text box with limited characters. How to recover the form if the signal drops. How to avoid the app freezing. Or knowing that if it does freeze, you need to restart before submitting or you’ll lose the entry.

This is where materialisation of competence begins to show. The app helps you get it right: mandatory fields; date auto-fill; spell check; pre-populated picklists etc. You don’t need to remember how to spell “corrosion”, you just select it from a dropdown, the knowledge is built in.

The tool starts to carry some of the skill.

Voice AI

Now imagine a future where there’s no form at all.

The technician finishes the job and calls a voice assistant, it asks a few questions, the technician responds. The job is logged, time-stamped, tagged, and routed, all without touching a screen.

• Meaning: Still a record and still data. But the tone of the interaction may shift. Talking doesn’t feel like form-filling, it feels lighter and less formal. But the system still captures, stores, and uses everything.
• Materials: A phone. No need for a screen, tapping or even Wi-Fi.
• Competence: Saying what happened, in your own words, listening to the questions, answering naturally. It’s a bit like speaking to someone who already knows the job and just needs the details to fill in the blanks. You don’t have to structure it perfectly, if you miss something, you can go back and add it, the system helps you along. You speak, it understands. It’s more like a conversation than a form.

At this point, competence is deeply materialised. You don’t need to write. You don’t need to spell. You don’t even need to structure your answer.

The practice still exists, but (if you pardon the pun) in a new form!

This is what happens to practices, they are less likely to disappear, they are more likely to evolve and change.

So, if something as ordinary as filling out a form can shift this much, what else in the workplace is ready to change? What other practices might Voice AI begin to reshape?

The Mapping Part

So hopefully the mapping part is obvious. Maturity Mapping uses Wardley Maps. As Simon describes maps have 5 key properties:

• They are, obviously, visual.
• They present to the reader of the map the position of components. In the case of maturity mapping these components are social practices.
• They are anchored by a recognisable need.
• They present options for movement
• They represent a specific context. In the case of Maturity Mapping this could be the practices used by a team to develop a software product for a customer, eg server side build, testing, user research etc

Where we think Maturity Mapping and Wardley Mapping (currently) differ, when considering them both as social practices, is in their meaning. Wardley Mapping is used to develop strategy and has, as Marc wrote a bias toward material things. Maturity Mapping on the other hand has a bias towards competence and (among other things) helps you develop an awareness of how deliverable your strategy is. So hopefully that helps with the Mapping part.

The Maturity Part

We chose to use Maturity in the name after much discussion. We considered ideas like Fluency Mapping, Improvement Mapping and others. Practice Mapping, which has also been considered (and not yet fully discounted), is the one we feel most closely aligned to. However it doesn’t reflect one important purpose we are hoping to achieve. This exploration reflects our initial discomfort with using the word maturity. We feel this discomfort is reflected in our community, as some folks seem dissatisfied with the term and are searching for alternatives. John Cutler recently asked:

“Looking for alternatives to the words “mature” and “maturity” for teams/orgs, as it seems that better ones are out there:

fitness

suitability

readiness

ability

?

https://twitter.com/johncutlefish/status/1220841078296731648?s=20

Steve Smith has also shared his thoughts on the term as well:

One of the reasons I dislike maturity models is the word “maturity” carries so many connotations about an individuals personal growth

Talk about team effectiveness, proficiency, etc. Don’t talk about maturity. And don’t use maturity models, they suck.”

https://twitter.com/stevesmithcd/status/1214857435472633856?s=21

And when Chris tweeted about his intention to write this post Michael Bolton replied

“I wince when I hear references to ‘maturity’ in this context.”

https://twitter.com/michaelbolton/status/1228448173091368960?s=21

So what is it about this word that folks find dissatisfying or inappropriate for this context? Well we think the fact that maturity is often associated with a stage in development, and that when something or someone is considered mature they have reached the end, pinnacle or final stage of the development. When I think about it, I’m reminded of being a teenager, thinking I’m mature and capable but being told I’m not, or not quite yet. That’s not a pleasant feeling.

If we look for definitions and examples we find things like (many thanks Wikipedia)

Adjective:

• Brought to a state of complete readiness (a mature plan)
• Fully developed; grown up in terms of physical appearance, behaviour or thinking; ripe. (They. is quite mature for there age)
• In the context of film and television, Suitable for adults only, due to sexual themes, violence, etc. (mature content)

Verb:

• To become mature or full-grown; to gain experience or wisdom with age.

In Biology, maturity means also that the organism has reached the developmental stage in which it can replicate. We think that is an interesting notion in regard to the maturity of practices.

What, in essence, we believe this is, is a judgement and most often this isn’t a judgement you make of yourself but an the opinion of others. Unless we seek it, I tend to think we find that unpalatable.

There is also the association with linear maturity models, where the models describe the stages of maturity. You can read more about our thoughts on maturity models here. TL:DR, they suck!. I wonder then if people’s displeasure with the use of maturity is subconsciously linked to their displeasure with maturity models or associated shaming experiences (e.g. “don’t behave so immaturely”). I know this is something I wrestled with. With regards to the previous point, the models themselves are placing a value judgment on your practices.

However not everyone seems so perturbed by the idea of maturity.

Lisa Angela replied to John’s tweet, quoted above with:

“In life, maturity implies learned proficiency and alignment on priorities to effectively contribute to society, but it doesn’t negate the becoming more mature, more refined, wiser. Same true here. A level where teams can consistently achieve desired outcomes but it’s not the end.”

https://twitter.com/intrepidleeloo/status/1221081935352664064?s=21

There are a number of other replies to Johns’ question that suggest maturity is a continuum, that it expresses something holistic and complex. We can also conjure pictures in our mind of the wise

We’re comfortable with both sides of this argument, we can see and have experienced both the pros and cons. So back to the original question, why use it in the name?

Self judgement

Maturity Mapping doesn’t come with an associated definition of what it is to be mature at a specific practice. It doesn’t say what it means to be mature in the practice of driving or cooking or developing software. We use a set of guides, heuristics, to enable – and this is the crucial bit – the users of Maturity Mapping to determine for themselves how mature they believe they are at a particular practice within their particular context. With a map and movement options, contextualised by using Cynefin, users can then look to plot a direction that is appropriate for them in their context.

Occupy Maturity

In case you hadn’t noticed, we have a deep dislike for maturity models, they are a complicated solution to a complex problem. But we believe, in order to try and make a dent, Maturity Mapping has to occupy the same semantic space (as Jabe or Greg put it) as maturity models. We need people and organisations to see our approach as a competitor to the traditional model approach. With that our working hypothesis is: by having a name that positions our work beside theirs, Maturity Mapping will be seen as an alternative way of meeting the needs of those who would have reached for a Maturity Model.

People’s models are anchored in specific terms. If we want to compete with context-free maturity models, then we have to use that term. The meaning of terms (and consequently how we model associated experiences) can change, especially through practice.

There is an anecdote about Peter Drucker that matters in this context. He observed that employees were often perceived by managers as a liability, almost as a necessary evil, and stand-out performers were seen as the exception to the rule. We had to accept having low-performers as a consequence of seeking and finding high-performers. He also noticed how employees only appeared in financial documents as a cost. Contrasting that, he noticed that some “inventory” was seen as assets (shown as having value on a balance sheet) and worth of investment and wanted managers to apply that thinking to people too. He then introduced the language of calling people resources in the hope it would shift the view of managers towards seeing people as assets to the business. We all know too well how this worked out. If the underlying thinking doesn’t change, changing the words/terms has no consequence, because the people who see employees as a liability will happily call them resources and still continue having dismissive models in mind. And if managers do not see the value of working with people, making them use a different term mainly spurs resentment. But if we can get people engaged in a contextualising practice, facilitating the engagement by using the terms they expect and use, we can (maybe) reshape their associated models.

We appreciate this won’t satisfy those with a deep disdain for, or discomfort with, the term maturity in this context or maturity models themselves but we least hope you’ll see that we’re on the same side here, even if our approach to tackling the problem is different.

This blog was co-written by Chris McDermott & Marc Burgauer

Timespan of discretion

Jabe Bloom, building on the work of Elliot Jaques, suggests that each level of an organisation, in particular in an enterprise, operates in a different timespan of discretion. Timespan of discretion, which needs at least a post to itself, in essence means that because different levels of an organisation consider work over different time horizons (ie executives are concerned about what the organisation will do over months and years and for members of agile development teams it’s days and weeks), the narrative they articulate together at each level is different to that at a different level. This leads to challenges as members of each level discuss work and direction together because they have a different narrative. So to ensure objectives are clearly articulated to each level, in a way that is meaningful to the people who operate in that layer, we often chain a series of practices together.

Mapping the practices

When trying to make sense of the practices and how effective they are in a particular context, I’ve recently experimented with colleagues by using a Maturity Map. Normally when drawing Maturity Maps, the anchor we place on them is that of a customer and their need. This leads the map to be bound within the context of a team or more broadly in an organisation. However, recently, when trying to develop a shared understanding of the alignment practices that a client uses, it struck me that mapping the problem could provide an interesting insight. A colleague had already created a visual that represented the artifacts and their relationships, and, interestingly, the quality of the relationships (more on that to follow) between the artefacts used. To turn this into a map, all that was left was to anchor these artefacts, consider them through the lens of Social Practice Theory and plot their maturity.

The first thing then to consider, as with all maps, is ‘who is the customer’ and what are their needs that we are trying to meet. In the context of alignment to strategic goals, the question is: who is it that needs to understand direction and what, from their perspective, does that mean? In the map below we look at this from the perspective of a ‘team member’ and their need to answer the question ‘What is the right thing for us to be working on?’. We can then follow the chain of practices used to ensure that this need is met.

What the map shows, is a chain of social practices and the quality of the relationships between them. We can see that the practices surrounding user stories, backlogs, planning and product roadmaps are all fairly well connected and are delivering value. However we can see that the use of OKR is challenged. There also appears to be inertia created by the inability to access good performance data. The inference here is that the shorter timespan (days to weeks) activities appear to be operating, but those in a longer timespan are challenged.

Focusing on the relationships

To improve our situation and mature some of the practices maybe we could focus our attention on the relationship between the practices instead of the practices themselves. Here we can see, because of the additional meaning attributed to the connections between practices by the red dashed lines, that two relationships are in need of some improvement. The first is between our strategy, in the form of a Wardley Map (of course), and our objectives articulated in the form of OKR. The second between the OKR and the product roadmap.

Highlighting the quality of the relationships brings to mind a route planner that shows roads and details whether a road is a major or minor road and even, for example with something like google traffic view, the volume of traffic and the current impact on flow. With an understanding of the quality of the relationships and more specifically the information flow between them we have further insight and options for acting.

So to improve the situation in the example above, we’ve introduced the practice of back briefing. The aim being to increase the quality of information flow between our strategy and objectives and by that improve our objectives. By having an understanding of the quality of interaction, we’ve focused our improvement between the practices and not directly on the practices themselves.

Hopefully this post has highlighted two things to consider when it comes to mapping maturity.

• Firstly, maps don’t have to be contained within bounded groups, like teams. We can look across teams and strata in an organisation and the practices used to meet organisational needs like alignment, reporting, auditing etc.
• Secondly, we shouldn’t just focus on the practices independent of each other we can also consider and highlight on a map the relationship between them.

Many thanks to Chris Downey for the insight and inspiration, which highlighted the value in visualising the quality of relationships between practices.

Note: I’m making no inference here as to how you should ensure alignment in your organisation. That’s your context 😊

Also note: the above example is just that, and doesn’t reflect a real organisation.

The book Dynamics of Social Practice puts forward the idea that practice is the integration of meaning, material and competence and that by using practice as the central unit of enquiry, we can better understand adoption, evolution and continued enactment of practices.

One of the examples used, when looking at the adoption and circulation of practice, is Nordic Walking, “a form of walking involving the use of two specially designed poles to increase the intensity of the exercise”. The book illustrates, in this example by considering the meaning of practice, how to help a practice being adopted in an environment. For Nordic Walking to take hold, walking with sticks had to be dissociated from the idea of frailty. To do this manufactures and others interested looked to ensure that the understood meaning of the practice was “one of personal health, the other of fresh air, nature and outdoor life”.

In this post I’m looking to put forward the idea that by using Social Practice Theory (SPT) as a lens to understand an organisation or a team we can be better informed as to the likelihood of success when we look to make change. I’ll also show how Maturity Maps can help us by representing the environment we are looking to change.

While I’ll focus on the element of meaning both material and competence also are key considerations, topics for future posts.

A word on theories of change

Two suggested approaches to change that I’ve found challenging are the ideas that “by changing the thinking the change in behaviours will follow” and the suggestion that we can “act ourselves into a new way of thinking”. These two distinct change approaches that are often advocated have frustrated me for quite some time. Both approaches suggest that the desired behaviour is already understood by someone in the context and by either thinking or acting the way they do, the desired change will occur.

What I’ve found more helpful when considering change in a complex environment is the idea of introducing, reshaping or removing constraints. The change in constraints acting on the system changes the system’s dispositionality which in turn allows new behaviour to emerge. By using practice as the central unit of enquiry we can be better informed as to what constraint (potentially in the form of a practice) to introduce, reshape or remove. That is, SPT could help us understand how well positioned an environment is to accept and adopt the change in constraints.

Remind me again, what is Social Practice Theory?

As I mentioned above and in a previous post, Elizabeth Shove sees practice as the integration of meaning, material and competence. Eg driving as the integration of:

• Meaning: your need for transportation, to move things or for leisure in the form of racing, a Sunday drive etc
• Material: the vehicle you are driving, the road on which you‘re driving etc
• Competence: your ability to observe, steer, make decisions based on your observations etc

Examining Change

The classic organistional and culture change story is that of NUMMI. This is the story of a collaboration between Toyota and General Motors. The collaboration resulted in a workforce, that previously produced, arguably, the worst quality cars in America, turning around to a position where what they produced was among the best quality in America.

GM Fremont

As the story goes, in 1982 GM shut the Fremont plant, laying off all of the workforce, due to the terrible production quality and unreliable production workers. At Fremont workers would drink alcohol, take drugs and frequently so few of them turned up that the production line could not be started. When the plant closed there were 700 outstanding grievances, 25% absenteeism and the fewest number of cars per worker across the whole of GM. If we were to use a Maturity Map to examine the practice within GM Fremont it might look something like this.

The map, which is purely my unvalidated assumptions of both a chain of ‘work to be done’* and the maturity of those items on the chain, suggests that the underlying practices in place were at a low level of maturity. It also suggests that improvement practices may well have been conceptual, in that the meaning, material and competence for improvement may have existed, but they were not being integrated to create the necessary practice. What we can also see is that the underlying meaning, and therefore influence, that would encourage or discourage improvement of practices was of quantity over quality and a low trust in the workforce.

NUMMI

When Toyota and GM were looking for a home for the NUMMI venture they decided to use the empty plant at Fremont. It also turned out that 85% of the workforce they hired were former employees at GM Fremont. In stark contrast to GM Fremont, two years after NUMMI was created, there were 30 grievances, 2.5% absenteeism, productivity double the previous high, 90% of employees reporting high job satisfaction as well as quality that was comparable to Toyota factories in Japan.

How was this so? What change had taken place between GM Fremont and NUMMI that enabled these conditions to emerge?

There were two considerable differences, two notable constraints introduced that weren’t present in GM Fremont. The first was that the workforce were asked by management, “how could you make this better?”. In their time at GM this was not a question that they were asked. Improvement wasn’t the job of those manufacturing the vehicles.

The second was the practice, that John Shook argues in his paper “How to change a culture: Lessons from NUMMI” changed the culture, called “stop the line”. Stop the line was implemented using a tool called the Andon Cord. This was a cord that workers could pull if they couldn’t complete their task in the allotted time, or if they became aware of a fault with the car they were building. The result of pulling the cord would mean, initially, support from a manager, and if the issue could still not be resolved the stopping of the production line. This practice was unheard of at GM. GM believed that if workers were given the opportunity to stop the line they would do it all the time in order to break from work.

The Maturity Map for NUMMI might well have looked like this.

So why did this practice take hold in NUMMI? Of course people were trained to act differently, but I believe this doesn’t fully answer why. By examining “stop the line” through a SPT lens we can see:

• Meaning: quality.
• Material: the Andon Cord.
• Competence: ability to identify an issue or know when you were unlikely to complete your task in the allotted time.

The underlying systemic meanings in the way in which Toyota carried out work both in their own plants and at NUMMI was of ‘building quality in’ and ‘respect for people’. Workers were trusted, encouraged and even obliged to pull the cord when things were going wrong.

While in Shooks terms, the Andon Cord helped workers “act their way into a new way of thinking” and thus create a culture with high engagement etc, it was a thinking that was embedded within the design of the work. The Andon Cord and the underlying meaning of quality were, in complexity terms, enabling constraints introduced by the NUMMI management to help create the conditions in which a desirable culture could emerge.

In contrast when Andon Cords were subsequently introduced to other GM plants in an attempt to replicate the success of NUMMI, they were not pulled. The underlying meaning of the system did not change, in contrast to the change in meaning which existed at NUMMI. They still operated under conditions where meeting the production targets took precedence over building a quality car.

In a software context…

With practice as the central unit of enquiry we can examine the practices we want to introduce and the interlinked meanings that exist in other embedded practices or systemically within a system. For example, think about introducing the practice of Test Driven Development into a product team environment where testing is the responsibility of the tester. The meaning for product quality is held by a different discipline to the discipline that is being asked to adopt and enact the practice. Even the practice of Unit Testing, integral to TDD, at the time of introduction was understood to be something different by each discipline. The pushback on adoption of this practice is systemic.

Now think how it might differ in an environment where product teams are encouraged and supported to do Continuous Deployment. Given this approach encourages teams to make software available quickly to end users, the meaning of ‘quality’ is then more likely to be systemic. It’s is, IME, more likely to be spread across the team and the adoption of practices like TDD are potentially easier.

Another example to consider is that of introducing trunk based development to a collocated product development team when the version control tool of choice is Git. Git was designed to make branching easy for distributed teams working at different times. In this instance it’s the meaning embedded in the toolset that makes adoption more challenging. How might introducing a constraint that removes the ability for teams to branch change practices used to manage integration?

Practice as the central unit of enquiry

Therefore using the framing of SPT as the central unit of enquiry we can ask ourselves: is the meaning required for a practice to be successfully integrated into an environment present? If not then what action can we take?

• Do we seek another practice to reach the same outcome?
• Do we look to create the conditions that could establish meaning that is coherent with the practice we are looking to introduce?
• Do we consider positioning the meaning of the practice in line with meanings already present within the system?
• Or, like NUMMI do we create a trophic cascade by replacing senior management? ;-)

What’s next?

Take time to draw a Maturity Map that reflects the practices in your team or organisation. What improvement in practice do you think you need to make to better serve your customers needs? While doing that consider the underlying meanings of each practice, how they are interrelated and what might encourage or discourage improvement of these practices. How does this inform your thinking about what constraints to introduce, reshape or remove?

Hopefully this has given you some food for thought.

Thank you

*The term ‘work to be done’ was suggested by Marc Burgauer as an improved way of referencing meaning in practice as articulated in the post Mapping Meaning.

Many thanks to Valerie McLean, Chris Downey and Marc Burgauer for review and feedback. Thanks also to Jabe Bloom for pointing me towards the Social Practice Theory rabbit hole.

I was woken on Sunday morning to the saddest message, it informed me of the sudden passing of my good friend Martin Burns. Since then my thoughts have been filled with many fond memories of him and my eyes filled with tears. I’d like to share a few of those memories here.

I first first met Martin on the 20th of September 2012 at the speakers dinner of the inaugural Lean Agile Scotland. I was running late and he offered to welcome the speakers who had travelled for the conference. He helped me for the first time that night.

He got in touch with me earlier that year keen to contribute to the conference. We discussed his talk, he shared his passion for Lean. He submitted his talk to the CfP (late… his Big Blue employer took there time signing off his submission), I accepted it. I’d like to think that helped him on his Lean Agile journey.

In 2013 I was looking to find a new venue for the Lean Agile Scotland speaker meal. My knowledge of Edinburgh’s restaurants was limited so I asked Martin and he helped.

Later that year he ran his first public SAFe training course, I helped him organise it. I encouraged him to wear a Lean Kanban University hat during the PI planning section of the course that I had picked up for him at a conference earlier that year. We thought it would be funny for the SAFe Release Train Engineer to wear an LKU hat.

He told me a story that year that I think explains in part why he so passionately believed in SAFe. While working for a client he was asked to help them design an approach that would allow them to scale their use of Agile. He thought hard about this and designed a model for them. Weeks later he stumbled across SAFe online and noted the strong similarities with the model he designed for his client. I think he developed an emotional connection at that point that led him to invest so much time and energy in SAFe.

Martin had a habit of falling asleep during conference talks, it made me giggle… especially when I was the speaker. In 2014 at London Lean Kanban Days he told me of this habit when I sat next to him for a talk. He asked me to help by nudging him if he fell asleep. He did, I nudged, he woke up :-)

In early 2015 he and Lucy organised the inaugural SAFe Leadership Retreat in Crieff, I helped (in a small way). I witnessed Martin work hard to build a community that could make what he believed in better for those who worked with it.

In the summer that year he and Lucy returned with their children from Sweden. I was in need of help, lots of it, with Lean Agile Scotland and Martin encouraged Lucy to join in. I’ll be forever grateful, not only for Lucy’s help but also her friendship.

At Lean Agile Scotland that year he and Lucy opened their home to speakers who travelled. They gave some a bed to sleep in and at the end of the conference they gave us all party to celebrate our new friendships and the community we were part of. They’ve hosted their party every year since and have helped make the #lascot community what it is… some of us call it the party at the SAFe House, I think he knew, I hope he giggled along with us.

In 2016 he asked if he could bring pronoun badges along to Lean Agile Scotland to give away at the reception desk. I didn’t know what they were, he helped me understand the importance of wearing such a badge and giving others the opportunity to wear theirs.

That year at the conference party we played guitar and sang Caledonia together. It’s my fondest memory of him.

In 2017 he tried to help us pack the delegate bags the night before the conference. He tried to organise us, I’m not sure it worked out quite how he hoped it would. It made me smile, he was trying to help.

Just last week I noticed that he looked at my LinkedIn profile. I DM’d him, here is our exchange:

It turns I had helped him see the importance in meaning when framing practice. This was our last exchange, the last time we helped each other.

I wish I could help him again and have the opportunity to receive his help.

Thank you for all of your help. You did many many good things. I am proud to have called you a friend and to have received your friendship.

May you rest in peace.

Other tributes

Lucy Burns

Dave Snowden

Chris Matts

Melissa Perri

Chris Corriere

Gordon McMahon

Sal Freudenberg

When running Maturity Mapping sessions with teams and in workshops I ask teams to map the practices they use. What I started to see appear on maps were activities that I didn’t recognise as practices, a number of times “Feedback Loops’ appeared. This didn’t, and still doesn’t, strike me as a practice.

I tried to work round this by providing a list of practices both as a starting point and as examples to use, this didn’t go well. I had clearly set tight boundaries on what I thought practice was. During the session very few new practices were added and the team didn’t engage. It semmed to stifle much of the conversation about how they worked together which defeated the purpose of Maturity Mapping. To his credit Marc didn’t even say I told you so afterwards, even though he had in no uncertain terms told me so :-)

Social Practice Theory

The conversation needs enabling and not governing constraints. Guidance on what constitutes practice and not a set of practices. When discussing Maturity Maps with Jabe Bloom he (re)introduced me to Elizabeth Shove’s work around Social Practice Theory (SPT). While it resonated straight away it’s taken me some time to get comfortable articulating how it might integrate with maps.

Simply put, SPT suggests that practice is made of three elements:

• Meaning: the motivational, emotional and aspirational. It’s why we should care.
• Material: the infrastructure, tool, technology or process.
• Competence: the skills and know how.

Let’s consider the example of cycling:

• Meaning: could be any one or a combination of transport, health, competition or contribution to the environment.
• Material: a combination of the bike and the place(road, velodrome, mountain etc) in which the practice is performed.
• Competence: ability to balance, timing when breaking, posture, personal fitness etc.

Take a moment to think about the following practice associated with software development:

• TDD (Meaning: high quality code, good modular design, rapid regression testing. Material: programming language, the IDE, xUnit Framework, red-green-refactor. Competence: programming and design skill, test design).
• Stand-up meeting (Meaning: planning, alignment, social cohesion. Material: walk the board, 3 questions, the space where you meet. Competence: knowing and sharing).
• Version control (Meaning: safe storage and sharing of code, reverting to previous version etc, Material: git, your client. Competence: knowing what and when to commit, how to pull, merge etc)
• Wardley Mapping (Meaning: situational awareness and strategy. Material: the map, the doctrine, gameplay, Realtime Board, paper & pen etc. Competence: how to recognise and document a value chain, understanding of evolution etc).
• Maturity Mapping (Meaning: situational awareness, understanding competence, directed improvement, shared understanding. Material: Wardley Map, Cynefin, Realtime Board, stickies, pens etc. Competence: facilitation, knowledge of practice etc)

We could go on but hopefully you get the drift…

Mapping Meaning

What I’ve started to find interesting when producing maps with teams is not to delve into the named practice but to look instead at the meaning of the practice. It’s allows us to develop slightly more abstract maps which has the effect of making them more coherent. Another way to put it is to ask, what is the job this practice is doing for us? Some of you might recognise this as Jobs To Be Done (JTBD).

So what a might a map, whose entries are defined via the lens of meaning/JTBD, look like?

You can see here a consistency of granularity of practice. We don’t dive into the low level detail e.g Build Software could contain many sub practices (programming languages, design patterns etc) which you may then want to discuss and possibly map in a sub map. You’ll also notice that the three branches mentioned in the original post, and seen near the top of the map above, also encourage us to think about meaning but at a slightly more abstract level.

What’s next with SPT

Not only does SPT give us criteria to examine our suggested practice but it begins to open a number of questions about things like the evolution of practice, movement strategies, defining and recording practice, sharing practice, integrating new practice and why some practices are successfully adopted while other (equally effective) practices are not. We can also start to thinking about how practice is connected. Components on a Wardley Map are primarily connected via need but what if we connected practice by shared meaning, material or competence? There is quite a bit here so I’ll return to most of this at a later date.

Hopefully that’s given you something to chew on.

References:

The Dynamics of Social Practice: Everyday Life and How it Changes. Shove et al

Realtime Board Wardley Map template by Ben Mosior

My goto game to illustrate interdependence, connectivity and complexity is called Triangles. It’s a slight derivative of the Triangles game as described in The Systems Thinking Playbook (pg 206) which is used to illustrate points of leverage in a system.

I find this game helps me in workshops to quickly move the conversation into a space where people start to understand the nature of uncertainty and emergence without using too many new terms or asking people to imagine a scenario in their mind. Through the game people experience, or directly observe the fundamental aspects of a complex system.

Complex Triangles

So how does it work?…

1. Start by clearing a space circa 4–6m square in the room (you don’t have to be too strict about this, people will move and make use of the space available).
2. Then ask for 6 volunteers to stand in the space. I’ve found 6 best but if you have 8 that’s fine too and it’s best not leave anyone out, greater than 8 gets messy. They can stand in a line or a circle or randomly it doesn’t matter.
3. Instruct each member of the group to select 2 other members of the group ensuring that they don’t let on to anyone including you, the facilitator, who they have selected. It’s crucial that their selections remain private.
4. Now ask them to stand equidistant from the 2 members of the group they have chosen… I always add “if you stand 2 metres from one, stand 2 metres from the other” just to be clear. It also anchors them in using a spacing that doesn’t end up with group squashed together invading each others bubbles. “Go”!

What follows is an un-choreographed dance around the room as each member tries to position themselves equidistant from their selections only to find as they move their selections move to do the same. After a couple of minutes order emerges, either naturally or because the group decided the positions they’ve got themselves into is good enough and they stop.

What I often do if it slows too quickly is ask one member to follow me to the corner of the room while instructing the others to continue playing, ensuring they know the member of the group I’ve moved is still part of the game.

Once it settles down and the inevitable laughter and giggles subside. I ask a simple question. “If I were to put you back to the start do you think you could repeat exactly the same pattern and end in the same positions?” Universally the answer is “no”.

We discuss that the patterns could be recorded and understood in retrospect, i.e. you could see that when person A moved person B subsequently moved because A was one of their selections, and person C moved because B was one of their selections and so on, but you couldn’t repeat it. This gives me the opportunity to introduce interdependence highlighting in this system you know who you are dependent on but not who is dependent on you. Then I‘ll add a nod towards emergence by highlighting when the parts of this system interact something new emerges (an un expected movement) which changes the subsequent behaviour of the parts.

If I’m feeling brave and haven’t bored the audience too much up to this point I’ll talk a little about dispositionality, the fact that complex systems are disposed to a particular kind of outcome and aren’t completely random.

I could, but haven’t yet, introduced the idea of constraints to the groups I’ve taught. The fact that being equidistant and making 2 selections are the constraints and that other constraints would let me manage the group differently. E.g. nominate one person that everyone must choose.

Ordered Lines

To round off I then ask the group to stand in a line, one arms length apart. I instruct them to stay that distance apart and ask the first person to take one step forward. I then ask “if I did that again would we get the same result”, universally the answer is “yes”. We have a quick discussion about linear cause and effect and manufacturing models, compare the two examples and we’re done.

Here is a talk, “It’s Systems All The Way Down!” that I gave at London Lean Kanban Days a couple of years ago where I use the exercise (circa 18 mins 50 into the talk).

I find this a super simple exercise that takes maximum of 10 minutes from start to finish. Hope it helps

Many thanks to @IanCarrollUK who taught me this in the pub after a conference in 2012. At the time his example was made that little bit more tricky when one of the members of the group decided to head off to the bathroom, luckily I’ve never had that happen again.

• Most, if not all, maturity models are context free. They presume to know what is universally good in order to give you a clear way of assessing your current capability and then plotting a path to perfection. But as software development is a complex (as in Complex Adaptive System) problem there is no universal perfection let alone a path to it. For example, Adrian Howard points out that maturity for a 30 person company is entirely different to that of a multinational.
• As Marc Burgauer highlights “they also bias thinking towards the model, i.e. blindfold for context”. That is most maturity models encourage “gap thinking” which involves envisioning their view of an idealised future state and closing the gap. This, in turn, discourages options that might otherwise present themselves.
• Jason Yip points out “they’re suggesting a poor learning order, usually reflecting what’s easier to what’s harder rather than you should typically learn following this path, which may start with some difficult things. In other words, the maturity model conflates level of effectiveness with learning path”.
• In some context being categorised as immature could also been seen as shaming. This then creates an extrinsic motivator for improvement but for that we want teams to be intrinsically motivated.

Trent Hone likens them to a treasure map where X marks the spot. The problem being the terrain you see around you isn’t reflected anywhere on the map. You know something great is out there, you just have no way of navigating your way towards it.

To improve what really matters is that we understand our own context, the challenges we face and our ability to adapt and learn to meet these challenges. That is, we need to focus on “present thinking”. I’d suggest that for a maturity model to provide utility it must reflect the context, and provide some guidance for improvement that can be selected dependent on that context.

When exploring this challenge it struck me that we have a way of understanding our current landscape, the climate, doctrine and context specific approaches to apply to make movement within the environment towards a desired state. Simon Wardley’s mapping gives us all of these things but in the context of strategy. What would happen if we turned it towards team or organisational maturity, what would that look like?

Note: If you’re not familiar with Wardley Maps please watch this before reading on as the rest of this posts assumes a familiarity with Wardley Mapping.

When describing Wardley Maps Simon uses Sun Tzu’s five factors. These are purpose, landscape, climate, doctrine and leadership. Let’s exam these in the context of a development team.

Purpose

This is the moral imperative, what we are doing and why we are doing it. For a software development team this could be the product they are building, the project, the user need, their mission etc. This is the first point that we realise our maturity map is set in the context of the problem we are trying to solve.

Landscape

This is the map that shows the value chain that represents how we act towards our purpose. What is the value chain of practices that we use to satisfy our customer need and the maturity, in our context, of each of these practices.

Climate

These are the forces that act on our environment. In the context of our software development team we could consider WIP, deadlines, quality, dependencies, team dynamics, work environment (co-location, wall space) etc.

Doctrine

Simon describes these as standard ways of operating, Trent refines this to be a “set of heuristics that inform decision-making”. This could be things like… focus on flow, develop feedback loops, visualise, inspect and adapt etc.

Leadership

This is about the choices you make, about how you act to improve your situation considering your purpose, the landscape and the climate you operate in.

An example would be good around now

Let me set the scene, to keep it simple we’ll focus on a one team one product example. The Big House company run a popular website for the housing market. One of their teams has the responsibility for the search function and their mission is to ensure home buyers “find the right home”. The team comprises of a Product Owner, 3 back end developers, a dedicated front end developer, a user experience designer and a tester. The team also work with a separate team of DBAs and have an Agile Coach supporting them.

Building the Map

To create a context specific Maturity Map we’ll first need an anchor. Given our example this seems straightforward, our anchor is our mission “find the right home”.

Value Chain

From this anchor we can then create a value chain that reflects how we as a team go about satisfying that customer need. To help guide this I start by considering 3 paths:

• Building the right thing
• Building the thing right
• Building it fast enough

If we follow one of these paths this could lead us to a value chain that looks like:

Evolution

Most Wardley Maps you’ll see describe the evolutionary axis as genesis to commodity but we need to use language that more accurately reflects what we’ll map or we’ll find ourselves continuously performing a mental juggling act. What we are mapping is practice. For evolution of practice Simon uses Novel, Emergent, Good and Best. To now map our practice we could ask ourselves to categorise each practice along the evolutionary axis using these guidelines:

• Novel — this is new to us, it’s not well understood by anyone in the team.
• Emerging — we are trying this out, it’s something we can begin to explain to each other
• Good — we are getting to grips with this, we know there is room for improvement and can improve it in our context
• Best — we’ve nailed it. It’s a practice we’ve established in the team and might not even mention it in a retrospective

I’d suggest this is a team exercise and practices aren’t mapped without first discussing the reasoning within the team. Our map might then look like this:

If we follow their other two paths we could find ourselves with a landscape that looks like this.

Movement

We’ve now got a landscape so our discussion can move to “what would be the most effective movement we could make here to ensure we have the best outcome”. For this we exam the landscape identify the moves we think would benefit the team the most. Looking at the map we see that client side testing is something that we might want to improve along with our ability to understand user need.

At this point we and then consider the climate, what environmental factors influence our ability to improve our situation, and what doctrine exists to help inform our actions. To do this we could ask the team, “how could we make this better?”, the team can then brainstorm ideas for improvement and call out impediments. Once we have all these ideas on stickies we can then group them using the following criteria:

• Any of us could do that: improvements that anyone on the team could action/impediments anyone on the team could remove.
• We know someone who knows how to do this: we know an expert that could make the improvement for us/remove the impediment or could teach us how to do it.
• We’d need to try a few things: We’re not sure how to act on this and we don’t know anyone who could so we’ll have to experiment.

What we’ve now done is introduce the Cynefin framework which gives us advice how to act with the various kinds of problems we’ve identified. This approach is very much informed by Liz Keogh’s and Kim Ballestrin’s approach to using Cynefin for estimation.

With this insight we can now add to the map the possibilities for improvement.

We can see that improving our ability to understand user need is something that we can act on but there is an impediment to improving our client side testing. The fifth of Sun Tzu’s factors now comes to play with the leadership decisions we make to improve the situation. Do we choose improving our understanding of user need over building another feature… I’ll leave that for you to decide.

Summary

As with most improvement techniques the value exists in the conversation. Building a Wardley Map for something like team maturity, informed by Cynefin, can act as enabling constraint helping us develop a shared understanding of our situation and where we can best focus our improvement efforts.

Through conversations with Marc, Karl, Chris and others we can begin to see application of these ideas at an organisational level, evaluating transformations, as part of a multi team workshop and in other areas. We’re just beginning to scratch surface I feel!

If you decide to try this out I’d love to hear how you get on. Either comment below or message me on Twitter.

Many thanks to Marc, Trent, Markus, Adrian, Jabe, Sal and Simon for their thoughts and advice on this post and the wider idea.

After 7 years of organising and chairing the programme for Lean Agile Scotland I’ve decided to call time. Creating and growing #lascot has been one of the most wonderful adventures of my life. I’ve made many many great friends along the way and learned more than I ever could have imagined (when I started in 2011 I couldn’t even pronounce Cynefin!!). The very best of those friends Marc Burgauer has decided to join me in calling time.

But this doesn’t mean the end for #lascot!! Far from it. As you may know I passed on the running of the conference to the vastly experienced Mark Dalgarno and Software Acumen last year and they have picked up the reigns with the same passion for the conference and the community in Scotland that we’ve had in these past years. I’m delighted that the conference is in safe hands and will continue to go from strength to strength.

We are immensely proud of our contribution to the community and are overwhelmed by the standing it has in the global Lean Agile community. Lean Agile Scotland will always have a very special place in our hearts and we will continue to give it all of our support from the sidelines. I’d like to reiterate my thanks to all of those who have helped us in developing such a phenomenal event. Particular thanks go to Marc for sharing this passion with me and, of course, to my beloved wife Julia for your unequivocal support.

Keep Lean Agile weird!

In the beginning

In the Autumn of 2011 I started on a journey that would challenge me in ways I never imagined and would change my life immeasurably.

Having tried unsuccessfully to attend a number of the Lean Kanban series conferences I decided to organise my own conference… after all how hard could it be, right? While I was keen to explore what was emerging from the Lean Kanban community at the time I felt that Scotland needed something with a broader appeal, something that would allow us to explore the full breadth and depth of the value stream of effective software delivery, so decided to organise Lean Agile Scotland. Within a few weeks David J Anderson and Liz Keogh had agreed to give keynote speeches and my expectations about what the conference could be began to rise.

After what can only be described as an intense year of organising, #lascot12 opened on the 21st of September 2012 at 9am with 114 attendees, 26 speakers and a 8 helpers. While the core of the content was drawn from the Kanban community there were also sessions on BDD, Scrum, Software Craftsmanship, a mini track on Rightshifting and more. Those two days were an exhilarating and emotional experience, I made many new friends and watched many other friendships form. When I look back the tweet below from Ben Forrest always springs to mind and helps cement the fond memories I have of that year.

Since 2012 Lean Agile Scotland has grown each year not only in numbers (372 attendees in 2016 with 73 speakers) but also in breadth of content. In 2013 we welcomed Dave Snowden as a keynote speaker and the complexity journey began, this was further cemented as a key theme for the conference in 2015 when philosopher Alicia Juarrero keynoted.

The community

Over the years I’ve received great feedback and have often pondered what makes #lascot so special. For many years I thought I was the only one who experienced the feeling but I’ve come to realise that many care deeply for the conference and the connections they make on those days each year. In Chris Matts talk in 2016 he described his ideas behind community of needs and community of solutions. He then asked the audience how they would categories #lascot, the overwhelming majority described it as a community of needs, Roisi Proven adding that:

“when I go to other conferences I feel like I’m poking a bear when I try and enter into a discussion, where as here it’s like poking a kitten that rolls on it’s back and says… hello”.

What is it that contributes to making this a community of needs? Is it the location? Jabe Bloom once remarked that “most cities have bronze statues of great soldiers who led armies into battle. Edinburgh has statues of philosophers, instead!”. Is it the care and attention that Marc and I put into the programme? The balance between speakers who we know will challenge the community to think differently and the introductory content for those starting out in their journey. Is it those practitioners who care deeply for the community that travel each year to be part of the event? I think we could say that Lean Agile Scotland might well be a place of multiple belongings.

The challenge

Each year I’ve received great help from friends and family for which I am truly grateful. After a particularly challenging year in 2014 I was joined in 2015 by my good friend Marc Burgauer who has helped shape the conference since. Lucy Burns also joined in on preparations for 2015 and has added much needed support in the organisation of the logistical elements.

While I may have been able to keep LAS going for another couple of years the levels of stress, often anxiety, it induces on me and more so what it asks of my family cannot be sustained. The many many evenings each year sitting at my laptop away from Julia is not something either of us relish.

Over the years I’ve seen great conferences come and go and felt the sadness and loss in the community as that time of year where they usually would gather pass without their favourite event taking place. I didn’t want to see this happen to the Lean Agile Scotland community. On the flip side I’ve often pondered what else Lean Agile Scotland could contribute to the community both globally and here in Scotland. Clearly sustaining the conference has proved to be a big enough challenge let alone have it contribute more.

What’s next…

In April 2016 Mark Dalgarno a fellow Scot, Agile practitioner and highly experienced conference organiser who I’ve known for a number of years approached me and asked if I’d be interested in passing on the responsibility of organising the conference to his company Software Acumen while still leading on the design of the programme and hosting the event. In the following months Mark and I had a number of discussions around the topics of community, diversity and the role of the conference and found that we think and act along the same lines.

After giving it many months of consideration I’m delighted to say that I decided to pass on the conference to Mark and his team. Not only is Lean Agile Scotland now in safe hands that will secure it’s future but it also has an opportunity to grow and contribute more to the community. With over 10 years experience in organising events and the passion Mark, and the team at Software Acumen, have for the community combined with the on going contribution to the programme and event feel that Marc B and I will bring I am excited for the future of Lean Agile Scotland. You can read Marks thoughts in his Lean Agile Scotland – postscript here.

Thank you!

Since its incarnation I have cared deeply for the conference and the community that has grown around it and I’m delighted that this has the opportunity continue. But it has never been just the work of one person and I’d like to thank everyone who has attended, presented, shared their ideas with our community, helped shape the programme, helped on the day, spread the word about the conference and contributed in the many ways you have. Of course a special thanks goes to Marc and Lucy for everything you’ve done.

Without doubt the biggest thank you is reserved for my beloved wife Julia who has supported my efforts throughout, been an ever present sounding board and notably packed over 300 delegate bags single handedly in 2014 while 7 months pregnant!. Thank you, always ❤️

I look forward to seeing you at #lascot17!