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.
Scrummaker: The technical discussion
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:
- Collaborative wireframing to kick each story off (then being able to start work on dev and design concurrently)
- Use the Foundation framework from Zurb
- Pair programme to implement design
- Start with very basic design, and finesse later
- Not use any text in images (this is also in the interests of internationalisation)
- Use Sass
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:
- Master always has the working product on it; development is done on feature branches and then merged.
- We’d set up a CI server, a Git repository, and use Cloud Climate, Semaphore, New Relic and Airbrake.
The Hosting post-it got the one-word answer Heroku.
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.