top of page

Stop doing Agile! 9 words you must be comfortable with before pursuing agility.

There has been tremendous chatter in recent years about Agile. For a family of methods that has been seen as the “Hippie” approach for a couple of decades, nowadays, the heresy is proclaimed when we do not get behind discussions of a shift to Agile – go figure!

While somewhat a success for proponents of Agile (tipping point re broader acceptance seems to have been reached) from my observations throughout this tipping point era, I’d suggest some concerns require airing before the Standish Group start reporting failure rate equivalent to waterfall projects for Agile initiatives.

These concerns are born out of a fear that we’re really not doing agile well and faith may be lost if we don’t have a more considered approach/stop Agile adoption falling foul of some of the very things Agile promotes. We may actually have a case of the blind leading the blind.

Areas of concern:

  1. We’re talking about it, but no-one really knows what Agile is.

  2. Just about all of the time, Agile = Scrum and seems to predominantly focus on the team execution level. What about all the stuff that happens before a 4-9 person teams gets to work? How do we scale Agile to be a viable enterprise operating model or “system”?

  3. Business and IT. Agile was spawned in the software development/software engineering domain. It is applicable in non IT centric situations. Why isn’t this talked about/practiced more?

Oh, and the title does talk to “9 words” so in the spirit of alluding to the answer up front, here are nine words (not definitive, there are others but this provides a digestible set based on common observation) to consider.

- Definition

- Goals

- Expectation

- Mindset

- Trust

- Accountability

- Capabilities

- Experimentation

- Talent (People)

Finally, again with the end in mind and having a respect for people’s time, here are some precision questions we may wish to consider before jumping upon the Agile bandwagon:

  1. Why do we need to adopt Agile? (drivers/rationale/goals/objectives)

  2. What, precisely, do we mean by/is Agile? (definition/ understanding/ alignment/ commitment/ governance)?

  3. How will adopting some aspects of Agile impact us? (readiness/ change management/ culture/ operating model/ working practices / working with non-agile partners, suppliers, vendors and performance in and post transition)

  4. What does the journey look like? (planning/ understanding of time, cost, risk, resource and other “expectations” and touches on performance indicators, definition of “good” and “finished”)

  5. How do we adopt or leverage proven Agile aspects? (scope/ capability development required/ roadmaps/ sequence and pacing/ measures of progress and success/ review)


I was part of a group of circa 20 “experts” that were contributory authors/reviewers selected from around the globe for the PRINCE2 Agile manual published June 2015. I recall one of my first interactions was by way of a question (if you hadn’t guessed it yet, asking good questions is a key skill!). It went something like “Team, so we’re all coming up with great ideas re content etc. but can we start at the beginning. How do we [20) as a collective define Agile”?

There was a bit of a pause. Then came the sobering response – “that seems like a good idea”. No kidding…

Long story short, we came up with (not straight away!) a definition centered on the “Behaviors, principles, practices, techniques and processes” that would enable agility. I’d also suggest that the Agile manifesto is alive and well and summed up here (one word changed to make it non-IT centric):

Individuals and interactions over processes and tools

Working solutions over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

It is incumbent upon me to state the key part of these four statement (as this often gets missed/overlooked). It’s not that we don’t value the things on the right, its just that we value the thins on the left more. So please do translate this as “if the things on the right are important/should be done, then do them!”

And while we’re getting clear on some basic premises, I should explain that Agile ≠ Scrum. Nothing wrong with Scrum, lots of value there, all good, but there is more to Agile than Scrum and the vast majority do not understand this, forget or never consider this. This is a major issue.

Goals & Expectation:

Before rushing off, getting the seemingly mandatory few roles certified with training and then, invariably, starting to apply Scrum, abandoning the need to document and assuring executives that Agile is the panacea to all ills, let’s take a little leaf out of our traditional/waterfall approach(es) and give this some thought.

Simon Sinek tells us to start with the why. So, Why do we want/feel the need/have already decided to adopt Agile? What problem are we trying to solve, opportunity are we trying to realize etc. Again, most do not ask (and by default answer) this question. Might be useful to document (yes, documentation is ok!) a case for change/mandate/ charter etc.

