@dgoosens wel sometimes you can, through agile, make (part of) a complex problem complicated as long as you probe it and find out which solution works (for now...). But yes, you can never ever ever reduce complexity....
In a complex environment, you need to use heuristics to allow new practices to emerge organically. The problem I see is that most transformations only optimise the work and structure, ignoring the social and system aspects. Real success happens when you jointly optimise all four parts of the sociotechnical system and include the people who do the work in the design process.
I'm convinced that the biggest reason agile transformations struggle is that we're using the wrong approach. Agile is most effective for complex problems, yet we apply a complicated approach—copy-pasting pre-defined "best practices" from large frameworks—to solve them. But if your problem is complex, so is the process of solving it.
1/2
And it's a two-way street! Because the teams are so close to the product, they're constantly observing and finding new opportunities themselves. Less time dictating, more time discovering and building together. That's where the real magic happens for great products.
Instead of getting bogged down in writing super detailed requirements and just handing off designs, POs are freed up to dig deep into market research, really understand opportunities, and collaboratively model solutions right there with the team. It's a fundamental shift in how we work.
When teams truly own their domain and design architecture through Domain-Driven Design, combined with Team Topologies and solid Continuous Delivery/DevOps practices, Product Owners get to do so much more actual product management. This was one of the biggest eye-openers from the recent Domain-Driven Design training for product management I gave with Connected Movement.
@rhys depends on my goal. I equally use all of the tool TBH for a while now, hence this hands-on. But Wardley is easy to start, but requires a lot of practice to get the most out of it I must say, but then the impact is highest I think.
Because when you're dealing with genuine complexity, relying on just one collaborative modelling tool is simply going to fall short!
My sincere thanks to the @dddeu organisation for providing us with this platform, and a special thank you to every single participant who joined us.
And working with eight people on Wardley Mapping is already tough, but on a whiteboard where moving things feels like a huge effort compared to Miro? Even tougher.
In the coming months, I'm setting up a new DDD-crew repo – tentatively called 'When to use what CoMo tool' – where we'll capture all our learnings from the session. Our hope is that this becomes a sort of blueprint, inspiring others to experiment with these tools and discover what works best for them.
For me, it was also a personal challenge: could I use Wardley Mapping for a solution space with eight people? I usually rely on it for mapping the current landscape, often in a "together, then alone" approach for design. And yes, it was challenging, but we definitely uncovered a ton of valuable insights. The main thing missing was that initial map of the current landscape to kick things off.
