Scenario based Agile

Scenario based Application of Agile Methodology to Project Management

Being a Project Manager for past several years I have often found myself and other Project Managers struggling with the problem of when to use Agile. In this article I try to specify a few scenarios which may lend themselves to effective Agile Project Management, and in the process I hope to answer some of the questions that have bogged the minds of my peers.

However, before we delve into the various scenarios, it would be of consequence to do a quick review of what makes Agile Methodology so unique and unorthodox. Below are a few of my understandings around this:

1. Agile works best with a team with a Flat hierarchy
2. The success of an Agile Project is measured by the Business Utility of the product (quality-centric), rather than adherence to the plan (variance-centric)
3. Concentration leans towards Product Design more than it does to Risk Management. In other words, risks are acceptable as long as the reward is substantial enough
4. Teams are self adjusting and self organizing 

These factors make Agile a preferable methodology for some scenarios at the same time as it makes Agile disastrous for some other scenarios.

Scenario 1 - Chaos
"The Software Developer is a Startup with a great idea whose incubation period is about 1 year"

Primary Considerations for Choice:

• Startups tend to be less structured and therefore a flat hierarchy will be more achievable and acceptable.
• Startups typically employ top-notch resources and therefore the team members will most probably be self-motivated and genuinely knowledgeable.
• Since the idea is at its inception stage, there may be various changes identified and required during the course of implementation. This would make the Agile's ability to adjust and re-adjust to change (essentially being "Agile"), of paramount importance
• Since the Startup is developing the software themselves, there should be no reason to identify a fixed-price/scope based implementation approach (which is where Agile miserably fails).

Therefore, in this scenario, Agile is not only a preferred implementation methodology, but also an essential choice for success.

Scenario 2 - Dictatorship

"The Software Developer is a Services company who is developing an E-Learning platform for its client. The client is insisting on signing a Fixed Price contract for this engagement"

Primary Considerations for Choice:

• No Advantage - Since the requirement is pretty standard, there is not a lot of requirement for innovation on-the-fly. Therefore the requirement will remain more or less static and the major advantage of change management, gained from Agile will be minimized.
• Disadvantage - In a Fixed Cost scenario, using Agile may mean Risk Amplification, as the cost will not vary in case the project needs to be extended due to the minimalist planning warranted by Agile. 

Therefore, the use of Agile in this scenario is not only fruitless, but may also end up being harmful to the overall endeavor.



Scenario 3 - Democracy
"The Software Developer is a Services company who is developing a new Eatery Location/Suggestion system based on implicit preference analysis of Usage patterns. The client is insisting on signing a Fixed Price contract for this engagement"

Primary Considerations for Choice:

• This is a balanced scenario where the requirements are not well established but the cost of implementation has to be fixed.
• Agile would be preferred in this case as the requirements are volatile and may evolve as the implementation proceeds.
• Additionally, the client may want to have a view of the production progress, sooner than later, as the concept is R&D based and prone to misinterpretations by the team.
• The constraint of a fixed price can be achieved by breaking down the work into calculable units and then exchanging the units to ensure that the overall value of the scope remains the same, even if the scope itself changes.  

The use of Agile in this case is the lesser of the two evils. Since the client is looking for a Fixed Price against a variable scope, the situation is tricky and slightly impractical to begin with. However, the Waterfall model in this case holds a much greater risk due to the delayed visibility and feedback.

I hope that the above should help put things in perspective for the reader and help them make an informed choice of project management methodology, specifically Agile.

As always, your comments and suggestions are welcome.