If we’re in an environment that is relatively stable, well-defined, not subject to rapidly changing customer needs/regulations/requirements etc. then, here’s an idea, some of those more traditional approaches can (and do, when done appropriately) work just fine thank you very much. Whilst I would absolutely agree that waterfall/traditional stage-gating models have their challenges in our fast-moving world, we should think twice before discarding baby with bath water. Some of those practices, some of the time - situation dependent etc. – can be positive game changers and life-savers.

And remember the rhetoric about managing expectations being a good thing? With perhaps a focus on wanting to “sell” the virtues of Agile (when compared to current ways of working) we seem to somehow convey that Agile equates to a shiny grey projectile / panacea for all ills. Remember the definition, “Behaviors, principles, practices, techniques and processes”. Does anyone think that within each of these aspects let alone an integrated mix of all these elements, we humans have the slightest change of not quite getting it right? Agile has its pros and cons like everything else. It is not a silver bullet.

Apply thoughtfully, in context (environment, values and resources) and ensure a systemic learning cycle that drives “validated learning” is working in conjunction with the ”performance cycle” of doing work and we’re on a great path to ensure we work out the optimal balance of the definition components in the “shortest sustainable lead time”. And yes, don’t understand the pros and cons, situational and environmental context, that agile has two congruent cycles as standard, learning and performance, then I’d humbly suggest a few “spikes” to research these aspects be added to the portfolio backlog and prioritized.


This is a significant challenge and one of the top barriers to successful adoption/application. Agile requires a fundamental change in mindset. Agile values different things than traditional management approaches. Rather than command and control, we talk about self-organization, centralized decision making by those with titles and power is decentralized (criteria based) to the lowest appropriate level, traditional approaches value big design/big planning up-front whereas Agile assumes these are flawed as;

a). we’re really not good at working out everything up front;

b). we are atrocious at estimating, demand and capacity management; and

c). we really can’t control all the environmental (internal and external) factors that often

point to the fact that we should deviate from the plan that took 12 months to create and


Agile instead values real-world, quick and constant feedback (validated learning) by doing. And my favorite, and one that is a real challenge re enabling an Agile Mindset, our current companies have a model that favors cost control over value realization. Yes, I’m sorry but it’s true, we can tell a story and appease boards/shareholders easier when sticking to preordained business goals/objectives and associated budgets than when we actually build an organizational system that is truly focused on the realization of real-world value (as can absolutely be agreed by said board members/shareholders). This item definitely warrants an article/series of articles in its own right.


Within the last decade, there has been a spate of books around the issue of Trust in business and I recall a number of papers declaring Trust as “the #1 issue in business today”. In my view, inextricably linked to this is the concept of accountability – and linked to that, decision management.

Sometimes, if we loosen the grip on the reins, the horse is allowed to move more freely and can perform better. Agile is no different. It requires us to loosen the corporate grip and have some trust in the “behaviors, principles, practices, techniques and process” and ultimately “people” we hired to get things done. Accountability shifts from people with titles making all the decisions, to those very people enabling their managers and teams to succeed – invariably a shift to people/talent cultivation rather than governance and process control.

I’ll use myself as an example. In a role that I am competent at, please do not tell me how to do my job. I’m competent so, by definition, know how to do my job. Instead, simply tell me what you want (outcome/value/benefits) and leave me (trust/accountability) to perform in the role you hired me for and deliver the solution/outcomes articulated. Again, I’m competent so I’ll ask you for guidance, help, clarification etc. at a point that enables you via sufficient time and preservation of options to discharge your accountabilities. We need to get to a point where this trust and understanding of accountabilities is agreed and comfortable however. This is imperative for Agile operating models. There is one real kicker to this ideal however,



Agile will require some refined and potentially new capabilities – at the organizational and individual level. I’d strongly suggest that, before jumping into Scrum, we assess our current capability set versus one that is required in the agile world, define and understand the gaps etc. and devise a lightweight (Agile) plan, roadmap and some starter “stories” to build required capabilities to enable us to correctly adopt and apply Agile.

