By Nathan Donaldson
Tags: Agile , Development
On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool to support teams to run Agile retrospectives, which we call Scrummaker. This series of blog posts records the two days: what we made, and how we did in.
A little context: Boost is a team of designers, developers and Scrum Masters, who have been working with Agile for the past six years or so. As well as building websites and custom software and offering Scrum services and coaching from our Wellington office, we’ve recently opened an office in Shanghai offering Scrum training and coaching. Nathan Donaldson is Boost’s managing director and the Product Owner for Scrummaker.
As part of the whole Scrum ethos, I’m timeboxing the writing of each of these posts to 20 minutes, so if the brevity leaves you curious, feel free to get in touch for more detail.
At the end of the day on Wednesday, the team met (for strict 30 minute timebox) to thrash out technical decisions we felt we needed to make in order to get off to a clean start on Thursday morning.
We grabbed post-its and had two minutes to scribble down the things we wanted to discuss. These went up on a sheet of paper, were quickly grouped, then we dot-voted to pick what we wanted to discuss the most. We agreed to spend 8 minutes discussing the highest priority item, and 4 minutes on each of the other issues, until we ran out of time.
The highest priority post-it was How do we avoid design blocking work. Balancing the needs of Scrum and design is something we’ve worked hard on for several years now, so it’s not surprising that with a two-day development period this came to the fore.
After discussing the issue, we came up with a series of actions:
It turned out that this discussion also knocked of the second-highest post-it, CSS framework, so we moved on to Integration. Here we agreed that:
Next we quickly covered off Testing, agreeing to stick to our usual practice of Behaviour Driven Development, and to use RSpec and Cucumber
The Hosting post-it got the one-word answer Heroku.
JavaScript was up next. We knew that Scrummaker was going to be heavily interactive, and that JavaScript would be very important. We agreed on Unobtrusive JavaScript and that we’d discuss this in further detail on the day as it came up.
Finally, we agreed on a zero critical bugs policy – new development would always come second to fixing critical bugs in existing features.
At the end of half an hour, we felt prepared for the Project kick-off at 9am the next morning.
