Alle Beiträge von martin

Cynefin: We need to teach this in school!

Using the wrong tools

You probably know about his metaphor: Using a hammer to drive in a screw. While I knew about the idea of using the wrong tools to solve problems for many years, I only recently learned about the Cynefin. This framework describes this situation much more profoundly and has been an eye-opener for me. Having been a victim but also a perpetrator of „using the wrong tools“,  I can’t wait to write this blog post. Because so much pain has been created.  So much effort, money and motivation has been wasted. And even worse, it continues everyday. We need to change this! You need to learn about the Cynefin-framework and you need to pass on the word.

I will only scratch the surface of the framework, but that might already sufficient to change the way you see the world. At least that‘s how it was for me when I first got in contact with it. But before I start to talk about the framework let me provide some of my very own examples that should explain  why we need to learn about it:

  • Several years of time and lots of money wasted trying to develop a new revolutionary product for a large German firm; treating this as project to implement some fixed scope without regularly asking for feedback and quickly pivoting.
  • A large, company-wide transformation project managed with a project plan containing some thousand tasks.
  • Countless well-thought-out strategies and large re-organisations failing or not fully reaching the desired and planned outcomes
  • Neglecting what we already know of good-practices in project management when building an office 
  • Hours and hours of heated discussions about the best way of working

And these are only me own personal experiences… So, without further ado, let me quickly present you the the Cynefin-framework. I will come back to these examples and some notes on digital transformations later.

The Cynefin-Framework

This is how the Cynefin-framework looks like. You can see four quadrants. Unlike many other models, it does not have dimensions, i.e. there is no x or y axis. It‘s basically these four quadrants and some area or space that separates these area. I will not talk about these borders and why some of them are thicker and some are thinner. Let‘s keep it simple. Four quadrants. The titles of them all start with with the letter „C“. They are called CLEAR, COMPLICATED, COMPLEX, and CHAOTIC.

What can we find in these quadrants?

Let me quote Sonja Blignaut from the book „Cynefin. Weaving Sense-Making into the Fabric of our world“. She writes „At its most basic, Cynefin allow us to distinguish between three different kinds of systems:

  1. Ordered systems that are governed and constrained in such a way that cause and effect relationships are either clear or discoverable through analysis;
  2. Complex systems where causal relationships are entangled and dynamic and the only way to understand the system is to interact; and
  3. Chaotic systems where there are no effective constraints, turbulence prevails and immediate stabilizing action is required“.

Let‘s start with Clear: Clear is the domain of best practices, the solution to a problem is visible to everybody. The relationship between cause and effect is obvious or has become obvious. Some examples might help: How about  the work in a call center: a customer calls, the agent listens and then quickly chooses a corresponding script to help the customer with a solution to the problem.

Another example could be building a family home. A house. That‘s not a simple task. But it has been done a billion times before. We have best practices. The domain is fully understood. There are even catalogs in which you can choose your dream home. By the way, clear or obvious or simple does not mean easy. It can still be difficult and hard work. Moreover, building a special opera house like the one in Hamburg does not fall into this domain. 

Now the Complicated domain.  Here, the solution is not visible to anyone.  You need expert knowledge. This is the expert domain. An extreme example could be flying to the moon. There was a massive amount of expert knowledge and analysis required to master this enormous challenge. Yet the relationship between cause and effect, although complicated, could finally be understood. Or how about building cars. Engineering work. Another example from the IT world would be the global roll out of an ERP system. This is clearly not an easy task, yet we have good practices for that. We can build methodologies for that. We can have process charts, templates, role descriptions, artifacts. We might build a physical or commercial model. We might even be able to analyse and estimate the work and offer a fixed price since we know how to control and manage the work.  Problem solving in the complicated domain is not easy. But if you get enough brain power, if you get your best engineers and experts onto the project, you will be able to find a good solution. Maybe not the best one. This is because the relationship between cause and effect can be analysed and understood.

Now, this is all different in the Complex domain. Here, the relationship between cause and effect can only be perceived in retrospect. What does that mean? Well, the impact is enormous. No matter how many experts you assigned to a problem, no matter how smart they are, no matter how hard you try, you are not able to derive a solution. Well, in fact you might be able to create a solution, and you might convince yourself and others that this is the solution. But as the cause and effect relationship in the complex domain is only visible in retrospect you are simply fooling yourself and others. And this is happening everyday. And I can confess: I have been a great fool myself.

To make this article concise, I am skipping the Chaotic domain. The interested reader will have no problem to finding out more about Cynefin and go much deeper.

