I have just read an interesting article by Bob McGannon on selecting the right IT projects for Agile development. Bob is a Founder and Principal of MINDAVATION, a company providing project management training, consulting, keynotes & coaching services throughout North America, Europe, the Middle East and Australia.
Here is a précis of Bob’s guide to creating an appropriate filter for determining which projects would benefit from the use of Agile processes.
- An eager sponsor willing to conduct frequent reviews and evaluations of the evolving product.
- Ambitious, knowledgeable and available business representatives – The Agile process is purposefully collaborative.
- Minimal time to verify product viability: its power comes from its ability to produce quickly, adjust consistently to new knowledge and business change but only if the learning can be understood, interpreted and absorbed quickly.
- Minimal business exposure if the product produced is broken; it would be high risk to put a piece of functionality into a production environment if an error in that product would have a substantial impact on the business.
- A willingness to consider a very different approach; the ability to invest in a different work and management approach is necessary for the project stakeholders.
- The ‘DNA’ to deal with a bit of ambiguity. Priorities are consistently reassessed and work sequences changed.
The full article can be found at http://www.mindavation.com.au/articles/may10_intellections3.html
Bob’s approach is closely aligned to the ideas discussed in Mosaic’s White Paper on Project Strategy; see: http://www.mosaicprojects.com.au/WhitePapers/WP1038_Strategy.pdf; one approach to every problem seldome dilivers optimum outcomes.
Pat Weaver
Lynda Bourne
Aavssitedev's Blog
Interesting perspective , shows there is much more maturity required in the understanding of Agile, that is a good thing as there is more to evolve.
This one specifically puzzles me
============================
Minimal business exposure if the product produced is broken; it would be high risk to put a piece of functionality into a production environment if an error in that product would have a substantial impact on the business.
=============================
One of the key things in agile is to make sure that enough validation is done to confirm to the standard of the product owner/ customer , the definition of their DONE.Also it is not mandatory that each iteration should be deployed to production.
Whilst the reference is to Bob’s article; and I know this comes as a real surprise to many agile advocates, but there are software developments that need end to end design and rigorous FMEA (Failure Mode Effect Analysis) before a line of code is written, followed by thorough end to end testing before deployment. One example is the flight management systems in aircraft.
In these software environments there is no such thing as a minor change and failure costs $millions not to mention the possibility of killing people. Agile simply does not work in these circumstances.
Thanks Pat for the response.
It does not come as a surprise at all as I do understand things can be mistaken at time.
Agile does not demand you have to release with each iteration. the objective of iterative development is to get early feedback and create something that meet quality in short increments.
The organization who is implement the software can definietly make sure that they don’t do something as killing someone because they are following Agile. I don’t mean to say that Agile methods are for everyone , if you choose into them, you will definietly find ways to leverage it to be successful.
If it does not work for you that is great , however says that Agile will cause large business exposure is not just right .
Good luck with what you are doing . I hope it turns out successful
Iterative development has a range of advantages but it is the anthesis of a designed system. Evolved systems allow adaptation as the people involved learn – this is the ideal domain for Agile. Designed systems are built to achieve a specific, constrained objective and go through a disciplined process.
Pat,
My take on the perspective on when not to use agile systems is where the system starts to get complex (e.g multiple systems integrated) AND the cost of failure is large.
So website that integrated Paypal, twitter and Facebook among other things is fine to get wrong as the cost of recover is small.
The risk when you are dealing with many months or years of independent system development is large and that’s where you need to work harder.
But even this scenario needs to be observed at another layer of detail; complex enterprise software systems may be fine with agile development if you change the way the systems are built (integrate frequently, for example.)
So the real segment where it gets hard to run agile projects is smaller; possibly just where physical assets and software assets are integrated – by teams that are not able to regularly integrate their work.
What are your thoughts on this view?
Our “Agile” project has turned into the most uncomfortable working experience I have had in 10 years. I have been wracking my brain trying to figure out why and have settled on this: first, we do not have the personalities needed to have a good Agile team (surly developers, meeting-haters) and we do not have an enthusiastic leader who is an Agile fan. I seriously think our team leader (PM) saw the “project management by team” Agile theory and saw that as a way for her to do nothing.
My take on Agile done well is there is a real need for very high levels of skill in the team leadership area and the project strategy and high level planning areas. Setting the right tone and direction for the project is not easy but without this framework the ‘iterations’ can become meaningless (unless the job is so small and simple people can do the work intuitively).
Pingback: What is Agile? | Aavssitedev’s Blog