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.

The Agile "Mindset"

Most of the Project Management Community in Software Development has been trying to imbibe and use Agile Methodologies in their production processes, but very few have been successful in delivering to the promised potential. In this article I will try to bring to light some of the obvious but less known concepts that prevent us from realizing the full potential of the Agile Methodology.

Agile as a "Mindset" - For most of us, Agile is a set of processes and practices - Scrum, XP etc. - that define the way to implement an Agile methodology. However, few realize that the true meaning of Agile is to be just that - AGILE. If this was Just Another Set of Processes (JASP), there would be little point in calling it Agile. Its Agile because it is supposed to be a flexible and tailor-able to the needs of the organization, without being restrictive in its implementation. Quite simply put, Agile means doing things the way it works Best.

But isn't that Anarchic and Chaotic??

Well, that is partially the point. In order to understand this, let us try and understand the basic difference between the way things work in Agile Vs Non-Agile worlds. As an example, let us compare the Software Development Process to the Car Assembly Line.

Car Assembly	Software Development
Outcome is knowable	Outcome is not tangible
Change is Expensive	Low Cost of Change
Boundary of Completion is Well Defined	Work will expand to take up the amount of time available, based on the desired quality

Therefore, in Car Assembly Line we need “Trained Workers” whereas in Software Development we need “Knowledge Workers”. However, most of the times we try to apply the Assembly Line processes to Software Development. Therefore, while implementing Agile, all we want to do is DO Agile. Instead, the full potential of Agile can only be realized by Being Agile.

What does it mean to BE Agile?

Agile is not a set of procedures but a mindset. And in order to switch to this mindset, one needs to inculcate the following:

• Welcome Change
•  Failing Early
• Build and Feedback Rules
• Continuous Delivery
• Value-Driven Development
• Small Value-Add Slices
• Learn Through Discovery
• Continuous Improvement

These few points move the style of working from the Assembly Line mindset to the Knowledge Worker mindset. As a Knowledge worker, you are not Trained but Educated. Instead of following processes, you learn to Create processes that best fit your needs and provide the best results.

Therefore, Agile is not chaotic, anarchic or process deficient. It is a way of working where the process is applied if it works and only the processes that work are applied.

Scrum, XP, Product Backlog, Continuous Integration etc. etc. are just practices and tools that have been designed to give you a head-start into the Agile way of work. But at the end of the day the point of being Agile is that you may formulate your own unique tool/practice that works best for you.

Note that in order to be truly Agile you will need to get out of the mindset of “Just tell me what to do” to the mindset of “I have a problem to solve”. And that is when you move from the Assembly Line way of thinking to the Knowledge Worker way of thinking.

I would like to end this article with an illustration that conveys the difference in the mindsets very beautifully.

(This article has been largely inspired by the very informative Webinar done by Ahmed Sidky on September 25, 2013. The recorded video of the Webinar is available here. I would highly recommend anyone reading this to view this brilliant presentation)