Task finish late more often than they finish early, why?

"Failure to plan is planning to fail"     -  Winston Churchill. 
"It is better to be roughly right than precisely wrong." - John Meynard Keynes 

Planning should enable us to take right and reliable decision. Don't get me wrong, I am not asking for precise estimation.

I strongly believe in quick and rough estimation which evolves as time pass through.

In this post, I am leaning more towards what impact, human behavior and type of work we do, make on our rough estimated number.

Student Syndrome or waiting till last responsible moment ;)

Student Syndrome, refers to waiting to start a task until the last possible moment that does not preclude on time finish. (This is human nature and very difficult to change.) Lets take same feature A example. As a developer, I thought task X should not take more than 3 days but I kept one day buffer and said 4 days.

When we think we always think like below: Work (3 days) + local Buffer (1 day)

But while executing we feel very optimistic to finish the task in 3 days and we start with cleaning technical debt, preparing some flow for project or documents etc.

We behave reverse i.e. Local Buffer (1 day) + Work ( 3 days)

Finally I started my work and my work took 4 days. I ended up delaying the schedule vs. finishing on time. I had local buffer but it did not help. Therefore having shorter iteration in development cycle might help in keeping the focus vs. big iteration.

Lateness passed down (Central Limit theorem does not apply for software)

Software tasks are mostly dependent upon each other, hence the impact of delay of one task may cause delay in other another too. Let me elaborate what I mean by this. Lets estimate a feature A, which has 3 tasks X, Y, Z.  Task X would take 4 days to finish. Y and Z subsequently would take 2 days each. So initial estimate for feature A is 8 days.

For some technical reason task A took 5 days. Now obvious question would be to think what impact would it have on tasks Y and Z? Developers would mostly say other tasks would finish in 2 days each, since I learnt a lot while finishing task X.

You might think that our new estimate for feature A is 10 days vs. 8 days.  If the tasks in feature A are independent to each other, than this new estimate might be good but in most cases if task X took 1 days longer there are possibilities that task Y and Z might take longer too.  Therefore for any revision, look for inter-dependency within tasks for more accurate estimates.  

my experience
Manisha

Think outside Scrum or Kanban

Today was that day again when I ended up moderating Kanban vs. Scrum process meeting. Honestly was deep into one code refactoring and meeting reminder popup awakened me. Had to quickly gather up myself and started thinking. Why teams always choose one process over other and never ask or understand "what process has to offer them".

Having experience with multiple teams and process. I kind of hate and love Scrum and Kanban. People just like to blame the process vs. putting effort into understanding them. Scrum does not seems to working, lets try kanban.

I wanted them to think out of the box and they keep coming back to Kanban. It's like, I heard it, I saw it and I know I want it. What would be world without waterfall, RUP, Scrum, Safe or Kanban or Lean Startup models.

I was being asked this question long long back and it stuck in my head like a tumor. I myself don't have best answer and always start to think what is a process first before thinking how it can benefit us?

As per wikipedia, it is a series of events to produce a result. In our IT world we can say process helps us to produce software. But how one process does it where as we have each company solving different problems with different set of behaviors in one organization. It's getting late but will think for my new process. Manum may be which will solve next generation problem. May be good starting point would be think of problems which we want our process to solve and pick and choose goodness from all around.

Always like comments
Manisha

Process for Art vs. Commodity

I am thinking a lot about process of late. People talk about Scrum, Kanban , XP blah blah. We all agree that none of the process is perfect to solve all your problem. Mostly everybody talk about organization culture, context and business problem influences your process model.

I am not denying about their importance but I strongly believe there is one more factor which is equally important if not more.

Your engineering team. How team feels about writing code? do they feel it as form of art ( I know it's very subjective) or as bunch of functions to complete a business objective? We all write software for business, government or other institution and we know customer only cares about FUNCTIONS.

Question is WHAT YOUR TEAM CARES ABOUT? How they feel about code? Understanding them and their need will be base of any process you put around them.

To my experience if you have a team which treats code as commodity would be happy, following any well define process. Whereas passionate people, who would like to be creative, would prefer little unstructured but responsible system.

May be their own customized personalized Kanban or LeanBan or ScrumBan. First understand the team and then define the process which fits their developer personality.

In my organization one team was very reluctant following any process so we tailored Scrum to their need.

I explained them what Scrum or Kanban or Drum Rope etc process have to offer us. Advantages and disadvantaged of each of them. Then we discussed our issues which we have presently and things my team is good at.

We all agreed that we need something which will let us keep our goodness and will fix our short comings . We designed our own process and my team is loving the process around their need vs. making them process slaves.

I know, I will upset few scrum gurus but my team is happy. To me this is bring agility to process.

Thoughts?
Manisha

Business value and MMF

Doing why stack is fun. It might be little annoying initially for few product owner or business folks. But I think we should pop up why stack max 5 times recursively for every feature until we end up with one of the following business values:

• Protect revenue
• Increase revenue
• Manage cost
• Increase brand value
• Make the product remarkable
• Provide more value to your customers

If we’re about to implement a feature that doesn’t support one of those values, chances are we’re about to implement a non-valuable feature. Consider tossing it altogether or pushing it down in backlog. Focus on implementing the MMFs (Minimum Marketable Features) that will yield the most value.

The value provided by a system is what you can get out of it – not what you put into it.