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.

Our first good acceptance test

In an effort to get our teams understanding ‘Done Done’ we’ve started looking at acceptance testing. We’ve moved, over the last 18 months or so, from a traditional waterfall process to a full on Agile one, our final hurdle is the QA process. We still have a very waterfall-esque QA approach.

We’ve done lots in terms of getting QA involved early on, making environments available for the different stages of testing. But we still have a major problem where by all our QA tends to get done once the developers yell ‘FINISHED!’.

The problem is, we developers tend to lie. Not knowingly, more out of a desire to move on to something more interesting. So even though we may be making our burn down chart look a little neater, we’re in fact delaying the inevitable. QA return to us our shiny code, complete with bugs we never thought possible.

So recently, we’ve started looking at Fitnesse in an effort to bolster our QA efforts and also to bring more light on to the process that is QA. If we get more people looking at it, we can surely all help to improve it by offering new tests and finding ways to improve how the existing tests work.

I’ve known about Fitnesse for quite some time, since CITCON made it to London, my first open space conference. However, even then the general consensus was it was great, but quickly turned in to a beast to maintain. This problem still remains, as from the recent alt.net conference, Gojko himself said, it aint great, but it’s all we got.

I’ve waited too long for someone to come up with a better alternative (whilst keeping an eye on J Miller) we’ve started to give Fitnesse a go. I’m doing my best to ensure we don’t fall in to the pitfalls people have done before. My main gripe would have been the need to build fixtures. I have heard many a nightmare about the fixtures replicating ‘value’ already given by unit testing, fixtures being brittle, and requiring as much effort as production code to keep going. These are all things I’m tying to keep us from.

So recently my new team showed me our second good acceptance test, the first one referred to in the title that inspired this post was by another team which I used to experiment with. The approach I’m taking, is to use the FIT approach against the parts of the system that have to handle all the ‘scenarios’. We’re following a flavour of SOA that I like (not full on SOA, that still makes me uncomfortable). We’re also cleaning up some of the more terrible examples of misplaced responsibility we have. This gives us an opportunity to move domain logic from the ASP.NET front end (urgh) to the places it belongs.

The SOA gives us a nice potential for isolation. That means we’re able to get our examples from the business (or indeed from the beast that we’re rewriting) and feed them in, table like, to check the code we wrote was the right code! One thing I really don’t want to get hung up on is driving selenium or other slow front end tests from Fitnesse. That would just give us the illusion of acceptance testing when all we’d really be doing it moving are old fragile, brittle, slow selenium tests into a fancy wiki that no one would read.

But I’ll come back to that later. One decision which we’ve made, and now you might disagree with this, is to tie the fixtures directly beneatch the WCF contract stuff we have for the service. this means it talks to a more pure, less noisy version of the services the service offers. This so far has allowed our tests to read quite clearly in terms of what makes up a table. It has also hidden quite a bit of fluff we use to on all our services which qould give our fixtures another reason to be brittle.

It does however mean that we wouldn’t pick up an problems with the WCF layer we put atop. I’m going with this is an OK trade off considering how good it felt to see 400 test cases passing and 100 failing. I never thought I’d enjoy seeing red tests so much!

Me feels I need to be more specific (and more frequent!) in my blogging, maybe if I don’t let post sit in drafts for 2 weeks they’ll be better. Hopefully there’s more on acceptance testing to follow!

Estimating tasks with points

Following on from my entry on the altnetuk session on Agile Process, I’m just going to layout the different types of estimating with points that I know of. I’m not sure why but at that session it felt like someone had put and end to point to complexity estimating and forgot to let me know!

Pure time based estimates

You’ll be wrong. The time it takes for dev a to do a task will be different to the time it takes dev b. You will run in to problems with the task and it’ll totally throw all your estimates out (may be exaggerating).

Your manager will not understand why you can’t do 7.5 hours worth of work in a day. There is no room for ramp up, context switching or any of those minutes you don’t think of.

Burn down charts tend also to look like complete failures. As every hour of your day is accounted for, but you don’t actually spend every hour of our day on storied tasks, those other hours show up on a burn-down chart as slacking. When this happens, it’s not reasonable for the team to commit to less in the next iteration, as it implies they’re not spending their time doing any work. This totally ruins the point of committing to any work in a planning meeting, if there is little or no intention of completing it all. This also makes it difficult to ball park future iterations.

Time to points

The team eventually manages to estimate tasks without thinking about the time it takes. Easy to figure out your capacity or velocity. Easy to manage when team size fluctuates (illness, holiday, expansion). Easier to sell to management. No room for improvement, how do you increase our velocity without making time? It’s possible, but only by admitting that you’re not estimating with time any more.

Pure points

Difficult to start a project with a new team. I do this by assuming we’re unstoppable and committing to all the stories we have. Then I use the number of points we do complete as a baseline for the following iterations. Motivates developers quickly. Increasing velocity in this way is far easier to motivate developers with. The idea that you’re getting better at doing work is much nicer than the idea that your old estimates were slack. More quickly with pure points do new developers fall into line in planning poker. They stop influencing the task with how quick they think they are (maybe quicker than some of the team maybe slower) and go straight to how complicated the task is. Points always help when you get estimating discrepancies. More clearly separates your teams estimating technique / accuracy from another’s. With a per team velocity and meaning for points, it’s more difficult for management to unfairly compare two teams estimates and use it as a flawed performance indicator.