For now, let’s focus on the implications: Like many of us, I have been socialised with the belief that through proper analysis we can find a solution. Being trained in mathematics and engineering I would look at a problem („sense“), then take it apart, understand its properties („analyse“) and finally develop a solution („respond“). With proper training and some years of experience, I have become an expert in my field (e.g. project management) and became good at applying the practices. Where is this approach located in the Cynefin framework? Well, you guessed it right, it’s in the Complicated domain. So far so good. But the problem starts when we apply our good practices in the complex or chaotic domain. Here, the cause-effect relationship cannot be known in advance. Thus, we need a very different approach. In the complicated domain, we first need to try out something („probe“), then we see how things develop („sense“), and from the feedback we have received, we continue or change our approach („respond“). In a nutshell, this is what agile methodologies are all about. They emphasise on fast feedback and acting upon it.  So coming back to the initial metaphor, we get into trouble when we apply the wrong tools (think „hammer“) in a specific environment. Most often I see this as good practices from the complicated domain being used in the complex domain. That might be project and program management methods used in complex product development or for transformations. But sometimes also (yet, less often) when we use agile methods in situations where we already have good practices in place.

Moreover, knowing the Cynefin-framework, the discussion we often have during a digital transformation becomes much easier. As it is not about which way of working is better. Is agile better than waterfall? Or the other way around? This is fundamentally the wrong question. It’s rather if the set of tools or approaches are well suited to the domain. 

I wished I would have known about Cynefin much earlier.  This would have saved myself and my teams a lot of wasted effort (being the person using the wrong tools).  Or it would have given me the confidence and the arguments to say out loudly that something is going deeply wrong (being the victim). I wished we all would learn about the Cynefin-framework. So why not discuss it in school? Until we are there, please help to save ourselves lots of wasted effort. Please have a look at it yourself and tell others about it.   

Anti-Pattern: This shot must be a winner

This video is about a pattern that I have noticed lately in the IT industry. It‘s actually an anti-pattern or a fallacy and I would like to call it „this shot must be a winner“. Or in other words, this project must be a success.

Despite all our knowledge about large and complex IT programs, I see that these are planned and started again and again. We know,  they have a high risk of failing,  they become late and exceed their budgets and customers are often not happy about the end results.  I personally have been a member in some of these death marches so I know what I am talking about.

But why do people still consider these large and complex IT projects? Despite the knowledge of their implementation risk. Despite the knowledge that chances of success can be improved, e.g. by decreasing the batch size. In other words be cutting large initiatives into several thin slices.   

To be frank, let’s acknowledge, there are some programs which are  large and complex by nature. Think of building a large bridge or a train track from one city to another. An agile approach of delivering value fast, breaking down initiatives and  experimenting with MVPs does not really work there. At least to my knowledge. Please let me know if you know any examples in the comments.  I am really interested. So some of our challenges don‘t lend themselves to reduction in size, complexity, risk and time. And as a  side note and teaser, the Cynefin framework can help us to understand why and how some challenges are different than others.

Ok, back to today’s IT programs. A few days ago I moderated a round table about portfolio management. A participant said that the days of large and complex programs have passed. I thought, yes, she‘s right, but at the same time, this  is not what I am seeing out there. Again and again, I am seeing large and complex IT programs kicked-off. With unrealistic time lines, unclear outcomes and high risks. I hear IT managers say:  „This project must be a winner“.  „We really need to get it right this time“, „we are setting everything on one card“. Or even „The future of our company depends on this strategic opportunity“.

Then I think, they should know better. They should know about the risks of large and complex  IT programs. They should see the possibilities to cut out thin slices, start with MVPs. Or use methods like R.A.T (riskiest assumptions tested). Why don‘t they get it? It’s all there, right in front of them. The evidence, on the one side, and the principles, techniques and tools on the other side. And yes, I hear complaints from some managers in these death marches.  So what‘s happening?

I came to believe that it is not the individual‘s desire for large and complex IT programs that creates this anti-pattern. I rather believe the problem is systematic. I came to believe that the root cause lies in way how mature companies have grown over time to become what they are. And it’s these mature companies where I see this anti-pattern. I believe this anti-pattern is rooted in the management hierarchy that mature companies have established over years of growth. You know this management hierarchy. It’s the predominant org structure in well developed or mature firms. 

In short, as firms grow and mature they utilize efficiencies of scale to offer once differentiated services at lower prizes as the competition it catching up. They need to, in order to survive in a competitive environment. And by doing that, they create silos. And these silos can make a firm more efficient, but also less able to change and adapt. 

