The context of this map is the adoption of different organizational models in the software industry, by enterprises that decide to build instead of buying.
When this shift happens they have to build their capabilities, and the way they organize the software construction is one of them.
You can say:
“you should have written this 5 -7 years ago, now it’s late”,
and you are right, but believe or not, the are so many organizations doing “digital transformations” that still can find this valuable (at least I hope it does).
Background
There’s a moment where organizations decide if they buy or build some of their software capabilities. These decisions are present during the last 30 years and the volume of decisions in one or other move like a pendulum.
The move of the pendulum started adding software as a secondary capability and right now software is in the core of millions of organizations.
In parallel the software industry inherited some of the engineering practices related to the way of organizing the work, and starting from there, they have evolved.
The disconnection between software teams and management
The classic start point is the delivery of software using waterfall methods. And agile manifesto (2001) kicked the evolution of software construction in terms of organization. Scrum is one of the more adopted ways of building software, and despite the fact there are others ways of building software I will simplify just adding this (sorry!).
The point is that enterprises are organized with yearly budget cycles, quarterly/yearly bonus incentives and many other constrains that hit with that “agile” way of performing. This provoked a disconnection between the software teams and the management that in some cases was resolved quickly, and in other cases it has stayed there for years.
This initial map tries to represent this situation:
The typical issues are: a software team that delivers at better speed and quality than the classical waterfall approach of building software, but that is constrained in an organization which cycle pace is completely different, the communications between parties are complicated and the adoption of the new nomenclature, processes and ways of delivery is poorly understood by management.
The birth of frameworks on top of scrum, XP, RAD and other methodologies
Scrum consolidated its position as one of the right ways to build software, the raise of the product owner gained importance but the coordination of different scrum initiatives was a problem. In so many organizations the product owner has been a settler, working with both sides of the organizations technical roles (the pioneers) and management (town planners).
Note: in organizations where management are the pioneers the speed of adoption is completely different and this map does really not apply.
Between 2007-2015 and with the purpose of organizing the scrum teams in a better way, different forms of organization started to appear: SAFE (scaled agile framework), LESS (large scale scrum), DAD (Disciplined Agile Delivery).
LESS is the preferred framework for the people that believe in agile manifesto, and it has been adopted in too many small organizations that have the flexibility to adopt it. The point is that in large organization, with different reporting layers the disconnection still exist.
LESS and SAFE (I will focus on these 2) come from different ways of understanding the world and have evolved in different ways. You can find in your favorite search engine thousand of articles highlighting pros/cons of both methodologies. I like this one.
Focusing on large enterprises, SAFE has gained more traction, as it connects better with the traditional way or organization. Is that bad? I think it is not. I think it’s a necessary evil that is enabling large enterprises to evolve from waterfall approach to a more agile way of organization.
Probably in the long term, LESS is the best suitable once the practices have co-evolved in the management side of the organizations, but who knows?
Then, here the future can evolve in many different ways,
Scaled Agile Framework adoption
I would like to detect the adoption curve related to the adoption of “scaled agile framework” during the last years. I will try to do a simple exercise using Google trends.
Other notes:
- Waterfall will exist in the organizations as they are required by different reasons, but the trend is that will decrease its presence.
- I have ignored the concrete prevalent doctrines in each organization, and doctrines are always first. The adoption of these frameworks have come because there is an evolution in the management and leadership teams recognizing that they have to evolve.
- Large companies transitioning to SAFE are laggard.
- There are other forms of agility in organizations more evolved than these ones.
All maps are wrong, but some are useful, so as usual, any feedback is welcome!!
WordPress
Google + 
Facebook