Agile session Alt.Net London

So to start the conference I chose to take part in a session about agile development and processes. I think mainly because I wanted a refresher on some of the points and to see if I could contribute. It’s nice to see plenty of people there new to Agile as I was at my first open conference. Learning the basics of the process, and making a good start. I was also interested to see how people had developed from their initial attempts at introducing Agile to their shops.

At one point there was a lot of talk about how we estimate, and I was surprised to see that everyone had assumed estimating in hours and half days. Assigning some time to points and then estimating with points. I wonder what happened to estimating by points representing complexity. At uSwitch, when we introduced planning meetings and planning poker, we started with 5 points to a day. This was mainly to get developers used to the idea of estimating in points and as a team. Over time in teams where this method had remained, they have naturally loosened the tie between the points and the number of hours they represent when estimating. They still use the rule to define how much capacity they have in a given iteration, 5*Devs* 10days = capacity.

For me and my teams, we’ve moved this to the next logical stage of entirely decoupling estimation points from time and tying them to the complexity of a task. Has this gone out of fashion and no one told me?

I think I’ll break this off into a separate post on estimating

Crystal and full project breadth

Ian Cooper shared with the group the method or agile flavour he’s using with his current team, it’s called Crystal and sounds interesting. It sounds like the emphasis of crystal is the continuous improvement and customisation of the process to your team and project’s needs. A quick bout of googling tells me that the following has not much directly to do with Crystal. From what I’ve been able to gleam (and it’s not much) Crystal is primarily focused on improving methodology frequently, aiming to minimise it’s weight.

The main point that Ian brought up that caught my attention was the move from the pure priority prioritisation to a more whole system or breadth approach with incremental refinement. Purely working of stories by priorities, apparently leads to systems that have a lot of work and attention spent on apparent high priority sections while those features and functions that the client may deem as a lesser priority are essentially neglected, typically tacked on the end of the project. This can lead to seemingly unfinished projects (my conclusion).

The three thirds approach that Ian described seems to encompass the entire system with increasing levels of ‘focus’. The first phase is the ‘Walking Skeleton’ this is just enough of the entire system to get something going from a technical perspective, this might take up most of the ‘framework’ stuff that one has to do to get a project going. Many people likened this to an iteration 0, which doesn’t deliver much or any business value but is necessary to build something you can demonstrate.

The next phase delivers the ‘First Business Value’ taking the walking skeleton and adding enough to actually add to what the business has, making a contribution.

Here is where my notes get a little woolly and I wish I wrote this post while I was in the room! The final phase adds all the other features, improves on the initial business value, works on feedback from the client on the second phase, and perhaps includes changes to requirements.

From the weakness of those last two paragraphs, I think I’m definitely going to do a little more research, so check back for a bit more bulk in later posts.

This notion of increasing the focus with subsequent iterations really did intrigue me, and I’m definitely going to see how I can apply it to our next project.

altdotnet London September 2008

So, I’ve just got back from the altdotnet conference in London. This is my second altdotnet conference, and it was as good as I remember. You could see people had moved on, and it was nice to see that altdotnet has had its affect on uSwitch.com in a positive way. 5 attendees were currently employed by uSwitch, that’s a great improvement from the 1 from last year.

As always at open spaces events, I do wish I was less passive in my contribution, but every time I did pipe up someone else got to where I was going but probably more clearly than I would have. Maybe by the next conference blogging will have helped improve my confidence and clarity.

I aimed to learn about acceptance testing and how I could move that piece of the agile puzzle forward in my organisation, and luckily Gojko Adzic was in attendance. He literally wrote the book on using Fitnesse for acceptance testing, and clearly had lots to say. I attended (accidentally) two sessions on acceptance testing. Our BDD talk quickly moved on from the standard definition argument to a broader discussion on how ‘Behaviour’ should inform our acceptance tests and involve all stake holders rather than just be a developer concern. I think I’ll separate out my write ups on the different sessions I attended.

Ian started the conference with a quick demo of the Park Bench method of a open space session, and chose the controversial subject someone had brought up in the previous nights session brainstorming exercise. Is altdotnet = faddotnet. The park bench quickly ended up being the same old are we anti msoft, should we be, why are there so few of us, why doesn’t anyone else care, this session was the closest to an alcoholics anonymous I wanted the event to get. (We’re only ever two step aways from that in an open space conference).

I really did start wishing we stopped concerning ourselves with how we’re perceived. It seems only ever really to be a concern of people who are unsure they want to wear an alt.net badge. To them I say, don’t! But if you’re interested in the things we do, and interested enough to read our blogs, attend our meetings, then you’re welcome. I think the difference between an alt.net’er and a microsoftie, is the just the plain old giving a damn. Enjoyng what we do for a living, with just a little mix of compsci for added goodness, but not so much that we end up being java devs 🙂

It was also good to brush up on some of the basics of Agile and DDD, just to remind myself on what I find so interesting about my job. Thanks guys! Now for me to work on giving some back….