7 things wrong with Deloitte’s Agile Tube Map
And why it’s just like the real thing
In case you haven’t seen it, the above image is Deloitte’s agile map. You’ll note it is on version 3 as more and more practices have made it’s way into their consciousness. There is an associated blog post illustrating how Deloitte came up with this model and I’d encourage you to read it in the interests of fairness, before reading my 7 click-bait reasons why it’s wrong. It’s OK, I’ll wait.
1. Agile Practice is not that Discrete
The map links particular practices to each other by a hard link. Not just that, but the hard link is almost arbitrary!
Agile practices tend to be mongrels in real life. They borrow inherent characteristics from other tools and techniques, yet at the same time, many practitioners seem to categorise these under particular schools of thought. In any event, it is not always required to go through related concepts to get to the appropriate technique.
Let’s take a particularly simple example. Regardless of whether you use Scrum, Kanban or XP you almost certainly employ some level of Test Driven Development (TDD). Yet, none of those methods prescribe it and indeed, it is not prescribed precisely because there are arguably situations, where “test-after” is the only way to do it (smell? no smell? For another day).
Another particularly apt example is the discrete stop for Information Radiators which is totally separate from Kanban. Whilst they are of course, not the same thing, part of Kanban is information flows “right to left”, deliverables flow “left to right”. Visualising that information is crucial to exposing invisible work. Ensuring work you seem to be paying for but can’t see the output of, is shown.
2. Separation of Strategy/Management from Delivery
This one is precisely what is wrong with the Bimodal system Gartner sells. The dotted lines give license to viewers to mentally separate the ideas behind strategy/management and delivery, which in most waterfall organisations currently sits in the hands of dedicated job descriptions (think middle management and above) who are already reluctant to relinquish control.
Deloitte’s position, and those of others selling similar services through such collateral, presents completely the wrong message to disseminate to organisations seeking to become productive, agile organisations. Deloitte, like most large consultancies delivering similar messages from positions of much less experience, are utterly irresponsible, both to their clients, and the agile community in this regard!
One of the core tenets that evolved from the Agile Manifesto is everyone, all together, from the start. As soon as you separate out the roles of Management and Strategy from Delivery, you provide license for those in higher positions to kick back at developers by dictate. This is most dangerous to fledgling, immature agile organisations as agility simply does not have the cultural space to take hold in those contexts. Companies no longer with us, learned that lesson the hard way.
3. Ghost Stops
The map has a couple of empty stops and unconnected links, which again are not correctly positioned in any event. Why are we stopping there? Do we stop there? Does this highlight a lack of QA (and thus maturity) in the production of collateral?
4. Duplication
Why is it that a number of these conceptually identical practices, are repeated? TDD is a practice to be employed. Not the foundation of an entirely new method or principle per se. It fits more with an inherited characteristic. Is this a deliberate or accidental attempt to make this more complex than it actually is? It reads like a recruitment agency job specification.
5. Ambivalent Message
The map combines a number of different things. Some programming concepts, some working practices, some methods, some tools (ORM? Mock Objects?). None of which works in isolation. At the same time, none of them are prescribed nor essential if equivalent “coverage” exists elsewhere. The message is fragmented and incoherent. Like the twitter misunderstandings have independently proven.
Who is this map aimed at? Is it developers? Managers? Why do managers need to know what Mock objects or ORM’s are? Are we referencing practices? Why is there no overlap between Cynefin and many of the other practices within the map? It doesn’t stand by itself.
6. Missing Practices
The map is missing some of the most important and transformative ideas in the agile space. No reference at all to Lean-Startup, #NoProjects, Mob Programming and as much as I don’t like where it has gone, #NoEstimates.
This, to me, is probably the most embarrassing omission in the map. These have been around for years! Many are having marked effects in large companies as we speak, with high functioning teams inside them choosing to operate these methods and having the necessary space to do them. This map isn’t needed for them, granted, yet at the same time, the map should encompass and include these practices. Both to stimulate conversions and questions, as well as show any overlap.
7. Quick Succession Updates
This one is slightly more forgivable, since the map itself is evolving as Deloitte get accustomed to the techniques that are out there. There have been 2 versions prior to this.
Deloitte’s researchers are using the internet by asking the wrong question and harvesting the results. If they want to use articles like this or other more eminent members of the community as feedback, that’s fine. That’s what it’s there for (credit though) as they are likely to do a lot of damage if they are not aware of either the community’s breadth of approach or their own limitations.
Conclusion
How about we simplify all that map to these 4 stops:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That’s a bit easier. Granted it doesn’t sell as well if you need to make money out of exposing and fixing complexity, but that complexity only exists because of the way companies have attempted to subvert systemic simplicity, often by [rewarding] local optimisation (“I do my bit as best I can, they do theirs”) and not identifying their role in creating systemic complexity in the first place.
To me, this map exposes a total lack of understanding of agile practice and illustrates the firm’s own struggle for maturity. At best, it will give companies and execs a start, but certainly will not get them close to an endgame nor the ability to choose a partner from that endgame. Indeed, the level of conceptual duplication in the map shows the collation is focused on the words, not the values, principles and practices themselves.
Sadly, it is common practice for traditional consultancies to defend their collateral to the hilt and politically highlight themselves as some form of authority when they are constantly playing catch-up to the bleeding edge.
Agility is still a fledgling service in large consultancies and often, organisations in general. Their customers are competing with organisations that already run with very solid agile practises. The Amazon’s, the Facebook’s, the Google’s, the ThoughtWorks, the JustEat’s, the MoneySupermaket’s. Many older companies only just adopting practices most of us take for granted. We, who have been using the practises; who have lived and breathed the values since their inception; who have worked with it day in, day out, possess freedom to truly live agile principles and indeed, breathe it outside our work. This isn’t encouraged in the vast majority of staid consultancies and indeed, are clamped down on in some cases. If you are thinking you need a Deloitte, a PwC, or even a Gartner, you’re almost certain to have made the wrong choice.
It’s rare for large consultancies to drive innovation in their own right but once a practice starts to become mainstream, there is suddenly huge interest in it. This is great for smaller, boutique consultancies since they can live under the radar for years, taking first mover advantage. Yet, large consultancy brand following and loyalty often allows bad ideas to propagate and drown out sensible practice for far too long. To cause damage for far too long. Putting off the most in need. Right when customers need proper support, at a crucial time at the beginning of their journey.
Customers appoint large, often staid consultancies on brand, to drive that change at scale, which is the first mistake they make. Just like any other human, if you suffer the consequences of a bad experience, you are likely to be put off integrating it and revisiting it.
As someone embedded in the community for well over a decade and a half, I can tell you the community itself is not all that fragmented. The overlaps in practice are huge! Every school or community respects the above 4 values of the agile manifesto. Sure, there are different schools and different community groups. However, they exist in a primordial soup that melds every aspect of agile DNA into a working practice that benefits organisations in their environment. Every one is unique.
In order to be successful in any form or level of agility, one has to build a repertoire of methods and be prepared to call upon any tools or techniques that exist, on-demand. Regardless of its previous contextual application. The right tool, for the right job, in the right way at just the right time.
The essence of agility and especially lean, is simplicity. Remove the unnecessary, wasteful moving parts that also increase risk and the value of the investment at risk. This map does anything but!
E
Ethar is a Lean-EA and director of Axelisys. He works to make organisations more productive and has been involved in the agile space since 2002. If you found this article useful, clap and share.
