In my last post, I railed against the list makers and pondered why people are still so keen to pursue such fine grained detail. I hinted at something I’ve been thinking about for a while, that it comes down to who your working for.
Probably the biggest benefit of working so intimately with our customer has been the amount of work we don’t undertake. The problem with this is it’s very difficult (read impossible) to measure. The customer may be very happy, but there’s nothing to show for it. In fact, you could argue this works against us as we’re doing ourselves out of a job.
Managers can only evaluate our productivity on the work we do. Where I work our project manager is required to issue a progress report every 2 weeks. It consists of our spending (which I feel is quite justified), a list of all the stories we’ve been working on, their status and our velocity (in story points). If something is taking a lot longer than expected she is required to explain why. A lot of time is spent analysing our progress this way, but very little time getting feedback from our customer (shouldn’t there be a customer happiness rating in this bi-weekly report?).
However, I have sympathy with my managers. It’s their job to report on our progress to their managers, justify our existence and protect us from people looking for excuses to cut budgets. This is where I feel the irrational desire for measurement emanates. Somewhere up the line someone who is too busy to get their hands dirty with the detail wants a really simple way of diagnosing the health of a project (”Costing 50K a month but only delivering 20 points? Hmm… clearly something wrong there.”). If the velocity suddenly drops, does this necessarily mean there’s something wrong? Unfortunately anecdotal evidence or gut feelings don’t translate very well to very hierarchical structures (which I think says more about the structure).
Imagine this scenario: A bank has a crucial trading system which requires no development work for the foreseeable future. You have a small team of domain expert developers who’ve worked on the system for a long time, but now having nothing to do (they’re not doing nothing though, being enthusiastic devs they’re investigating new technologies and better ways of doings things as well a spiking new ideas which could improve the system). A manager sees a report which shows they’re no adding “no value” and makes them all redundant. Very soon after there is a problem with the system, it falls over and all trading has to cease until its fixed. As all the domain experts are no longer there it takes a very long time and the bank loses tens of millions. If the manager had kept the team on they’d have fixed it within a fraction of the time and saved the bank a fortune. If, rather than looking at productivity reports, the manager had appreciated the value of the system to the customer I doubt he would have made the decision he did.
Customers couldn’t give a stuff about velocity, story points or any other spurious measurement technique you care to come up with. They do care about you asking them questions and always seem delighted to be involved when we want to show them something or give them some feedback (tip: it’s important that this never takes more than 5-10 minutes). If we’re having problems we don’t try and hide them, we explain them to our customer in a way they’ll understand (so far they’ve been very understanding). Ultimately (and directly in our case), it’s our customer who’s paying the bills, not our managers.
If our ultimate goal is to provide as much value to our company as possible then its certainly not by trying to measure the highly subjective productivity of the developers*. If there’s any measurement to be done we should be focusing our efforts on how much we’re satisfying our customer’s needs. There are many ways we could approach this such as seeing how they use our software (or, more importantly, don’t), asking them to provide feedback, imagining if something we built was taken away and how it would impact them, roughly estimating how many people it would take to do the jobs our systems replace and so on. However, I feel it will take some people a lot of convincing that this is the way to go…
*Which, as Fowler points out, we cannot measure anyway
The biggest lesson I’ve learnt is that the whiteboard is by far the most effective method of communication available. Requirements gathering with the customer in insanely fast times, meeting notes all can see and contribute to and the great thing is, they stay there for a few days where we can all see them. If I could programme on a whiteboard I would.
Meetings
Unsurprisingly, in our first retrospective together, Mike said he felt there were too many meetings. Essentially, this was because of the sprint planning meeting which involved a lot of estimating. We’ve now split the meeting in two - a prioritisation meeting with Mike in the preceeding sprint and then a planning, analysis and estimation meeting when we begin the sprint which we have at our desks so we can ask Mike questions if we need him.
The power of perception
On a very positive note, Mike is delighted with our progress and is feeling things are really getting done. Of course its not like we weren’t doing anything before (in fact, our team is now barely a quarter of the size it was before we moved in with them) its just that now they are deciding what we do on a bi-weekly basis and seeing the results in very little time.
Team Leading
I’m still hardly doing any coding, but that’s OK, its a bad idea to “own” any work as I can’t guarantee I’m able to complete it. When I do have the time I am using it to pair programme. This way I spread knowledge and best practices and can be across as much as possible without being too controlling.
This week the project manager arrived to complete the small team I am in. What makes our project interesting is we are going to be “embedded” with the customer (who is internal). As far as can tell this is supposed to be the ultimate environment for successful agile software development. I intend to write about my experiences here.
The other interesting news is I will be the team leader. Whilst I was a team lead in my previous job it was really only by default and I intentionally avoided this position when I came back from my travels. Now I’m more than ready, but there will be plenty of challenges along the way and I’ll do my best to write about them as well.
We’ve completed one sprint and already I’ve found the customer (to be known as Mike) to be very resistant to getting involved in the process of creating their product. Mike clearly has a very busy job and is hoping we’ll just be reporting back once every couple of weeks with lots of amazing things that exactly fit his expectations (as we have amazing mind reading skills). We’ve asked him to get involved with planning, retrospectives and stand ups and he’s expressed a keen desire not to be involved. It will be very interesting to see how we will get around this resistance. To create brilliant software the customer has to be involved and I will consider it a personal failure if we do not succeed in drawing them in.
On the team lead front, unsurprisingly, I have found I am spending very little time coding and have been struggling to keep on top things. You simply cannot do everything that is asked of you so to keep my head above the water I’ve been concentrating my efforts on recognising what is most important and doing that well. This is quite a skill as some people are very good at making a lot of noise, whilst other more important issues may timidly bubble under the surface (waiting to explode like a geyser). I’ve also tried to delegate as much as I can to the other members of my team which makes me feel uncomfortable, but I know it has to be done. The urge to constantly check up on their progress is hard to resist but they’re good people and I trust them so I’m doing my best not to be too much of a nag.
Over the next few sprints I’ll be focusing on getting Mike more interested in taking part and bringing our PM (who is new to agile) up to speed. Hopefully I’ll also get to cut a bit more code…
