Any form of human expression has its own trends and fads, for better and for worse. Management is no exception.
From Planned Management, with its somewhat simplistic “Plan-Organize-Manage-Control” mantra, to the “Total Quality” craze with its ISO certification, which led to the LEAN approach (with or without its twin sibling, Six-SIGMA), the latest “en vogue” management thesis is AGILITY, a concept that’s been getting more than its share of hype in the past few years, like a new religion that’s supposed to cure all our ailments – especially our chronic lack of time to properly plan for major projects. At least, that’s what a lot of people seem to think.
I recently noticed that for some, being AGILE simply means putting the planning process aside and improvising on a whim, spurred on by a sense of urgency and a need to react quickly to changing markets.
Unfortunately, that’s not what agility means.
Although the AGILE approach recommends subdividing your projects into more easily achievable deliverables, it still requires a good dose of planning from the onset (i.e. during the first SCRUM), and then at the start of each new SPRINT (iteration or cycle). Contrary to what some may believe, the objective of the SPRINT – as well as its deliverables – should be thoroughly planned out.
So beware if you try to substitute agility for the simple fact of properly adapting to a constantly changing situation.
AGILITY means delivering a complex project by iterations. It’s a rigorous and demanding approach that requires a constant focus on your objective and an attempt to eliminate obstacles along the way (which is generally the job of the SCRUM MASTER).
AGILITY is not a new methodology for achievement in project mode. It’s an approach, not a method. It doesn’t ignore older methodologies, such as LEAN; rather, it seeks to integrate them.
The AGILE approach encourages us to devour the elephant one bite at a time, by producing tangible, short-term results, or quick wins, as part of a larger-scope project. It stems from management’s desire to reap the benefits of its initiatives much more quickly. Through its iterative style, the AGILE approach allows for a continuous flow of benefits, rather than one big payoff at the end of the journey.
Does this approach have its limits? Of course – just like any other. Spending less time defining your deliverables, and having many more client touch-points along the way (not always a bad thing, mind you) tends to result in an “evolution” of the functionalities required at the start of the project. Sometimes, this requires taking a few steps back to adjust structural elements that have become inadequate due to the recent add-ons.
The absence of a formal hierarchical structure also calls for a rather homogeneous team, in order to deliver on time and on budget. On the other hand, the absence of varying perspectives within the team does not necessarily contribute to delivering a higher quality product.
Finally, with the focus on achieving and delivering, the project is often badly documented, which may lead to difficulties in terms of system maintenance and updates, especially when the original developers are no longer around.
Being AGILE requires a certain capacity to anticipate, even without more rigorous planning. For those who thought that being AGILE simply meant having the capacity to quickly adapt to a new situation, think again. Even if it’s only on a very short-term basis and by iterations, planning remains a key component of the AGILE approach.
Being AGILE simply means properly planning and developing a unique deliverable, and delivering it on time.