Estimating is good for your health

Matt Jukes has written a post called Don’t do Agile. Be agile. Or something. where he describes how estimating stories has not worked for them at the Office of National Statistics.

I think there is a more important reason to do estimation that just release planning, and that’s people management.

Over time, estimating allows you to create a sprint which is neither too daunting nor too trivial, and to build a good team cadence. A sprint with too much work in it can be depressing and ultimately slow down delivery, a sprint with too little runs the risk of falling foul of Parkinson’s law.

You could argue that if you have a good, committed team who are always up for the challenge of whatever’s put in front of them then it doesn’t matter – I’d argue the opposite and that you’re at risk of burning out your team.

Velocity, paired with your observations of the team, will give you the data to be able to work out if they are maintaining a sustainable pace or not.

As much as I am not a fan of Pivotal Tracker, it’s taught me that the burndown is not as important as having a graphical view onto historical velocity. Did the team deliver fewer points this sprint? Why? Was it story-related or human-related? If their velocity has been solid and steady for a long time, are they ready to step up, or do they need a rest? Most managers have a gut feel for these things, but having the data to be able to back it up makes it easier to discuss in retrospectives and planning sessions.

Estimation is not always easy, but so long as you don’t put too much importance on getting the “right” estimate, and so long as it’s really treated like an estimate, it can be extremely valuable for both release planning and maintaining the long-term health of your team.

Keep Posting

Pete has some good advice for writing a blog that lasts: Keep Posting.

I should post more, but I’m frequently paralysed by choice. I’m a software dev manager, so I’m interested in down-in-the-mud-coding, software quality, personal and team productivity, agile techniques, web analytics, business value and return on investment.

That’s not to mention the fact that my two-year-old is finally sleeping at night and I’m starting to pick up videogaming again (did I mention I have a 3DS so that I can finally complete Ocarina of Time? The console is physically delightful and OoT:3DS is the best version Nintendo have made of possibly the best videogame ever).

Also: Kindles, tablets, portable computing, mobile apps vs. web. Someone at work described me as ‘decisive, but easily distracted’. I like to know about everything; frequently, this doesn’t leave time for writing about anything.

What is Scrum?

A first-pass set of definitions, in increasing order of cynicism:

Scrum is a methodology designed to help an organisation deliver a product every few weeks rather than every few years.

Scrum is a set of rituals intended to prevent motivated, clever people from becoming cowboy coders. It channels agile behaviour into a predictable cycle of deliverables at a given level of quality.

Scrum is a set of processes designed to be adopted by organisations who want to find out if their staff can ‘do’ agile.

Scrum is a form of project management where neither the start nor the end of the project are defined.

What definitions have I missed out?

Scrum in web teams – an apology

A few months ago at the Institutional Web Manager’s Workshop I helped run a session on PRINCE2 and Scrum with Peter Barnes from the University of Reading.

I was terrible.

At the start of the session we collected several common problems that people face on their projects. From memory, these included:

  • missed deadlines
  • incomplete specs
  • feature creep
  • under-resourcing
  • no requirement to finish (managers don’t care about the project)

I failed to address any of these points, managing only to give a reasonably poor overview of Scrum as a whole, making both myself and Scrum look bad.

I plan on addressing the issues above in a series of blog posts tagged with “iwmw2010” which was the hashtag for the event to try and cover what I should have done at the time. Feel free to subscribe to the feed for just that content!

Working processes

What we’re trying to do at work:

  • test-driven development
  • pair programming
  • implementation docs on the wiki
  • code coverage stats (with cobertura) regularly generated via…
  • continuous integration (at the moment with CruiseControl, soon to move to Bamboo)
  • rapid software iterations (we suck at this right now)
  • totally transparent group activity

I think we’re doing quite well on these things, but I wonder if it looks different from the outside?