Sunday, September 25, 2016

SVNPlot Version 0.9.0 Released

Today I am releasing SVNPlot Version 0.9.0.

SVNPlot now works on Python 2.7.x and on Python > 3.5.x. Current release also contains many small bug fixes esp. related to Unicode handling.

You can download the installers from Bitbucket Download Page.

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.