Evil Burndown Charts

This post is in response to Tim Ross’s post on ‘Are Burndowns Evil?‘

Tim asks how useful a Burndown chart is, especially in the case of a new team with a new or unknown code base. A burn down chart (with an ideal line) for a new team immediately gives a team ‘schedule pressure’. Some may say that pressure instantly kills creativity and induces a ‘get it done’ mentality. I’d like to disagree, just a little bit. I think what little pressure a burn down gives at the start of the iteration can be a good thing. Every team needs a little hustle. Indeed in the case of a new team after a few days of a flat line bundown, this could well start having it’s negative affects, but this is down to the team. Should the team’s first call of action be to abandon all quality, that for me is a people problem. A fresh new team with no idea of it’s velocity should be made aware that the burndown for them is very much an indicator. I think this indicator is always a good thing. It tells us early, if we’ve overcommited and vice versa. It can inform your decision on changing and new requirements.

When a Burndown is used by project managers or anyone else to see how much work is done, you’ve got a small problem there. As Tim notes this just plain aint true. If you’re strict and award your points only when a task is ‘Done Done’ (and not half the points for half the work) you could misinterpret the burndown as saying no one’s done any work. Again its indicating how much of the work, maybe a better way of putting it would be business value, you committed to has been delivered, and perhaps even is ready to ship.

Breakthroughs, insights, and epic refactorings. You can consider these to be big chunks of work that go toward improving the code base and potentially not adding any immediate business value. Now let me stress here that these types of changes go a long way to a maintainable code base. No one likes working with a big ball of mud, and it’s not just a selfish emphasis. From a purely business focused view allowing the time for these kinds of things early and often plain old means you get more for your money in the long run. Code changes get cheaper and code changes. (period).

Burn-downs don’t reflect the value a team gets from such activities very well, and indeed this could lead to a vicious circle of teams never getting to implement these insights, which would be plain wrong. I think the key thing here is to note that the burn-down would actually allow you to make a slightly more informed decision as to when to take on these tasks. Some would say later is always the wrong time to do them, that they would get neglected and forgotten. Now I’m sure small easily lost refactorings should come in to your normal work flow and therefore velocity, so I’m not including them in this. The larger pieces, well they may well need to wait, perhaps even in future iterations they can be thought about and planned for, assigned points. Some what of a technical story, but when it’s presented and it’s value weighted and dare I say it costed, this is something quite more powerful to present to people that pay the bills. The automatic notion that these things should be done as soon as they’re discovered is almost a form of premature optimisation in my opinion.

To summarise, indeed a burn-down charts use can get lost for a new team, and it shouldn’t be the focus of morning stand-ups, it’s an information radiator, not an information altar. Use it effectively, and don’t let it make you feel so bad so easily!

If you’d like to know what good a burn-down chart is for a team that has a velocity, search the Internet.

Sustainable pace

One of the great things about Agile software development that I’ve noticed is sustainable pace. Planning poker, point based estimation and velocity are all great tools for finding a team’s sustainable pace. Knowing a team’s velocity and consistent estimating by the entire team, allows a team to commit to as much work as it is (increasingly) likely to complete, and complete consistently.

As well as properly managed expectations, a sustainable pace has the benefit of ensuring the quality of a team’s work is consistent. When the team is working at such a rate, there is no crunch time, there is no working late. As developers, working beyond our capacity can result in long lasting problems. Beside the whole no life outside of work thing, it also affects the quality of our work. Which always results in cost later in the life-cycle, be it with maintainability or bugs that come out of last minute fixes.

So I sound pretty sold on this whole idea don’t I? Well I am, and I’m almost proud that one of my close friends always leaves the office at ‘hometime’. I taught him both he and his work would be better off than if he stayed behind to finish that last bit! Well this all bit me in the butt recently and it I’ve noticed it has definitely killed off a great part of the job. The Programmers Hi-Five.

So some 6 weeks ago I was handed a project that was ambitious to say the least. I was asked to take our biggest product, which made the most money, and was closely watched for compliance, and rebuild it. No pressure. Being such an important product it naturally followed that it was the most hideous piece of ill maintained code we had. Given said compliance issues we were also not allowed to deliver functionality incrementally, as it was all required to stay compliant. [see curse of the rewrite].

All of this was to be delivered by one of the hardest deadlines we had ever had. As a business there’s an awful lot of buy in in to the whole agile thing, It’s something I’m quite proud of, but this wasn’t very ‘incremental’. So with all of that in mind, I agreed to do the project. As much as I love what we do and how consistently we do it, I work best under unreasonable pressure. I don’t understand any other kind of deadline.

Oh and did I mention it was with a fresh team that hadn’t worked together before? All good fun.

Given a mighty fine team and even some license to rework our QA process we worked ourselves hard. Often staying late, sometimes because we were in the groove (the best kind of working late) and sometimes just to make sure we stayed on course (the worst). We even worked for a few hours on the weekend. Once.

I’m getting mighty long winded, so I’m going to try and summarise the rest:

Good things:

• Pushing ourselves that hard meant we achieved a lot in a short space of time.
• We had to work hard to ensure quality throughout, but that has certainly brought new in sight on how we can improve our QA process going forward.
• The team gelled very quickly. I don’t think we’re done, but I certainly witnessed us passing through forming and storming in an iteration.
• Programmer Hi Five. A whole lot of satisfaction when something came together. I don’t know why this doesn’t happen more often in the normal course of a project. My hands have never stung so bad.

Bad things:

• From outside of the team and maybe even from within the team at times, we appeared to not be in control. Almost firefighting. We weren’t (always) but I’m sure as a team we’d prefer to give the impression we knew what we were doing at all times.
• We don’t have a velocity. We worked too hard to be able to find a velocity, in the upcoming ‘normal’ iterations I have no idea how much work the team is capable of at a Sustainable pace.
• Left behind. The amount of work we had to do meant often more junior members of the team were left to fend for themselves.
• Cool down period. We need a cool down period, luckily this all happened at the end of the year. The only time for it if you ask me. Hopefully it won’t be difficult to ramp up after this.

So I think we should throw out sustainable pace once in a while. (I’m thinking once every one or two years). Just to remind ourselves of the fun we had as hackers, and why it’s so much better as developers. The Edge of Chaos is fun.