This can be done in parallel with actually adopting some front line delivery practices so we can start to demonstrate some value of Agile while building the ability to be Agile.

There are a number of assessment models that do this just fine – we have various ones that literally take less than ½ a day to conduct and set action plans for. In addition to such “Agility Health Assessment” toolkit, one can also apply simple concepts such ERRC from Blue Ocean Strategy. Review the current and target operating models (it’s actually not that hard to define a target operating model/blueprint/concept of operations as they are typically known) and assess what practices, processes, things etc. should we stop doing (Eliminate), do less of (Reduce), do more of (Raise) or do things that we haven’t done before but should (Create).

Yes, I would absolutely use some Agile techniques, and capture visually the inputs to this analysis having assessed and invited the right stakeholders to contribute and focusing on the correct application of techniques such as root cause (not symptom) analysis/brainstorming etc. We know these terms but rarely do we see them actually carried out correctly. I’d go more traditional in the sense that I would focus on correct application of these techniques as this will generate considerably better, more accurate and actionable outputs.

Now here’s the real Achilles heel for agile adoption. If we understand and define success well, what happens if the competence and capability set of our people is not sufficient to correctly adopt Agile ways of working. I would strongly urge those charged with charting an Agile adoption path to have this on the risk log and give some thought to mitigation and handling plans. All too often this becomes an issue, quickly, for a variety of reasons. Please don’t think it can’t happen to you. It’s really one of the biggest issues we see. Agile practices, techniques etc. really aren’t that hard. Getting people to understand and be able to apply the right things at the right time in the right way, that’s a whole different challenge.


I read recently that some companies were moving and really starting to position their organizational operating models as a “continual experiment”. So, for those pioneers, gone are the days of reliance on cast iron policies, procedures, processes, structures etc. More the focus is on developing capabilities around relentless improvement and what I call organizational “adaptive capacity”. In a sense, they are deliberately making their organizations less fixed/rigid or frankly, “unstable” (which may drive much consternation where the goals, trust, understanding of the rationale for doing this aren’t established!) but much like loosening the grip on the reins of the horse, this enables opportunities and freedoms we otherwise could not get.

Think helicopter versus fixed wing aircraft. A helicopter is inherently unstable – by design! Without the tail rotor applying an opposing force to counteract the centrifugal effect of the main rotor, the thing would just spin around in the circles under power. And having solved this design “flaw” (attach tail rotor), we’re now presented with a vehicle that can maneuver in ways/trajectories impossible to fixed wing aircraft and voila, the game has been changed. E.g cost saving – don’t need a runway to operate, let alone ability to get into areas impossible to fixed wing aircraft (opportunity/new markets).

Experimentation is vital in Agile and I’d suggest in today’s world regardless of any Agile discussion. If we’re afraid to try new things and push out of established comfort zones, then we should stop talking about creativity and innovation (two words often spoken but rarely done!). Lean and Agile governance, risk and opportunity management capabilities can reduce anxiety here. No one mentioned reckless or ill-conceived innovation – we can innovate in an appropriately governed manner!

In classic style, we save the best, likely most important thing until last – Talent. And by which I mean People/Talented People/Teams etc.


I’ve been involved in major organizational change initiatives since the start of my career. It’s actually all I’ve ever done. With over 23 years’ experience I often tell people that ask, yes, I know some stuff and have seen most things good, bad and ugly applied, but I’m still 10 years away from mastering this whole enterprise change malarkey. And, to be clear, I’ll be saying the same thing in 10 years’ time. The pursuit of mastery, alas, is both a relentless passion and never ending. However, one can get to a minimal viable state of competence by likely complying with Malcolm Gladwell’s 10,000 hours formula.

The point of this context setting is this. I’ve spent the vast majority of my time mastering processes, lifecycles, frameworks, methods, techniques etc. etc. Probably not going to school me too much on those things. But the one thing I’ve come to realize really in the last 6-7 years or so – and am 100% clear on – people are >50% of the equation. You can have the best plans, processes, techniques, tools etc. but if you do not have the people able to navigate, perform and generally think, one will always be left scratching one’s head and donning a confused look re why things didn’t go as desired. The real challenge today is that the command and control approach takes away people’s thinking tools. Agile however, requires those tools be applied.

