A Year with SCRUM

It’s been a year we implanted Scrum (or something Scrum-like) as our development management methodology in the company that employs me atm. Today we said goodbye to the 12th sprint/month, which was a great chance to make a “1st birthday of Scrummy boy” party as well. Besides the regular Sprint-end presentation I presented also a look-back yearly review. Has it worked ? What do we do differently ? What have we learned ?

Year ago

We were in a situation that reached some critical-mass. Maintenance of actual products – unfortunately quite complex, running critical new development, prof. services requests hitting us daily, ever changing priorities, recursive interruptions, ill communication, organizational changes. All this with limited resources. Stress and frustration for every one. Gannts and quarterly planning surprisingly didn’t help ;)) We thought we did extreme programming. We did extreme… just in other aspect :) A small dev-team uprising was unavoidable.

…blah..blah…and so we decided to go with Scrum as project management tool. Backlog, ScrumMasta, Sprints, Daily scrum… Because anything was better than the status-quo the installment was smooth and accepted. Personally, I don’t like very much the way Scrum is promoted. And for the book: Ken Schwaber: Agile Project Management with Scrum… ok, but no big thing. Importantly, what is very sound and pragmatic are the the Scrum concepts. Of course, as we are somewhat creative people, we could have never been orthodox followers. Moreover it’s just about project management so you have to complement and stir it with other concepts (An Agile Roadmap)to get the most tasty and nourishing soup for the complete development process.

Year after

We are team of 6 devels, quite cross-functional. Very flat structure. New development vs. professional services,support, and maintenance goes 1:1. Besides the basic principles, we came up with some Scrum patches and local customs:

  • ScrumMaster is one of the devel team, as his part-time job. This eats max 20h of his time, which is sufficient for the duties.
  • Rotating Scrum Master -1-3 times each; to avoid stereotype.
  • PPTS – The tool. Web based, GPL, SCRUM, extreme programming. Very useful.
  • Scrummaries – each member writes a mail with a brief description of his achievements, status, open points at the sprint-end. It’s helpful later on to have such info persistent.
  • Half-time round-trips – SM and PO has a short talk to each devel get the big picture view on the progress. Some steering is usually done here.
  • Emergency time slots – we experience cca 15% of unpredictable situations, so-called emergencies. Therefore, we add a constant-time slots to each sprint.
  • DailyScrum mailinglist – as the team cannot be daily together, the missing person ports the “daily answers” to the mailing list.
  • Bad task” – unpredictable, NP-hard, R&D, we fix time per sprint.

After all, I have to say this approach worked for us quite well. The major improvements came in process transparency, much better planing, much much more relaxed development and thus also efficiency. And not so “agile” as before :)

So can I recommend this? Look at your problems, your team, the project and company culture. And make your judgment yourself.