So, the management hierarchy and silos.

Let‘s have a look at how decisions are made in the hierarchy.

Decision move up the management ranks. They bubble up. Look, managers usually don’t push decisions downwards to the teams or people affected. One of the reasons is that teams usually don‘t have end-2-end responsibility for the services or products they create. Usually, they are not autonomous. They are dependent on the input and alignment with other teams. It’s a direct consequence of having silos. Let‘s not forget why we have these silos in place to begin with. Within them, people can specialize, they can build deeper knowledge and skills with peers who are working on the same kind of problems. They gather more work of a similar type and thus can automate and use pooling to become more efficient. 

Let‘s say,  one team decides to implement a certain capability or change. As this team is not autonomous, it requires support from one or more other teams or colleagues from other departments. Thus,  now, it‘s not a single team working on this initiative any more,  but people from different teams or even a coordinated effort from several teams. And therefore the scope gets larger. And due to alignment and required hand-overs the duration also increases.  So it‘s not the team‘s decision alone any more. Thus, decisions naturally move up the hierarchy. And they become larger in scope and impact as more teams get affected. So changes and the associated decisions naturally become more and more complex. And consequently they also become more risky. And management is aware of that. They ask teams to go back and further analyze the proposed change to make it less risky. Obviously,  this well-meant task further slows down execution speed. In my practice I have witnesses several of these analyses and feasibility studies being executed, the result were nicely prepared, but NOBODY, yes nobody,  actually looked at the results. Since further more urgent questions came up in the meanwhile. That‘s a large source of waste. And obviously, people doing the tedious analysis work also loose their motivation over time. 

As changes in mature firms take longer to implement they also miss the chance to quickly see the impact and the results of initiatives. So instead of learning and making further decisions based on these learnings, they need to rely on business cases and management narratives.

With that in mind, I don‘t blame any individual for starting a large and complex program. For saying „this shot must be a winner“. It‘s the org structure of mature firms that creates  large and complex IT projects. It‘s the system. And as long as we don‘t start changing the structure of the organization, digital transformations will continue to fail. And we will continue to see large and complex projects and many of these will fail, as well.

So what can we do about this? To be frank, I am not sure. Digital Transformations are difficult. Yet, considering the agile principle of starting small,  the first thing is awareness. Understanding the impact of the management hierarchy and silos. And seeing how it can be done differently. Seeing truly agile firms.  Experiencing how autonomous teams operate. But beware of faux agile or cargo cult agile. So go visit the valley or start here in Berlin. And that is not just for the development teams, especially managers should consider the impact of silos and the management hierarchy Go and read about the evidence. Read about Conway‘s law. Then, if you are a VP or director, think twice the next time you ask for a feasibility study. Why don‘t you ask for an MVP instead and learn from the user feedback. If you are a program manager, think twice and ask yourself if you really want to wait for 18 months to see the first results. And be honest to yourself, chances are that you don‘t even get results in 18 months, it might be later and you might not get what you have hoped for in the first place. Listen carefully the next time somebody tells you this project must be a winner. Investigate how a thin slice could look like. It‘s not easy, to be fair, but so are these large and complex programs and death marches.

Distributed Delivery: Game Changer für Software-Exzellenz im großen Maßstab

Offshoring ist für viele eine verlängerte Werkbank für IT-Projekte. Für uns war es das nie. Wir bei ThoughtWorks leben das Konzept der agilen Softwareentwicklung in global verteilten Teams oder auch Distributed Delivery. 

In diesem Webinar diskutiere ich mit David Toborek (Metro Digital), Daniel Loeffelholz (ThoughtWorks), Sven Dittmer (Mercedes-Benz) und Lucy Chambers (ThoughtWorks) über Distributed Software Delivery.

Hier geht es zu Aufzeichnung des Webinars:

Top 20 Mistakes in Agile Offshore Software Delivery

For many years I have been involved in distributed software delivery. At the beginning in a waterfall setup. Since 2017 also in agile distributed delivery. I have seen many engagement fail and also have been part of successful delivery setups. Here’s my personal top 20 list of mistakes in that area.

