Agile for Decision Makers
Information for decision-makers considering large consultancy firms’ Agile offering
Curated review of large consultancy firms’ offering of Agile services, to help decision-makers make informed choices and get better results
Read this Agile for Decision Makers Guide here
Easily readable and searchable on any device.
Download this Agile for Decision Makers Guide as a PDF
This is a living document that is updated daily. The PDF contains the most up-to-date information and links to all of the quotes and information represented here.
A message for large consultancy firms and their consultants
Many of those working in large consultancy firms are friends, respected Agile practitioners, and competent Agile professionals trying to improve things from the inside. And then there are many graduates and junior consultants starting their careers with energy, passion, and a strong will to do well. The content of this document is not intended as a reflection of their talent and professionalism but as a reflection of the solutions adopted and sold by the large consultancy firms.
The large consultancy firms are all invited to adopt Agile to run the consultancy firm at all levels:
<< Some things can’t be told. You live them or you don’t. But they can’t be told. >>
They are also invited to engage with the Agile community and are encouraged to act on the parts of the feedback that are constructive and useful, in order to accommodate the desire for the improvements needed by their clients and the practitioners.
Now that Agile passed the early adopter stage, there are many companies interested in adopting it. Yet those companies without extensive Agile experience have a hard time evaluating what will bring them value and what not. Many of the larger companies look at large consultancy firms and their solutions for scaling Agile and for Agile Transformations, and they don’t know if they can trust those or not. In this document members of the Agile community are collecting and analysing available information. Some of these practitioners have been there, know how things started, how things went, and how they pan out with what results.
Agile Software Development has started as a bottom-up movement coming from practitioners for practitioners working in professional software development.
In a moment when medium-large IT projects had more chances to fail than to succeed, a fundamental shift in the basic assumptions on how to approach professional software development had turned the tide with a streak of repeated successes that brought Agile Software Development from a fringe movement into the mainstream.
During this period of time, a few small-medium size consulting firms in the tech sector adopted Agile Software Development as a means to succeed in their own mission of helping customers with challenging IT projects, as well as a way to run their own company.
One such consulting company worth mentioning is ThoughtWorks, which pioneered Agile Software Development, hired some of the authors of the Agile Manifesto, and made a reputation for themself for their rate of success with innovative and challenging IT projects. Another one is Crisp.se from Sweden. Another one is Equal Experts.
With many products and services gradually becoming digital, software development started to be ubiquitous. At the same time the accelerating rate of change and innovation, the unknowns and uncertainties that challenged professional software development from the advent of the Internet, started to become commonplace also for all types of organisations beyond tech and IT. This has been the start of the age that some may call the Information or Knowledge or Interconnectivity Age. That is when Agile values, principles and techniques started to inspire larger enterprises and companies both from within and outside the Tech sector.
All this created a rapid expansion in the demand for Agile consulting services from companies willing to learn this new way of working, and it consequently created a rapid expansion of the Agile services market, at the same time when the traditional management consulting market was declining.
This led several large traditional management consulting companies to rush their entry into the Agile services market without previous understanding or experience in Agile Software Development, or in adopting Agile to run their own company, and without direct experience or alignment with the fundamental shift in the basic assumptions on how modern organisations work. To make things harder, the business model of large consultancy firms relies on the margins made on junior consultants. So the large consultancy companies adopted solutions that their junior consultants could implement at the client site, and that resulted in simplistic solutions with the same limitations as the pre-Agile approaches and unfit for the complexity of modern organisations.
In an opportunistic move dictated by the contraction of the traditional management consulting market, several large management consulting companies entered the rapidly expanding Agile service market without any previous knowledge, understanding, or experience and ultimately without sufficient competence in Agile. And they equipped their junior consultants with simplistic solutions that perpetuate exactly the same limitation Agile is intended to overcome.
Agile solutions from large consultancy firms
When large consultancy firms entered the Agile service market as new players, they resorted to one of these strategies to quickly shape a catalogue of offers to scale Agile and for Agile transformations for their potential customers, and to equip their junior consultants with solutions they would be able to implement at the client site:
The Swiss army knife strategy
They adopted one of the commercial heavyweight scaled frameworks, typically SAFe, that allegedly contains the answer for all foreseeable needs
The extended Swiss army knife strategy
They extended one of the commercial heavy-weight frameworks, typically SAFe, for a specific industry, making it even bigger and heavier.
The cut and paste strategy
They adopted one of the freely available models such as the Spotify model, which was never intended to be copied and reused. On the contrary, the actual learning from the Spotify model is not the model itself that is a snapshot in time of a moving target, but the journey that led to the emergence of a model that at any time perfectly fits the specific context and circumstances of Spotify, and that continues to change and evolve together with their context and circumstances.
The made-up solution strategy
They created a new solution applying the traditional approaches they are comfortable with, while adding the Agile terminology and new ideas from various sources, typically misunderstanding and misrepresenting those ideas. And then integrating everything together.
These solutions so shaped consist of canned solutions and standard recipes to be offered to every client as a proven solution.
Whereas Agile is based on an empirical approach that consists in starting from a small and intentionally incomplete starting point in order to gradually experiment, learn, adapt and evolve an approach that fits the different and changing context and circumstances of every individual team, department, and organisation.
None of the solutions created by the large consultancy firms that have no good knowledge, understanding and experience of Agile, have been vetted by members of the Agile community, peer-reviewed and validated, and they don’t have any verifiable history of successes. Whereas the approach in the Agile community is to share and peer-review any new idea and contribution to the community in order to validate the idea, in a way that is very similar to the one used also by the Open-Source movement.
To implement those solutions on the client side, the large consultancy companies resorted to:
- their junior consultants after they had undergone a 2-day certification class;
- SAFe certified professionals, often those less experienced in Agile and more willing to apply the framework by the book;
- or charging the client for a very expensive plan and PowerPoint presentations, for then leaving to the client the responsibility of the execution of their plan.
Conclusion
Large consultancy firms that entered the Agile service market created an offering of solutions for scaling Agile and for Agile Transformations that ultimately consist in 1-size-fits-all canned solutions and standard recipes that are polar opposites of good Agile and that don’t have any verifiable proof of working well other than marketing material.
Evidence of the lack of Agile competence of large consultancy firms
In order to promote their presence in the Agile service market, large consultancy companies started to produce and publish their offering and Agile-related content for potential clients (listed in Appendix 1).
Most of that content has been produced or edited by their Sr. employees without much Agile experience. And while at first superficial look some of the content may seem ok because it copies and imitates some original Agile content, after reading it carefully a series of beginner’s mistakes become evident.
Those mistakes demonstrate a lack of understanding, knowledge, and experience with Agile, a lack of engagement with the Agile community and a lack of attention to its feedback.
McKinsey & Company
In terms of publications that demonstrate a fundamental lack of understanding of even the most basic aspects of Agile, McKinsey is definitely a top performer.
In several of the articles analysed, there is a use of the language, the terminology, and the rhetoric commonly adopted from genuine Agile content, but those terms are used in the wrong context and with the wrong meaning on what it seems a cheap imitation of counterfeit goods.
One of the articles presents the made-up concept of Agile pools where a pool of identical replaceable generalist resources are dynamically moved around to work on new incoming tasks. Whereas Agile instead pursues productivity with longstanding teams with stably dedicated team members, that are T-shaped in the sense that they are specialists and to some extent also generalists, and where the work moves to the teams and not the other way around.
None of the alleged authors of the article has previous experience with Agile.
Another article imitates the language of networked organisations, self-organisation in teams, and empirical approaches to work, while in the substance the article describes up-front planning, top-down management, and predefined processes. Again, none of the alleged authors of the article has previous experience with Agile.
In another article there is the made-up concept of an Agile Manager, the article imitates the language of the Spotify model but in the context of traditional top-down management.
Again the alleged author has no previous experience with Agile.
Going back a few years in 2011 in the tech and IT space, reacting to the rising popularity of Agile Software Development, McKinsey was the proponent of another made-up idea they named “Two Speed IT.” A few years later after a series of repeated failures the Forbes magazine, Boston Consulting Group as a former proponent of such an approach, and Martin Fowler who is one of the authors of the Agile Manifesto, all rebuked that practice as fundamentally flawed.
The article is still available today in McKinsey as a suggested solution for their clients.
Again the alleged authors have no previous experience with Agile Software Development.
McKinsey tends to sell very expensive plans for scaling Agile and Agile transformations to their clients while they often leave the burden of the execution to their clients.
Please note that Agile transcends the duality and separation of planning and execution because in Agile the two activities are inextricably intertwined, progressing in parallel in a process of gradual refinements.
As several practitioners reported, several McKinsey clients tend to leave behind the plan bought from McKinsey when they start to experience the consequences of the fundamental flaws. Regardless, McKinsey clients don’t usually speak publicly about their negative experience with a McKinsey “Agile Transformation.” Maybe because of the amount of money spent. But when asked personally they are open to admitting they have abandoned the recipes sold by McKinsey because they did not work. Given the propensity of McKinsey to make up Agile terminology, it is possible sometimes to spot some clients that went through a McKinsey “Agile Transformation” because of some of the terms that are still lying around, beyond the obvious Two Speed IT, and Agile Pools you can look for: North Star, Playbook, NWOW, CoE, Maturity Assessment, …
In conclusion McKinsey & Company has a track record of made-up Agile concepts and Agile terminology imitation that actually loop back to old traditional ways of doing things.
The alleged authors of their content lack understanding, knowledge and experience of Agile.
The content has not been shared and discussed at any Agile conference, meetup, or in any collaboration with the Agile community. Everything points to a lack of expertise in Agile.
Gartner
Gartner's presence in the Agile space is limited compared for example to McKinsey, but they have a unique talent for getting things wrong.
Around 2010, reacting to the rising popularity of Agile Software Development, Gartner suggested the idea of Bimodal IT that is very similar to McKinsey’s “Two Speed IT.” And sharing the same flaws it has been equally unsuccessful. A few years later Forbes, Jez Humble author of Continuous Delivery and Accelerate, and Martin Fowler that is one of the authors of the Agile Manifesto, rebuked that practice as fundamentally flawed.
In 2016 Gartner published an article that suggests a way to combine Design Thinking, Lean Startup, and Agile. The diagram that imitates Agile diagrams has a certain success spreading beyond Gartner’s clients, and leads to a few derivative variations. But a non-superficial reading immediately reveals the fundamental flaw: the three approaches are combined in a way that resembles a Waterfall linear gated process instead of an Agile approach.
In December 2021 Gartner gave it another go mapping the skills for Agile developers, failing to map correctly the core skills versus other valuable but secondary skills and including irrelevant or detrimental skills.
All these flawed insights that Gartner shared with their clients still today are available for their clients.
In conclusion, Gartner has a track record of demonstrating a fundamental misunderstanding of Agile Software Development, and an inability to learn and correct their mistakes.
Accenture
Accenture is not only a management consulting company but also a technical consulting company where their software development teams do not adopt Agile Software Development by default and are not known for mastering Agile either.
Accenture as a technical consulting company is not renewed for delivering IT projects on time, for their technical excellence, for their ability to succeed in challenging IT projects, or for mastering Agile Software Development as a means to their own success.
While the management consulting branch of Accenture provides solutions for Agile Transformations based on SAFe with all the well-known flaws, limitations and problems that SAFe brings (see https://safedelusion.com).
Accenture also created an extension of the already overcomplicated and heavyweight SAFe framework for the Automotive industry, calling it AutoScrum, which the Agile community has strongly criticised for its flaws.
In some of their publications, they show a superficial understanding of Agile in the form of an iterative process applied to a traditional linear process consisting of a linear sequence of stages. This approach completely misses the empirical nature of Agile which is one of the key elements that make Agile succeed where the previous approaches have failed.
The alleged authors of the articles and solutions offered by Accenture don’t seem to have previous experience with Agile.
Deloitte
Deloitte has been very active in terms of Agile offering in the space of scaling Agile and Agile Transformation.
In terms of publication of content Deloitte started off on the wrong foot by extending a graphical representation of the Agile practices by making it over-complicated while the relationship between the practices is oversimplified, and the separation of the practices between strategy, planning, development and delivery while typical in traditional approaches is the polar opposite of Agile.
Typical Deloitte's offering for Agile Transformations consists of internal made-up solutions each defined like a traditional process consisting of a linear sequence of stages. Additional articles that detail the approach reveal common misunderstandings around Agile that are expected from a beginner. For example in an article the Bimodal IT is described as a valid stepstone to Agile when the model is well known to have failed multiple times without bringing any organisation closer to Agile. None of the alleged authors of the solutions and the articles has previous experience with Agile.
For scaling Agile Deloitte resorts to offering solutions based on SAFe with all the well-known flaws, limitations and problems that SAFe brings (see https://safedelusion.com).
In conclusion, Deloitte has repeatedly made beginner mistakes and resorted to flawed approaches.
KPMG
Agile promotional material and content from KPMG replicate some of the high-level introductory content largely available from the Agile community. By doing so KPMG demonstrates the ability to identify the right content to be reproduced in their own material.
Then as soon as they start pitching their approach to an Agile Transformation they fall into the classic beginner’s mistakes:
- they focus on a target operating model as an end state defined upfront, whereas in Agile it emerges and evolves gradually while doing the work, and continue to evolve along the changing context and circumstances;
- they misrepresent the Agile adoption journey with a linear path with predefined stages of progress;
- they pitch concepts like Agile Centre of Excellence where in Agile excellence is achieved through a distributed community;
- they focus on planning practices where Agile focus first on the opposite end of the stick, on delivering outcomes early and often and from that learning, adapting and steering;
- and finally for their Agile Transformation offering they resort to SAFe with all the well-known flaws, limitations and problems that SAFe brings (see https://safedelusion.com).
As for the other large consulting companies, no one of the alleged authors of the solutions and the articles published has previous experience with Agile.
In conclusion, KPMG stands out compared to the other large consultancy firms for the ability to copy the right high-level content from the Agile community, while falling into the beginner’s mistakes in their offering.
Boston Consulting Group
Compared to the other large consultancy companies’ beginner mistakes, BCG makes mistakes that are common for an intermediate learner. While they still show a lack of expertise that is needed to offer professional services to their clients in the Agile space.
The solution BCG is usually offering for Agile transformations is a copy-past of the Spotify model that was never intended to be a model to be copied but a high-level snapshot of what Spotify looked like at one point in time during its journey to gradually grow and evolve something that was a good fit for their own context and circumstances at the time, something very personal that is expected to continuously evolve and adapt. So this is the first mistake.
While in other publications BCG reveals other mistakes in their thinking about Agile, for example with concepts like
- end-state target operating models, where in Agile there is a status of continuous improvement;
- north star, as an upfront defined solution, whereas in Agile a good solution is discovered gradually while the work unfolds and doing it reveals the direction of movement;
- traditional processes consisting in a linear sequence of stages.
While these may seem minor details, they reveal a lack of understanding of the empirical nature of Agile which is one of the key elements that make Agile succeed where the previous approaches have failed.
Like for the other large consulting companies, no one of the alleged authors of the solutions and the articles has previous experience with Agile.
In conclusion, while BCG stands out compared to the other large consultancy firms offering Agile services, the level is far below the level of expertise required for the job at hand.
The offering of these large consultancy firms, coming from a position of authority derived from their brand and history, actually reveal their lack of competence in Agile and their lack of understanding of the key innovative elements of Agile.
Selling their Agile solutions with well-known serious flaws is irresponsible both to their clients, the Agile practitioners and more in general the whole Agile community.
The demonstrated inability to react and adapt to the criticisms and to the failures of their canned solutions and standard recipes, the failure to engage with the Agile community to learn and to contribute, and the failure to empower the experienced Agile practitioners among their employees, demonstrate their inability to adopt, practice and be Agile, and leave Agile experts wondering how can they help other organisation Agile journey when they cannot help their own.
While there is widespread public criticism of the flaws in the Agile offering of large consultancy firms, clients that failed to adopt a solution from one of those consulting firms are less prone to share their stories publicly. While it is becoming more common for Agile practitioners and professionals to work with clients that are trying to recover from a previous failure with one of those consultancy firms.
More in general, more organisations are asking for genuine Agile professionals that are framework agnostic, and that have a real understanding and hands-on experience of good Agile.
On a less positive note, smaller or newly formed small consultancy firms without any Agile experience are trying to emulate these large consultancy firms in order to enter the market of Agile services. The number of smaller consultancy firms trying to do that has raised so much leading to an offering of services to fake Agile expertise:
- Offers to become an expert in a weekend by getting certified with a 100% guarantee of passing the test
- Fake or unknown Agile conferences where speakers have to pay to speak, so that they can pose as experts in their cv
- Ghost writing of Agile content for the company blog
- Genuine Agile practitioners approached by individuals asking or offering money to link or like or endorse questionable low-quality content.
Agile is not something that can be bought in a box and installed.
Neither is it something that can be implemented inside a project or a programme with a discrete start date and end date and a predefined scope.
More than a sprint or even a marathon, adopting Agile in an organisation is more similar to running, an ongoing journey with many starting points, like many waves that at some point come together to form a bigger wave that turns the tide.
Find in Appendix 2 some examples of large companies that successfully developed Agility at scale with tangible and lasting benefits, and other ways to succeed with Agile.
Like any transformational process, adopting Agile cannot be outsourced or delegated, but is a journey that must be owned by the organisation itself, and all the missteps and mistakes are a necessary part of the development the organisation needs to go through to learn the necessary skills and develop its Agility. Authentic and experienced Agile practitioners can help an organisation by providing some guidance, avoiding fatal mistakes, and helping the journey like a steward or a sherpa.
How to recognise genuine Agile consultancy firms
These below are a few characteristics that you can look for to recognise the consultancy. firms that have real expertise in Agile. A genuine Agile consultancy firm usually:
- employ Agile to run their own consultancy at all levels (they do not just sell “Agile” to their clients)
- employ Agile to be successful in what they do for their clients, and they excel in it (if for example, they work in tech they should be known for their technical excellence and ability to deliver successfully even challenging projects)
- has a people-first approach with their employees, their employees at all levels are visible, they are empowered and trusted to make important decisions
- with their clients uses Agile contracts that support collaboration and leave the flexibility to adapt the details as the work progress, for example to change the scope
- has many leadership members and many employees that are genuine Agile practitioners (see below)
- is not affiliated with any particular framework or methodology or any particular certification body, instead, they are innovators and adopt ideas and practices from multiple sources
- is engaged with the Agile community, share content with the community and is receptive to feedback and suggestions for improvements
How to recognise genuine Agile practitioners
A genuine experienced Agile practitioner usually:
- participate in the Agile/Lean community (in the online social networks, meetups, conferences, etc.)
- has contributed to the Agile/Lean community including in open initiatives aimed at collectively uncovering better ways of working by doing it and helping others do it; and by doing so the contributions have been reviewed and validated by peers
- has been inspired and influenced by thought leaders of the field and widely respected community members that personally or indirectly contributed to their intellectual journey, its start, its path forward, up until now in their current landscape
- has 10+ years of experience as a hands-on Agile/Lean practitioner (one to become an expert has to successfully deliver multiple times and excel with Agile/Lean in a variety of different teams, organisations and contexts)
- has experienced good Agile multiple times, in places renowned for their Agile/Lean mastery and high levels of Agility
- has personal characteristics such as being a team-player, empathic, is comfortable with uncertainty, ambiguity and lack of control, is non-directive, non-judgmental, and non-defensive, is flexible and resilient.