philwilson.org

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.

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?

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!

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?