Nr 20: Involve offshore teams too late
Nr. 19:  Forget to plan enough travel cost
Nr. 18: Forget to invest into communication infrastructure
Nr. 17: Neglect the time zone differences or cultural norms when scheduling ceremonies
Nr. 16: In communications, forget to level the playing field
Nr. 15: Teat all offshore location as „Offshore“
Nr. 14: Missing alignment on the delivery model
Nr. 13: Trying to enforce the same working mode for all teams
Nr. 12: Use the one-size-fits-all delivery model
Nr. 11: Go distributed with the wrong engagement
Nr. 10: Assign the wrong work to the offshore team
Nr. 9: Forget to extend the role model setup
Nr. 8: Deny the language differences 
Nr. 8: Not understanding political and cultural differences across the locations
Nr. 6: Forget the relationship building
Nr. 5: No direct access to users and customers
Nr. 4: Forget the business view 
Nr. 3: Forget to create the big picture for offshore teams
Nr. 2: Offshore teams not on eye-to eye level  
Nr. 1: Do it for the wrong reason, i.e. only look at the price

Future Skill „Vielseitigkeit“

Dies ist die Aufnahme eines Webinars zum Thema „Vielseitigkeit“. Sylvia Kern, Tanja Merz und Linda Barron stellen sich als Scanner-Persönlichkeiten vor. Ich habe die Diskussion moderiert und die Fragen aus der Zuhörerschaft aufgenommen.

Die Digitale und Agile Transformation benötigt ein agiles Mindset, agile Methoden, Know-how und die Kompetenz, komplexe Anforderungen zu lösen. Komplexe Antworten finden wir jedoch nur in der Vielfalt und der Vielseitigkeit von Menschen und ihren Fähigkeiten.

Bisher wurde das Augenmerk zu sehr auf die Expert:in gelegt, zu wenig wurde erkannt, wie wichtig ein vielfältiges Know-how ist. In Zukunft werden die Scanner, Multipassionates in der Business-Welt nicht mehr wegzudenken sein. Disruption bedeutet, Geschäftsmodelle, Technologien, Strukturen uvm. aufzubrechen – Startups sind beispielsweise Meister darin.

Routine Aufgaben werden künftig immer mehr von der Digitalisierung abgelöst, was bleibt, sind die komplexen Herausforderungen, die durch cross-funktionale Teams gelöst werden. Wer neue Wege beschreiten möchte, muss nach unkonventionellen Möglichkeiten suchen. In Zeiten von Digitalisierung & New Work sind Menschen gefragt, die anders denken können, Vielfalt wollen und diese auch selbst leben. Es sind diejenigen gefragt, die anders denken wagen, die Mut, Intelligenz und Führungsqualitäten mitbringen und sich sehr gerne neuen Herausforderungen stellen wollen.

Micro Frontends

Micro frontends are an architectural style that take the idea of microservices and apply them on the frontend part of (web) applications. I am talking with Ward Coessens, MengMeng Yan, and Eka Rudianto about their experience with using micro frontends.

We cover the following topics:

  1. Why do you need micro frontends?
  2. The Browser as a development platform
  3. How did we start with micro frontends in 2017?
  4. As a developer, what are your experiences with micro frontends?
  5. Are micro frontends visible to the user?
  6. How do different parts of the frontend communicate?
  7. What’s the relationship between micro frontends and microservices
  8. How does this relate to autonomous, cross-functional teams?
  9. How does it really work?
  10. Should you build you own framework?
  11. Should you now use micro frontends for all your web applications?
  12. How can you ensure a consistent design experience?
  13. How does an interactive component library look like?
  14. Where can you find more information?

Learning Breakthroughs #2: Steering Committees

In agile environments, we don’t need steering committees. Steering committees are a dying species. They are part of an outdated governance structure which is not suitable any more for today’s fast paced product-oriented environments.    

In this video I tell the story about my relationship with steering committees and how I needed to unlearn using them as a governance tool.

Modern Functional Programming with Clojure

Clojure. That’s a modern functional programming language. Not only the people who just read the book the Unicorn project in which functional programming is discussed wonder about this language. Why is it that functional programming is becoming more and more interesting in the business world now.  I wondered what was behind this hype and therefore got together with my colleagues Ward and Naveen who helped me better understand Clojure. 

In this episode of ThoughtWorks tech talk we take a close look at Clojure. In our discussion we talked about the functional paradigm, look at immutability, why Clojure is thus well suited for parallel processing. 

We also take a look into actual Clojure code starting with a Hello World and closing with how  map-reduce looks like in Clojure How difficult is it to learn Clojure and what can help you to get started? 

Learning Breakthroughs #1: Risk Management

This learning breakthrough video is about how I found out what is really important about project risk management. After a short intro to risk management according to the project management institute (PMI), I tell the story how I managed risks on a large HR payroll outsourcing project. This led me to recognise that it is paramount to actually create and commit to actions derived from the risk log. Moreover, making conscious decisions, communicating these decisions and actions and involving your teams and stakeholders is important, as well.