We want to create impactful products that make our customers happier and change our world to be better place. There is a complexity to it. How do we overcome it? How do we define the best way of working for us as a team to get there?

Random agile thoughts — From uncertainty to a product

My random thoughts on challenges faced by an agile coach working with software development organizations, week #27, 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 sharing my thoughts about teams transforming complexity in great products. And how a team could approach it the pragmatic way.

From complexity to product: I see the team’s mission is to navigate complexity and create a product that organizes the chaos and uncertainty. I created this animation to suggest a visual metaphor for my idea. The idea with sticks was inspired by Geoffrey Nelson, big thanks for his co-creation!

Random agile thought #7 — Amusing idea of seeing teams as a means to transform uncertainty and complexity in valuable products.

Earlier this week I was helping my colleague Simon facilitate a full day event where he was running a high-performing team session with a team where they recently on-boarded newcomers. The team was facing a huge challenge and the goal of the session was to forge them, turn them in a hi-performing team, align around the challenge at hand and support them in making decisions around their ways of working to overcome the challenge.

While I was co-facilitating the session and helping with smaller errands here and there, I was supposed to lead the sub-session toward the end of the day where I would give an overview of what agility is and help them structure their working agreements around the agile values and their specifics.

In a dialog with the same team before the session it became clear that there was a lot of uncertainty around them —their technical vision, their stakeholders and end users, their knowledge of the technology and knowledge of adjacent systems they would be depending on and so on. The entire challenge looked to me like a huge hairy ball. I can even remember us referring to it in such terms several times.

My assignment was to open up the discussion around the working agreements stemming from the agile values. So how could I inspire a good dialog around the topic while remembering to address concerns associated with these uncertainties? How could I speak to their practical concerns, so far away from the abstract and philosophical considerations of what agile is and what it means to people? I did not have much time — I had 10–15 minutes to open the topic and then the team would break down into smaller groups to discuss how they wanted to work together. Quite a challenge — you do not have much time but you would like to deliver a compelling message across.

First let me tell you something. When people talk about agile and ways of working from a perspective of practical application, they tend to go straight ahead into Scrum framework. The reason being is that Scrum seems to be so close to the reality and so simple — just have these meetings, roles and artefacts in place — and you are almost there. I wanted to avoid this. I do not like the idea of taking Scrum as a starting point — the reality our company’s teams is usually more complex, and the teams often feel intimidated thinking they are doing something wrong since they are so different from what Scrum is prescribing. I did not want them to arrive to this conclusion and this time I wanted to do something else.

Here is how I did it.

It starts now with the complexity and the uncertainty around it being the biggest. Uncertainty around the team and the inter-relations, the customers and their needs, the organization including the management and the stakeholders and the product and the solutions we choose.

I drew a timeline on a whiteboard and then a big hairy ball. I told them — this is the complexity of the challenge as you know it now, today. It has a lot of uncertainty around it — the way you work and interact together as a team and how you should work together, what customers and end users need, the organization around you including your management and stakeholders and other teams you are depending on in your deliveries, the product to be built itself and the solutions you need to choose. And as we progress, we would like to reduce the complexity, we would like to remove uncertainty that blindfolds us making our decisions difficult or impossible.

If we want to overcome complexity, we need to generate knowledge, we need to become wiser about the challenge. At least when it comes to digital products, the only way to generate new knowledge is to produce something tangible and see how customers react to that.

Then I continued the narrative saying that we can only achieve that by generating new knowledge that we do not have at the moment. The knowledge about what feasible and what is not, the knowledge about how our organization reacts to our work and our working style, the knowledge about what our customers think about our emergent product and how does that change their behavior — the outcomes. And the only way to generate this new knowledge is to create something tangible and see how the customers react to these.

The ‘Death by Meeting’ book by Patrick Lencioni suggests ideas for finding a good balance, define coordination activities that are the bare minimum for bureaucracy needed to keep things coordinated and organized.

