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:
We’re talking about it, but no-one really knows what Agile is.
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”?
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.
- 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:
Why do we need to adopt Agile? (drivers/rationale/goals/objectives)
What, precisely, do we mean by/is Agile? (definition/ understanding/ alignment/ commitment/ governance)?
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)
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”)
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.