This article about Agile software development processes will start with a reference to probably the biggest problem left (as yet) unsolved for 21st century science. It will be appealing and entertaining maybe for the part of you who still think of themselves as being the class geek and for the rest, I’m hoping, it will be at least intriguing if not a bit far-fetched.
The problem I am referring to is plain and simple, the quest for the “Theory of everything”. If you don’t know what this means, the first question that comes to my mind is “Where have you been living so far?”.
Jokes aside, the metaphor I am referring to, is the continuous effort of the most brilliant minds in science to reconcile the two apparently incompatible versions of our universe: the quantum world and general relativity. The first deals with what happens on a very small scale, on distances measured by Planck’s constant (10-35 m) in the realm of photons, quarks and bosons. This world is governed by strange laws and forces. The second explains what happens on our scale: humans, planets, galaxies and the universe. This world is governed by gravity.
Names like Einstein, Hawkins, Bohr, Schrodinger and Feynman should sound familiar and you should also know that currently there isn’t a definitive form of a theory that could explain and model both versions of this reality. You could argue that now we have Quantum Field Theory or String Theory that have the greatest chances to become the ONE theory, but probably there is still a long way to go.
Why this unexpected parallel between physics and product development?
Not because there is place for comparing the greatest geniuses our world has produced with people working in IT. Nor because we want to say developers are similar to bosons or electrons in that they can be very elusive when their current state is being assessed. Or that their behavior is hard to understand sometimes. And nor is it because companies are similar to planets with a comparable inertia and resistance to change.
The aim is to get ourselves back down to earth and look at our organizations and the systems we are developing from a more pragmatic and realistic point of view. Understanding that even though complexity exists and the problems we are facing are nevertheless real, they are nowhere near comparable with the really hard problems in other fields. They can be tackled and solved with the right mindset and will power in a reasonable amount of time.
The good news is that we are dealing with systems which have behaviors that can be understood, modeled and improved even by engineers like me. The two main systems we are talking about in product development being the product itself and the organization working to implement it.
In the product development domain the two sides needing to be reconciled are the business people versus the employees who are working on the implementation itself. People like developers, functional analysts, testers. Putting it differently, there are two detached points of view: the big initiatives and the high level plans based on a multiannual time scale versus the day to day activities of each employee. These two views should by no means be opposing or contradicting each other and solving the differences between the two sides should be reasonably achievable.
Even though Agile development, in various flavors, has been around for more than 20 years now and we also had Toyota Production Systems, Lean, “Just in time” production system and so on before that, it still looks like we are struggling when trying to align and build large systems and solutions inside big organizations consisting of hundreds or thousands of people.
Reconciling the two perspectives and fixing the problems with large organizations should be the main purposes of any framework trying to scale the Agile principles, values and processes from the team level to the level of the whole organization and this is definitely a part of the mission of the Scaled Agile Framework (SAFe) as well.
A short intro on SAFe
SAFe manages to bring a good compromise because with almost everything that it defines, it allows for everyone to participate with inputs in making decisions, creating the emergent design, architecture and identifying improvements. These can be promoted and industrialized if they make sense at the larger scale of the organization. In other words, this is a bottom-up approach to encouraging innovation in general.
The framework also provides the means to define the framework for the decision making process, guidelines to be used and followed in all areas and the processes and tools for the governance needed to close the loop and measure the benefits. All this emphasizes a top-down approach on general guidance and strategy.
The SAFe framework has been around since 2011 and it is the most widely adopted scaling agile framework, with 30% of the implementations of such a framework to be more precise. It has a strong and active community of practitioners and adopters and seems to be the most appealing agile framework to managers and executives as well.
It provides 4 configurations which can be used to cover the needs of various organizations starting from the implementation of small products on which 50-150 people can work on, up to the needs of a company having a portfolio of very large solutions or services and tens of thousands of employees.
Everything there is to know about it can be found on the official framework platform which can be found here
. So the rest of the article will consist of a series of examples of situations or problems which can be addressed by taking into consideration the principles and practices defined in SAFe, highlighting the real benefits and, at the end, a list of available trainings from our catalog.
Interested in adopting SAFe in your organization? Check out our SAFe training portfolio
Certified SAFe® Program Consultant (SPC4)