I continued saying that this is a team work — a lot of people working together. We want the advantages of diversity of skills and personalities. But a lot of people make things more difficult, more complex. On one hand we want to get concentrated on making things and doing work, but on the other hand we need to stay in sync, keep each other updated and learn from each other. We need coordination for that. In big organizations there is a lot of dysfunction around meetings and people hate them. But we need meetings, we just need to learn to do them right. I mentioned the book by Patrick Lencioni called ‘Death by Meeting’ which suggests a good balance between coordination activities and sets the bare minimum for bureaucracy needed to keep things in order.

Patrick Lencioni’s model suggests four levels of coordination that are needed to keep things in order.

I then introduced them to the hi-level idea of Patric Lencioni’s model with four level of coordination. I stressed out that daily check-ins and weekly tactical coordination is totally within the realm of the team, hence under their control. While monthly strategic alignment and quarterly meetings are either a higher level and are in a way the team’s interface to the bigger organization around them.

I used Patrick Lencioni’s model to show what types of events are circulating in the organization to help the team to relate to them but also to challenge the need and the value they get from those meetings.

I knew that there was a confusion around the lingo of meetings and ceremonies circulated inside our organization. People would refer to dailies, master plannings and big room plannings making things even more unclear, mixing ideas from various frameworks. I wanted to sort it out for the team so that they would be able to recognize the idea behind those meetings and make their own educated decision with regards to what type of coordination they needed. Therefore I used two colors and mapped the ceremonies from Scrum framework and also mapped three more organization specific events that gained high popularity and use inside of our big company.

Then I told them that there are three major things for them to keep in mind when making decisions around their ways of working as a team:

Then I used the diagram as a map to show them the three major things they needed to agree to in order to define a solid way of proceeding with their ways of working.

Those three things included:

1. Use the ideas of Patrick Lencioni’s model to challenge their coordination framework and try to keep it to the bare minimum — only the things that are helping overcome chaos and uncertainty and keep at bay things that only take away time and energy, not bringing any value.
2. When coming up with their way of working, the team should not try to come up with an ultimate version of ways of working, the best model ever. It is better to think of the biggest challenges at hand for the next, say three months and then think together what would be the best way to organize to address the short term uncertainty the best way and change later as needed.
3. Re-think the way the team uses retrospectives — move away from using them as a sub-optimization where they usually focused on delivery within an iteration; and instead see it the way it was supposed to be used — as a platform for the team’s continuous improvement dialog. I also offered the team to carefully capture the biggest findings from the workshop and create the team’s backlog for their continuous improvement ideas. Retrospectives would then be used to revise their findings and re-evaluate challenges. Inspect and adapt.

The team then used the visual map on the whiteboard to arrive to consensus around the next steps and the missing pieces to their ways of working.

Now that the team was clear and confident about what a model could look like and what are the minimum required components to support it, they started the discussion, as a team, where they identified the critical missing pieces and came up with agreements what should happen next. For each missing piece they kept a flipchart sheet to write down needed details while they used a sticky note with a key word to map it on the model to visualize where the missing piece belonged to. The missing pieces where not only about the ceremonies but also about people they needed to involve and things they needed to do to establish their continuous improvement backlog.

The rest of the workshop does not fit into the topic of this blog post and I will not mention what happened next.

Summary

I would like to suggest that changing the narrative from using a commonly accepted framework to talking about the team’s unique challenge and the concept of overcoming uncertainty caused by complexity really helped me to make the dialog with the team more real, more pragmatic. We were not talking about agile or Scrum and the necessity for them to close the discrepancies gap. We talked about the things they cared for and were concerned of — like can we achieve the goal? Do we have the skills needed? Do we trust each other? Do we have the support of our organization? Do we know our customers and our stakeholders and what they need? Do we have enough knowledge to come up with viable solutions? And then do we know how to work best together and with the organization around us? How do we know if we are overdoing it or doing less than enough? It felt more real to me, I felt like I could be more helpful. I was more happy with my part in it.

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!

Considering to request a training on visual thinking from me?

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