Tuesday, August 09, 2016

Agile Burn Down Chart

I am guiding a project team on some architecture changes. Its a new product. However, I was not getting any clear picture on the progress. I checked Burn down chart. Even that did not give me clear picture. I checked with project team as well Process team on the burn down chart. AND they successfully confused me. :-)

Process team told me that they track the burn down chart based on the 'remaining effort'. Every day each team member update how much time he/she worked any story. The 'remaining time' is the used to plot the 'burn down chart'. 

Now consider the scenario below
  1. Original estimate of Story A is 40 hours.
  2. Team member X, worked on Story A on first day for 8 hours. So he logged 8 hours and 'worked' and 32 hours as remaining.
  3. 2nd day he worked for 8 hours and updated 24 hours as remaining
  4. 3rd day he worked for 8 hours and updated 16 hours as remaining
  5. 4th day he worked for 8 hours and realized that many more things are still do be done to actually complete the story. So he updated 36 hours as remaining.

The chart will show that till day 3 you are on track. However, on day 4 you are suddenly 'delayed'. At this point, the graph will shoot upwards (Q: Do I still call it burn 'down' chart ??). In my opinion, this type of burn down chart gives a misleading picture to project team. On top of this,  consider that sprint duration is 1 month and stories are estimated at 40 to 60 hours duration. Now you have completely inaccurate picture of project progress. Many cases, by the time PM or Scrum master realizes something is wrong, team is very near to end of Sprint and has very little time to take any corrective action. Exactly the scenario that you are trying to avoid by implementing Scrum. !!!!

So what a Scrum team should do to get better picture in "burn down chart" ??

This is what I will do
  1. I will not use remaining time (or remaining story points) to update the burn down chart.
  2. If the story is not done, then entire estimated time is 'shown' as 'remaining' in burn down chart.
  3. When the Sprint starts, I will ensure that stories are broken down to level where they can be completed in 2-3 days (irrespective of I am using story points or hours for 'story sizing').
  4. I will ask which stories may get delayed during the Daily Huddle, but will not use 'remaining hours' estimate by developer to update the burn down. I will use this info only to decide who may need help and how to give that help.
Now my burn down chart will look like a ladder. 
For the above scenario,  till first 3 days, story will remain open and at 40 hours remaining time. On 4th day, when story is complete, remaining time will go to 0. The burn down chart will now look like this.

What do you think ? How do you calculate the burn down chart in your project ?

Friday, June 10, 2016

Why does Agile work ?

Why does Agile work ?  Yesterday I missed a session on 'why Agile' works in Agile Dev (West) conference.  (

Just wanted to share my thoughts on "why Agile works". 

Waterfall Assumes and expects "perfection"

Waterfall model assumes 'perfection'. It expects perfect requirements, then perfect design, then perfect code. Usually that doesn't happen but going back and correcting becomes difficult because of this expectation of 'perfection'.

Agile assumes and expects "mistakes will happen"

Agile assumes that 'mistakes will happen'. So all Agile practices focus on 'detecting mistakes early and fixing them as required'. It assumes that requirements will change. Hence Agile practitioners advise that  "don't spend time on big upfront requirement and design". If requirements change then this big upfront requirement spec and design is a 'waste'. To minimize such waste all Agile practices are use some kind 'fail fast' mechanism. This implementation of 'fail fast' mechanisms reduces waste and hence cost at the same time it improves the quality of outcome. Because of this 'mistakes will happen' mindset, Agile works better than waterfall in practice. Remember Toyota production systems is also based on implementing 'Fail Fast' mechanisms

So what is the 'guaranteed' way of ensuring 'Agile failure' ?  

Bring the 'perfectionist' mindset of Waterfall to Agile. Managers and teams who try to bring this 'perfectionist mindset' to Agile ensure that Agile/Scrum do not work for them.

Saturday, October 24, 2015

Fast track programs for managers and developers - Selection and First Quarter

When we announced the program we got almost 150 applications for this program. We wanted about 20 participants in this program. So we have to short list our 20 selected candidates from 150 applications.  We used following selection process
  • Online test composed of General Intelligence Test, Analytical ability test, English comprehension test.
  • About 50 candidates were selected from the online test. 
  • These 50 candidates have to write an essay about 'things they will like to change' in the organization.
  • These candidates have to undergo an interview by 2 interview panels. 
  • About 25 candidates were selected based on interviews and their essay.
  • These candidates had to  undergo final interview and in the end we selected 18 candidates.
First quarter was difficult. Participants were also somewhat confused and we were also learning about how to run such program.

First quarterly meeting changed lot of things. The participants started to gel into a team. We did sessions on basics of business finance, mind-mapping, creativity techniques, software design principles, basics of PLM systems, etc. 

They have also started on online management certification program by McIntire School of Commerce.  This program covered the theory while the candidates were getting a hands-on experience of all the concepts that they were learning.

One key component of Quarterly Meet was 'lunch with senior management'. Every quarter we arranged a lunch with CFO, COO, Head of HR and other senior management team members. This way candidates were getting direct access to senior management team and they were able to ask questions/discuss and understand their thoughts behind various company initiatives and ideas.

Every quarter we evaluated the candidates on various parameters. Anyone with C grade in two consecutive quarterly is to be removed from the program. So far (almost 6 quarters are done) we have not removed anyone and every quarter we are increasing the baseline

Part 1 of this article