Modern digital technology deals with complexity. We need versatile methods and tools to cope with it. Static models are not good enough. Organizational complexity illustration is inspired by Peter Holliger’s post.

Random agile thoughts — Static and dynamic models

My random thoughts on challenges faced by an agile coach working with software development organizations, week #26, 2019

I blog on the topic of challenges that I face in the capacity of an agile coach and this is a part of the series. Find the first post on the topic here where I also explain my motivation and ambition behind this series. The entire series is available from this publication called ‘Random Agile Thoughts’.

This week’s post is about static and dynamic visual models and what is best for facilitating team discussions.

Random agile thought #6 —Limitations of static visual models for understanding a complex challenge and how dynamic visual models can provide a better perspective

Earlier this week I was asked by a colleague to run retrospective sessions with her two teams she is serving in a capacity of a project manager. Whenever I get engaged with a new team I try to collect enough information to understand the context of their situation. We did so with my colleague. And as usually do, I drew our conversation as sketchnotes. Having conversations this way helps me ensure I understand my colleague, structure the facts and connect with the context on a deeper level. I cannot reveal the original sketches as they include real people names, team names and other sensitive information that I am not allowed to share publicly. But here is the simplified and obfuscated version of it to give you a general idea:

A simple sketchnote to reflect my initial dialog with the colleague who requested a help with a retrospective session for her team. It allowed me to understand the pre-context and come up with the best strategy for the session where we would concentrate on leaving behind all of the concerns (A) so that the team could focus on a working agreement a week later when the new members join (B).

What we agreed to with her was to concentrate on a goal of externalizing and leaving behind the concerns within the team that could make things more complicated a week later when new members were supposed to join. The sketchnote conversation helped us to focus on the most important things and have a strong alignment around what she wanted to achieve with my help.

Now that the goal was clarified and set, I started preparing for the retrospective with one of the guys from the team who was supposed to be leading the session with me supporting him in the background. It quickly became clear to both of us that we were not dealing with a standard retrospective situation — most of the team concerns were around an extremely challenging deliverable they were supposed to make and all the uncertainty and anxiety around their current level of technological knowledge, the vision clarity and the new members joining. A classical retrospective did not sound like a reasonable fit at all. We needed something else — to explore the team’s concerns with regards to their delivery challenge and technological and knowledge limitations that were worrying them so much.

Usually when people run retrospectives or facilitate vision workshops, most of the time they use tools that are build around certain canvases — matrixes that combine a set of attributes that altogether provide necessary perspective on a matter. The most popular tool for a retrospective is a canvas built around three questions: 1) What did work well for us? 2) What didn’t work that well and 3) What should we aim to improve going forward? For example, there is an emergent tool for looking ahead called V2MOM.

And I have an issue with these tools — all of these tools are static models. Don’t get me wrong, I find them useful as visual models and facilitation tools. They can create a quick alignment, bring clarity and establish more confidence in a situation. But they are not good enough to create an overview to help ‘see a big picture’. A year ago I cam across a work by Simon Wardley on something he calls ‘Wardley Maps’. I must say it is a piece of a very nerdy and deep thinking and I am still trying to wrap my head around his ideas in their full entirety (darn, that man is too smart!) and still the bottom line of his ideas could be overly simplified as the following — you cannot unravel complexity if you do not visualize your strategy in dynamics.

I find static canvases quite limiting — they create a momentary snapshot of the complexity team is operating in. Most often this snapshot is not good enough to come up with reasonable strategies — plans for getting along with their complex challenge.

And here is how I put these thoughts into this case.

In the beginning of the session with the first team, we started by drawing a map of facts that everyone could agree to. It took me approx 30 minutes to capture a map looking like this:

After approx 30 min of a conversation with the team this map was born. We called it a facts map. We captured all the known events, important facts and constraints collectively known to the team.

The team was not a classical team — you can say it was two teams in one compiled by the management for the sake of efficiency — bring together the people knowledgable about a legacy system and developers capable of building a new platform to migrate the functionality from the legacy system. The facts mapping exercise helped to get a strong alignment along with an attempt to create a hi-level plan. I can tell you, there were a few powerful a-ha moments. For example, one of the team members reminded everyone about the so called ‘in-flight’ cases — the elements created by the old platform but still active at the time of the new platform switched on.

After the facts map was complete to a satisfactory extent (no one could think of anything else to be added), we asked the people to break down in smaller sub-groups and gave them 10 minutes to discuss the concerns and hindrances that could prevent them from overcoming the challenge at hand.

While people were discussing their concerns, I was observing and what I noticed was that people were relating to the map all the time. They would point their fingers to it when talking to their peers, they were basing their conversation around it, like a navigation route!

I saw people were pointing fingers to the map on the whiteboard when they were discussing the challenges, they were relating to it, it was helping them to structure their discussions. I knew immediately the map brought value into the conversation.

Then we asked the groups to post their findings and share with the rest. We got the whiteboard looking like this:

The whiteboard looked like this after we asked people to post their concerns and place them where it felt the most appropriate.

Then we summarized the findings and I drew circles around similar concerns and put short statements that the team suggested for those clusters:

Summarized findings which we organized into clusters. Short statements suggested major themes around the concern clusters.

Then the team ranked the concerns and spent some time together to brainstorm on the next steps and how they would present their findings to the newcomers the following week. I am not providing the details about the rest of the workshop as the facts map is the main illustration for the idea I am trying to convey in this post — dynamic mapping is much more effective when discussing a complexity with a team compared to static visual models.

Later the same week we ran this exercise once more and this time with another team. We have observed the same behaviour. I have seen a high level of engagement in both teams, I have seen people taking pictures of the maps — things that happen rarely, only when people are really impressed with the insights. Engineers are pragmatic people, they are not easily attracted.

When making a decision for next steps dynamic models are more appropriate — they allow us to see where we should focus. They allow us to feel more confident as we see our choices more rational supported by the visualized relationship between facts and concerns.

What should be the summary of the topic? I think that static models are fundamental and helpful — we need them to create shared manifests, some sorts of pivotal points when try to make a sense of a certain challenge or a situation. The same time static models have sever limitations when it comes to us using them for planning and strategizing. We need a better tool for those situtations. We need to be able to dissect the complexity on a timeline. We need to see relations between parts of the complex pictures to support us in our decision making process. I saw a real confirmation of these thoughts in these two workshops. People needed to see the temporal perspective on their concerns. Talking about those did not make much sense to them unless they saw their connection to their delivery goal and with regards to other concerns and their effect on that delivery.

When making a decision for your next step, you want to focus on what is the most important for you. Dynamic visual models are more appropriate to suggest the most important areas as they set a temporal relationship between known facts and our perception of the reality — our concerns.

I hope you found these ideas valuable and if so, do not forget to support me by a few 👏👏👏.

Your reflections?

Thanks for reading this piece. I am an agile coach, product owner and a vision thinker living in Copenhagen, Denmark. I blog on visual thinking and share my random agile thoughts, if you want to read more. You can get in touch with me via my Instagram account or on Twitter and do not forget to visit my web page. All the best!

How about requesting a training on visual thinking from me?

Request a training for your team at https://www.vizthink.dk/