Alle Beiträge von martin

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.

Creativity Demystified – Lateral Thinking

Let’s say you have a difficult challenge and need some great, innovative ideas to get through this. Wouldn’t it be nice if you could just snip with your fingers and there you have it, these great new ideas?

This video is about taking creativity from some mysterious magic to a (somehow) predictable process. I will introduce you to the work of Edward de Bono on Lateral Thinking. This helps us to understand better how our brain works and understand why we can become trapped in our own successful thinking.

With the help of a metaphor I will explain different methods on how break out of these thinking prisons. In the end I take these concepts and apply them to brainstorming and provide concrete tips and tricks how to conduct much better brainstorming sessions which will give you more and better ideas.