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
- 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?