They Say Agile Is Different! So, tell me what’s different? – Part 1

 

Agile is the buzz word now a days. Still, many times during my training sessions, I face this question “what is so different about agile?” I think there are seven wonders (or wonderful things) about agile. I thought of summarizing them in this series of article. This series will list key differences between agile and traditional approaches (in my opinion). They just happen to be seven 🙂

Seven Wonders (or wonderful differences)

In my opinion (and experience), I think following are seven key differences between agile and traditional approach to project management. Please note that this list below is not ordered by importance of these items. In other words, it’s not so that 1^st item in list below is more important and 7^th one is least important. It’s just a list of seven!

1. Definition of a successful project – it’s different 🙂
2. Do regular but small studies throughout the term and not just few weeks before the exam!
3. Estimates are wrong! So…estimate your project more often!
4. Plans are inaccurate! So…plan your project more often!
5. If you hold stake (stakeholder), then must work together!
6. Bad news can be a good news, depends when you communicate 🙂
7. All projects have dysfunctions….when do you surface them?

This is the first one of this series….

Definition of a Successful Project – It’s Different J

While managing any project, a project manager (PM) is challenged with successfully juggling three variables at a time. And they are scope (includes the quality requirements), cost (due to resources) and time. If you disturb any, the other two may require adjustments to maintain all three in equilibrium.

In a traditional approach, we understand scope thoroughly (signed off requirements), using which we try to determine how much it would cost and how long it would take. Once you determine this equation, all three are supposed to be fixed. That is you must deliver said features in said time and said budget. In fact that has been the definition of a successful project!

However, every project is full of so many uncertainties (risks) that juggling this equation becomes too difficult in reality. We invariably run out of time! So, when a project (mostly every project :-)) reaches a stage where you realize that you can’t deliver said scope in given time, the most obvious (??) thing done is to add more resources to “somehow” get everything “out of the door” in given time! And then we say “we successfully delivered this project” 🙂

Have You Ever Thought Of This….?

You take any product – e.g. your mobile phone – how many features does it have? Probably hundreds. And how many do we really care about? You can count them on your fingers.

This is true with any product. Take your bank’s website or any e-commerce website or any damn thing – this is always true!

Less than 20 % of the features of any product provide more than 80% of the value! Not every feature is equally important in any product.

How Agile Takes Advantage Of This Fact?

Now, agile tries to take advantage of this fact. Out of the three constraints described above, usually time will be absolutely important! If you are late in market, you can be out of competition (and existence also :-)). You usually have limited dollars to burn while building any product. And time is money as wellJ. Whereas, we just learnt that not everything is so much important in any damn product! With agile we build product incrementally and iteratively. So, then, can we lock the two most important constraints, that is, time and cost and choose to deliver as much as we can within those constraints, ensuring that we get at least those 20% of features out which matters the most for success or failure of a product? So, we will have “time-boxed” iterations, and each iteration producing a small increment of product. Thus, now we will have only one variable to juggle – that is scope, since we have locked the other two!

There comes prioritization of scope (features) to be delivered in a project (hence prioritized product backlog).

So, now when an agile project (like every other project :-)) will reach a stage where you realize that you can’t deliver everything in given time, that you once thought you will, we need not add more resources to “somehow deliver” everything, but rather drop certain items from scope! So, instead of compromising on quality and cost (by last minute addition of more resources), agile says it’s better to compromise scope! Because not everything is equally important J and you would know your “chopping block” of scope, if you are maintaining a disciplined and prioritized product backlog.

So, think – what should be the definition of a successful project now? 🙂

Food for thought…

Assume that building just the following screen is your project. We have to get this out in three weeks with great quality.

Think of following questions…

1. How many features do I notice on this screen?
2. Are all of them equally important?
3. Do I clearly see some feature(s) which must be and can be done in 3 weeks’ time?
4. If we fall short of time, can we “leave something out”? J

 

If you are able to see at least 7 different items (or features) in this scope and can clearly notice difference in their “value” to end user of this screen, I think you can now deliver this project “successfully” in 3 weeks’ time-box 🙂

 

Hope you enjoyed this. Click here for the next item in this series.

Please do share your feedbacks. I would like to do this series incrementally and iteratively. So, be assured that your feedback on this first increment will be taken seriously to improve future increments in the series of these articles! Thanks….