Is SAFe a complicated solution to a complex problem?
Many would agree that product development is a problem in the complex domain. The more we alter our product and the more our user use it, our problems change, turning product development into this dance of probe–sense–respond or build measure learn. To stay in tune with the problem as we try new solutions we have to keep on dancing.
But what about the system that is building the product, is it a complicated or complex one?
If you where to think that it’s a complicated one, what kind of solution for the system would you design then?
One with a lot of roles, templates and “best practices” of course. Since the problem is complicated the equation will always work in every company and with every individual. There is no need to improve the system solution because it’s thought up by experts. If however the solution system doesn’t work, well then you are just doing it wrong. Come back when you follow all the rules (which of course is impossible). The goal has now shifted from doing things better to making sure that you are following best practice. Some would call this “renting” your way of working as opposed to “owning” your way of working.
In my opinion, the system that is building the product is also in the complex domain and we should use the same probe–sense–respond approach there. This, however, makes change more unpredictable and adjustable. Instead of installing a system solution, we now have to figure out where we want to go. When we have a goal in mind we can figure out where we are, and what our first experiment should be. Then tune and adjust as we move on in a probe–sense–respond fashion. What our solution is in some years time, no one knows, but it’s a process that suits the environment and is owned by the people working in it.
If you want your organization to reach its goals, don’t copy what others have done, but use their experience in your own experiments. The goal is not to adhere to a complicated solution but to get better and better at handling complexity, for your product and your organization.
I asked Andrew Sales at Scaled Agile if SAFe is a complicated solution to a complex problem at the SAFe SPC conference in Stockholm. His answer was that SAFe can be useful to make sense of a complex system. If you use some of the SAFe elements you can better see and adress the problems that becomes visible. He also argued that SAFe is a common ground from which the company should evolve their own practices according to their own needs, and not be used as a rigid framework. If a company still uses SAFe by the book one year later after starting out, then they are doing it wrong, they should learn and adapt. When SAFe X.0 is released they can simply look at all the new “current good practices” and pick what they want to try.
My thoughts is that yes SAFe is a complicated solution and may be used to help companies understand how to improve in what ever they want to improve. The question is how ever if this could be done in a simpler and faster (probably cheaper) way.
