Not Burning Down? Diagnosing and Fixing the Some of the Problems

Of course you would not expect every sprint to have a perfect burndown. You would not expect to complete every story in every sprint (my goal has always been 90% or greater stories complete), but if you are finding yourself with many “overhanging” stories each sprint there are a number of things that you can do to diagnose and fix the issue. In this particular post, I am going to discuss problems with time and hours.

There are three things that can go wrong with hours:

  1. The number of hours the individual estimates for capacity is too low.
  2. The number of tasks identified is incorrect (not enough tasks identified).
  3. The number of hours associated with each task is too low.

Continue reading “Not Burning Down? Diagnosing and Fixing the Some of the Problems”

Wideband Delphi and How I Re-Discovered It

While on my way to researching something else I can across an interesting blog entry on Atwood’s coding horror site about Planning Poker. Over the years I have been a scrum master I have evolved a pretty effective way of getting relative story sizes as quickly and accurately as possible. I do this rapid release planning by having the team choose t-shirt size stories as yardsticks and then having them use these sizes to size new stories. This in itself is not unique, but what I ended up doing to further streamline the process is to give the team members a spreadsheet and have them fill this out on their own and send to me.

It works very well.It keeps team members from getting “bullied” by outspoken teammates. We find that there is really a great deal of agreement for the size of stories (80-90%) and we save a great deal of time that would be spent in a meeting discussing a bunch of stories we already agree on. Not only do we save time but we gain accuracy by tapping into the wisdom of crowds. Those stories where we don’t have good agreement (high Standard Deviation) we can discuss until we agree. So I thought I came up with a new way of doing story pointing. While that still may be technically true, after stumbling upon Jeff Atwood’s blog, I realized that what I really did was to re-discover Wideband Delphi and apply it to Agile instead of waterfall. It goes to show that everything old is new again.

Welcome to 2012! Getting Back to Agile.

Wow! Just noticed that I had not blogged at all since October of last year! Between starting a new gig on October 31st and the holidays I have been way too busy getting acclimated to my new surroundings, shopping for the perfect holiday gifts, feeding my face with holiday cheer, etc. to spend time writing about Agile development. Time to get back to it. My new year’s resolution is to begin contributing again on a regular basis. It is therapeutic for me and I have found out through Google analytics that there are a number of folks out there that have found some value in my musings. I hope you all had a great holiday season and I wish you the very best in the new year!

What to Expect from a New Agile Team

Whenever I work with a new Agile team I have some stock “speeches” that I tend to give. One of my favorites “speeches” covers my expectations are for a newly formed Agile team, namely increased transparency and predictability.  Notice that I did not say increased velocity. That may or may not come with time, but the first two hurdles are getting to a point where one can understand what is going on at any time – transparency – and what can be expected to be delivered over time – predictability.

One of the biggest hurdles to getting any software development completed is endless interruptions. Transparency provides a safe haven where anyone associated with a project can see where the team is at anytime so that constant status and interruptions can be calmed.

Continue reading “What to Expect from a New Agile Team”

Chaos to Waterfall to Agile – The Evolution of Software Development

I spent some time recently in a PMO meeting about project  metrics. Seems that the big bosses want to create some service level agreements based on these metrics. The most interesting part of the meeting was sitting back and watching the process. As an Agile proponent I was amazed at the lunacy of central planning. Each project was on a master project list and resources (humans as I like to call them) were assigned based on their time estimates. These folks were scheduled months in advance. During the meeting, the leader of the PMO said that it was incumbent on the individual project manager to make sure that the assigned resource begins and ends their work as based on this long-term plan. Anyone who has spent any time in software development should realize that the odds of the working as slim to none. Funny thing, every PM in the room, even the head of the PMO, who has a background that includes Agile, thought that this was an appropriate methodology.

The kicker for me was when the head of the PMO stated that a successful project was one were estimated time was plus or minus 20%. A simple calculation told me that I was glad that I was not a PM responsible for a downstream project. If a resource is off by 20% on estimation of a large project, then my odds of getting the time I was promised from this resource is is low. Let’s say that the resource is committed to 160 hours of work on a project upstream of mine. This project can be successful even if this resource goes over 20% or 32 hours. If I only needed him for a week or two,  I certainly will not get the work I need or something else will need to slip. Add scope creep, poor requirements, etc and you have a very small likelihood of success, hence the CHAOS report results for project success.

Continue reading “Chaos to Waterfall to Agile – The Evolution of Software Development”

Why I Don’t Like Whiteboards, the Last Sacred Cow and Why I Will Burn in Scrum Hell

I doubt there are many people in this world who have the passion or spend more time researching about Agile than I do. Over the years I have seen many sacred Agile/Scrum cows questioned. Usually when one has the guts to do so there are scores of Agilistas ready to denounce anything that goes against their indoctrinated Agile/Scrum education. It seems that many fail to understand that in order to prove the value of something, it must always be questioned. Hell, the whole damn thing started because a few folks decided they would question orthodoxy and find better ways to do things.

And now I think I have found the very last sacred cow remaining. Over the past few weeks, whenever I have some spare moments, I have googled, binged and read blog after blog. My search – is there anyone else out there who really doesn’t care for Agile/Scrum whiteboards. I can say from experience that it appears unanimous. Every person talking about Agile or doing Agile absolutely, positively, without question loves Agile whiteboards to track iterations. All that is except me. Yet I cannot hold my tongue any longer. I know I will go to Scrum hell, but I have always had a strong distaste for Agile boards.

Continue reading “Why I Don’t Like Whiteboards, the Last Sacred Cow and Why I Will Burn in Scrum Hell”