Scrummaker: The technical discussion

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.

Post-it notes with topics for our technical discussion

Post-it notes with topics for our technical discussion, grouped in priority order

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.

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.

Related Posts:


  1. Kane
    Oct 18, 2012 @ 18:55:11

    Just to let you know the links aren’t working. The link takes me to:

    And the link takes me to:

    Just looking at the source, I noticed there are too many quotation marks around the urls … Cloud Climate Not sure how they got in there, but removing the double quotation marks will likely resolve the problem.

  2. Nathan Nathan
    Oct 18, 2012 @ 22:20:21

    Thanks Kane – fixed now but will find out tomorrow how those extra quotes are getting in!

Leave a Comment