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?