Being "Agile"
Darryl Godfrey
A senior project manager with 20 years plus experience in pharma, TIC, consumer products and digital media.
"Agile" methods as applied to programs and projects have been around for a long time now, but it's surprising how many misunderstandings there are. Let's try and get some clarity ...
Keeping it simple ...
To put it as simply as possible, an agile approach involves starting work on a project with only an outline idea of the destination. This contrasts with what we might call a traditional approach where the requirements are developed early on and a detailed plan is produced to map the direction.
Agile is a response to a fact of life: in an "IT" project, people might only have a vague idea of what capabilities they need in a new system to enable them to do their jobs. Without knowing what they need, how can something be implemented which will be suitable?
The agile response involves getting going once an overall idea of direction has been defined and then doing a number of iterations to refine how a system is configured and used. This approach helps key users to learn and improve their own thinking as the project progresses.
This approach came originally from custom software development, but it can also be used for complex packages such as ERP and CRM.
No free lunch
But there's no free lunch. One of the challenges of an agile approach is knowing when to stop. Which means defining a limit to the number of iterations (the time) and the cost. Such a limit is classically defined using the idea of the Minimum Viable Product (MVP) - a Gartner term, I believe.
The MVP is the minimum useful subset of capability. By definition, it's not perfect, but it's useful and the idea of releasing it for general use is that people can learn and adjust their requirements for the next release. So built into the method is an idea of incremental releases - not a single "big bang".
The downside
Obviously, an agile approach can't be used for everything. For example, building a bridge this way isn't likely to be successful. It has grown up in the world of technology due to the ability to always make changes, even if doing so is costly.
Another downside of the agile approach is what is called "technical debt". In summary, this is the collection of things that were implemented in a certain way because at the time it seemed reasonable, but after time and some more thinking, it's clear that a different technical approach would have been preferable. Isn't hindsight wonderful?
Culture change
Finally, introducing an agile approach to an organisation requires care and senior buy-in and this is where it normally goes wrong. The fundamentals are different: a focus on MVP rather than everything a sponsor might desire, for example. It requires a different approach to planning and delivery: via short iterations. From my experience, the single toughest challenge is for a sponsor to understand that he/she won't have everything on day 1, but they will have something useful. This means that they have to be able to prioritise, a skill which is often missing.
On the plus side, agile methods tend to reduce risk since learning is built-in to the process as well as adapting to a certain degree to refined requirements. Note that I wrote "refined requirements" not "changed requirements". At a certain point, things must become concrete otherwise it's just another endless project and no-one wants that.
Independent Consultant
3 年How does this agile approach align with project management time lines and cost management? At a certain moment some version should be somewhat delivering what the user wants, but than enough resources should be left to make user required changes. In other words, while the agileapproach as you descibe helps thr development and dekivery in interactions between it and users. How are corporate limited resources taken account off?
I love the MVP concept - some cynics say it is the best you can hope for anyway - with the everlasting challenge of writing SMART requirements being beyond difficult; when they need to be - specific to COTS software capabilities; and - capable of being understood and developed and tested by implementation teams; - for the funding that sponsors are willing to approve and part with; and - users are willing to accept My own experience tends to bear this out..... an agile approach but with appropriate project documentation, stage gate reviews and clearly agreed CSF's governed by an engaged sponsor who can balance the need for delivery against the need for perfection.