There have been many management themes and fads over the years and the concept of Talent and High performing Teams is no different. So, on the face of it, we’ve recognized the critical important of people/talent and true team work. But knowing is not doing. Yes, we’ve changed the name from Personnel, to HR, to People, to Talent Acquisition etc. but a lot of the behaviors, principles, practices etc. have not adapted.

It’s as simple as this, with great (and lean/Agile) policies, brand, process, governance, decision-making, quality control etc. I will have laid the foundation for success but, I cannot predict actual success. If I do not have the above things defined but have talented, competent people (which includes the mindset, intellectual (IQ), emotional (EQ) and conceptual quotients (CQ - which I summarize as the ability to think) then I’m going to be quite happy, as we have the ingredients of proven performance etc.and real world experience of what to do, when, how etc. Ideally, we need both of course.

But here’s the challenge. How many organizations do you see that are filled to the brim with talent spanning all the key functions? How many high-performing teams have you been a part of? And today’s operating models and the application of performance management are typically contrary to enabling an environment and culture of talent that actually realizes that people potential via performance that delivers real world value.

Why, well here’s a typical scenario, we’ve gone to all the trouble of defining, approving and funding a project and, despite our smart folks knowing it’s no longer the right thing to do or, the plan/approach needs to change due to things outside our control etc. we are still compelled to execute the plan to budget and time. Well, sorry, but doing the wrong initiative in the wrong way, at the wrong time has a habit of very rapidly causing truly talented and capable people to switch off. The slope generally tends to adopt a downward pattern from that point…

Let’s look and learn from the hiring model for companies such as Google. How do we change our performance management models to reward and recognize collaborative and enabling practices for example? How do we performance appraise self-organizing teams? Let’s set practical tests and present opportunities for candidates to show us what they can do (and how they go about it) rather than ask the list of questions HR has furnished us with for the last 3 years. In this day and age, I care less about the right answer to a question that engaging in a setting that enables me to see how the candidate thinks and what behaviors, principles, practices, processes and techniques they apply.


I’m not worried about Agile. There are proven and relatively simple behaviors, principles, practices, processes and techniques that we can define, train, coach and instill as standard operating procedure (in relatively short order) that can yield the benefits associated with Agile. Adoption can (and should) be done in a considered, modular fashion. It does not have to necessitate an enterprise transformational program (and frankly, don’t see those go too well as most companies really aren’t well versed in how to do that!). But we’d better start adopting proven, simple adoption patterns that enable an Agile organization rather than believing that applying Scrum to some IT delivery teams will produce game changing results. This invariably simply leads to local optimization in a relatively small part of the organizations value chain and worse, usually create bottlenecks/pressure on our downstream operations teams.

Please do ask us about the summary steps to adopt agile in an appropriate, feasible, desirable and proven manner.

Please do ask us about our Agility Health Assessments (used before, during agile adoption and post adoption as part of a relentless improvement model).

Please do ask yourselves – are we ready and/or how is our Agile journey going?

Let’s leverage some proven Agile techniques such as WIP limits, cadence, synchronization and Inspect & Adapt workshops to inform and manufacture success.

Let’s spend a small amount of time doing some classic/traditional things first to help enable understanding and ultimately Agile adoption itself.

And let’s not rush out and secure an Agile coach, a dozen Scrum Masters and five Product Owners at the outset. That is invariably NOT where the immediate need is and this represents a small percentage of what it truly needed to adopt Agile.

It’s a little like Resource Management – which is always high on the list of pain points for organizations. The root cause problem is not Resource Management. The root cause problem is the ability (capability) to plan, estimate, define scope and requirements. Allocating bodies to flawed plans, based on poor estimates and a scope that will invariably evolve is quite the challenge after all!

Don’t make Agile adoption the next Resource Management problem de jour.

Featured Posts
Recent Posts