Agile does not have dates. Really !!!!

There is an assumption (or some of us believe) that if we are doing agile product development, we do not work based on dates OR there is no such things as dates in an agile world.

Let's clear this myth.

First of all , Why we are doing this agile thing ? This is because we want to be better at delivering Value to stakeholders / customers, we want to be quick to beat our competition and we want to be nimble (flexible) enough so that we can change course as soon as we see a new opportunity. Agile is an approach or a new way of working Not a doctrine.

Now , if we do not work based on dates , then we can keep working without any end date. Things will get done when they will get done. My views on this is very simple : If that is acceptable to management , then please don't read further, have coffee and Enjoy !!!!

In case this is NOT acceptable to management, then we can talk about it as to what we can do better or different so that management is happy with us and we can be more predictable.

Now, let's talk business : There is nothing in agile which says we don't (or can't) have dates. We can (and in my opinion Should) have dates. 

Let's not confuse Fixed date with Fixed Scope. These are two different things.

Normally we have 3 constraints : Time , Scope and Cost. And we all know that in Software products world, Scope is the one which changes most often as we learn more and more.

So, agile approach is : Fix your cost and time and make scope variable. By Variable i mean , let's try to do the most important things first of all. Tke feedback from customers. If it does make sense for them , then do other items in priority order. Keep taking feedback as you work. Working this way , we will have most valuable items already built by the time we are near the delivery date or ran out of money and customer will not be surprised because we are taking him also with us on this journey. 

Example 1 : If we are building Microsoft word and we have a release date after 3 months and we think we can build 5 different features(including Cut, copy and past features which are the most important according to our PO) in next 3 months.

1. We started development , and after 2 weeks we realize that features are much more complex than we initially thought.
2. We discussed with PO and asked her to re-prioritize features.
3. She said let's build top 3 features first(Cut , copy and paste text). 
4. We built those.
5. We released on time 
6. Stakeholders were happy as we were able to release on time and team was happy as we have built the most important features

Example 2 : WhatsApp was released initially in Jan 2009 with only "sending text messages over internet" capability. This was the very basic version of WhatsApp just to test the waters. Then they got feedback from market. Then added "Status updates", then DP's, then Voice calling, then Video calling, then Blue tick(when someone reads ur msg) etc etc. The point here is : 

Agile product development :

1. is a way to control risk of building the wrong thing OR building something which no body wants. 
2. Is a collaborative game where leadership helps teams in removing blockers and waste while teams help leadership by generating something of highest value each iteration.
3. Focuses more on continuous planning and adjusting the the plan based on the reality (because we cannot change the reality  ) 
4. Increases your chances of success. It does not make Impossible possible.

Notes: 

1. There are system running in a regulated space, we need something for an important trade show. We have to have dates and we need to meet those dates
2. We need to help people file taxes by dues dates otherwise our customers might be in trouble
3. We are in online gifts business and we need a capability to sell certain items on Christmas. After Christmas , no one will buy them. We have to have dates.
4. Hard dates are okay and a fact of life, it is just what you can do before that date is an option. It's maximizing value within a schedule; this is where Product Owner comes into play.
5. Do your stakeholders, your customers, your board of directors expect or want something delivered by a certain date? Then you have to work based on dates.

Recently i have a discussion with some of my colleagues as well as some of the folks on Li and I thought it's better to write an article on what I have learned.