Silver bullet thinking. It’s the notion that if you only do “this one thing right here!” all of your problems will disappear. Sounds wonderful, doesn’t it? Except that reality is way more complex than that!
If you look around, you see this silver bullet thinking all over. It happens in politics (Free college for everyone! Tariffs will fix trade and border problems!). It happens in management consulting (outsourcing, performance management, megatrend orientation). It happens in organization process design (management playbooks, matrix organization). And it happens in software methods and processes (just pick anything!). It even happens in our personal lives (Oh – this job/house/person/diet will change everything!!) It’s the human thing to do!
See, we humans like certainty. It’s how we got here. When you are on the Serengeti and a lion is staring you down, it is good to be certain that you are not the slowest runner! And act on that certainty! So we naturally like to latch onto notions that seem to promise much but cost little by comparison.
Which brings us to Agile Frameworks. Every agile guru has one, it seems! For the most part, each is a specific methodology that fulfills on the Agile Manifesto (for software development) or on basic lean-agile principles (for other business functions and organizations in general). There is no doubt that each of these (including the major ones such as Scrum, Kanban, SAFe, LeSS, Scrum@Scale, DA and DAD, etc) solves certain problems very well.
For example, scrum is the go to approach for start up and medium sized software development efforts while Kanban often works best for support, portfolio, marketing and other highly dynamic efforts that are engaged directly with customers. SAFe, LeSS, et. al. promote agile scalability in larger software and related projects that include many dependencies within enterprises. And just to make it even more interesting, there are as many opinions on all of these as there are practitioners.
So, of course, I have mine! I tend to see all of these methods and frameworks as sets of tools and ideas that can be mixed and matched as appropriate to each team, organization and its culture and objectives. In this way, the business value of agile, specific to each organization, is the guiding vision. The choice of agile methods – whether consistent or eclectic – is just the means to that measurable end.
That is not how others see it, however. Many purveyors of agile transformation – especially for large enterprises – espouse SAFe (Scaled Agile Framework) or DA (Disciplined Agile) or some variant of their own. There is no doubt in my mind that there is value in these frameworks. But when applied in existing hierarchical enterprises, any of these frameworks when taken literally can lead to some unexpected outcomes.
Firstly, there is something just plain paradoxical about taking agile and implementing it on an entire enterprise basis all at once! The essence of agile is to start small to produce the minimum most valuable result that can provide feedback from customers and stakeholders. Adapt to get that right. Add on. Repeat, grow and repeat. This is essentially a bottom up approach that relies on small teams, trust, learning, collaboration and adaptation. Unsaid is that the culture of such smaller efforts are already primed for agile success because they are based on networks of relationships and not hierarchy!
Meanwhile, as any traditional executive team will tell you, enterprise transformation starts at the top. The adoption of an enterprise oriented agile framework and migration will initially fit right into the command and control culture that likely exists, creating a barrier for true agile transformation. The culture is just not ready for the trust, collaboration, openness and adaptation that agile requires. And adopting a framework alone does not create that culture change!
We know that culture change is the hardest thing for both executives and large organizations to accomplish. And that is why so many agile enterprise transformations seem to stumble. Steve Denning, in his article on fake agile, illuminates many of the possible pseudo agile outcomes that result from this agile enterprise adoption paradox.
In the spirit of being agile, let’s keep things simple. To be agile we need a prioritized backlog of valuable things to do, small teams to accomplish those in quick increments, each of which obtains active feedback from customers and stakeholders. In Steve Denning’s language of agile, these encompass the law of the customer and the law of the small team.
But Mr. Denning has a third law in pursuit of being agile: the law of the network. And this is the reason I am pragmatic on method and frameworks. Anything that can be used to eliminate bureaucracy, overhead, waste, waiting, etc. (being lean, in other words) is an ongoing aspect of being agile and getting better at it. The network replaces hierarchy. And that network is the essence of cultural change as well. We want small team collaboration and communication to make hierarchy irrelevant so that the most valuable information and results get where they are needed the fastest and we can easily adapt to changing circumstances.
That’s the agile way. The last thing we want is to adopt unthinkingly a framework in its entirety that puts those complexities back into our organizations just because it does!
So stay pragmatic and be agile!