Updated: Feb 7, 2019
Almost all the large companies I know are working in some way on an one WoW and are completely under the spell of becoming Agile. We need to be fast, flexible and predictable. On the other hand I hear a lot of talk about that 'Agile' doesn’t work either. It even becomes a dirty word. Though we need to understand where we are and why we are there to really grasp the situation we are in. Scaling Agile is part of this understanding to my opinion.
In 2018 some of my colleagues and I designed a Scaling Agile workshop. You could ask, why do we need this, we have a one WoW and probably, like us, you are already working on some Scaled version, right? Well, that may be true, but the most of us still encounter a lot of challenges in our current WoW and that surfaces, for example, in the form of a lot of dependencies between teams and departments and although not always measured properly we still (in quit many cases) have a long lead time. So Agility is far away still.
The reason we are working on an Agile WoW is that we as a company have a strategy which needs a fast and flexible (and predictable) delivery. We want a fast service for our customers and we are not there yet!
So, is there something wrong with our WoW, or first Agile steps? Well, that’s a quick and big ‘no’. The beautiful thing is that the most of us are very successful with a WoW. Might sound like a contradiction to what I just claimed, but it’s true. Because we are so successful and Agile is almost everywhere, we encounter the real issues we as a company have. It makes our challenges really transparent. That’s also what Agile methods like Scrum and Kanban promises us, right? Well here it is and now we can do something with it. Though, a lot of organizations stop right there and just see these surfacing issues as a downside of working towards Agile. But this is just step one. Years and years we build our companies to become what they are now and we can’t expect to turn into Agile companies overnight or in a year for that matter. It takes time.
Especially large and complex organizations have complex IT landscapes and process structures. To break that down and bring that into something we can turn into feature teams that can truly service the customer end to end in one sprint is just very difficult and that takes time.
Although we have a lot of Scrum and or Kanban teams, still the larger amount of them are component teams. That means we need a lot of handovers between teams (read dependencies) and even departments or external companies to service the customer. We build pieces of the product instead of end to end solutions.
Working in a large and complex organization means we can’t just apply ‘normal’ Scrum like the Scrumguide prescribes. Scrum is designed for one team and we are with way more than one team. Though that’s what the most of us did when they transform into an Agile organization. We copy paste Scrum teams along process steps and IT architectural components. We as Agile Coaches are often asked to help these teams to grown on Agile Maturity. We can see a team as part of the whole system (within a product). So, we optimize the parts instead of the whole. MIT and Harvard studies have already proven that optimizing the parts is not going to optimize the whole. Worse even, optimizing the parts will slow your organization down.
As Scaling enthusiasts we believe Scaling Agile is a handy toolbox thing, but also a necessity to at least understand. So we can recognise and act on related situations when needed. Therefor we developed a workshop and training that creates awareness, not just a framework, but understanding of the wat we are organized right now and what you can do with it. It would be a waste to just press on better single teams and be blind for actually not helping the system, but helping it to slow down. So, if you want to learn more you can join our workshop, join the guild or a meet up and talk and learn about it. We also have a lot to learn still and can use your insights as well.