Cupcakes vs Gateaux: How Scrum Helped Christchurch City Council Deliver

Christchurch City Council recently launched their new website built on the NZ Government Common Web Platform using SilverStripe CMS and Framework. SilverStripe's Senior Agile Project Manager Tony Dale-Low explains how the council was able to deliver this ambitious project in just 12 weeks... 

The Scrum framework is a beautifully simple thing and intentionally so. The core idea is that it provides a ‘lightweight structure’ to support teams delivering customer value in short periods of time.

Unfortunately when implementing the Scrum framework there is a danger that teams go overboard adding additional details to 'the Scrum process', or teams may think that if conditions are not perfect then that may be a barrier to them starting projects using Scrum.

I have recently been working with Christchurch City Council in New Zealand coaching one of their project teams using Scrum to help implement their new website in a very short timeframe.

In the initial stages of the project the team were facing a huge challenge. A short deadline, limited experience with the product to be developed, lots of on the job learning and a mountain of work. Subsequently the team were struggling to focus due to the magnitude of the task ahead.

The Scrum process started with a sprint zero. This primarily consisted of 2 half days of Agile and Scrum team training. The training covered the basic Scrum framework but also covered what it means to have an "Agile mindset". During sprint zero, backlog refining sessions were also held to start getting a good enough backlog for the next 1-2 sprints.

Sprint 1 commenced in what many Scrum practitioners would say were less than ideal conditions:

• 1 large team with 16-18 members, consisting of a mix of business and technical people
• No dedicated Scrum Master
• A Product Owner (PO) with a very busy day job (initially had limited time with the team)
• A mix of technical and business deliverables with some rough acceptance criteria
• Not all co-located
• Limited prior experience with Agile
• No experience with SilverStripe (the CMS being implemented)

The result

After the first 2 weeks the main feedback from the team was that they could now focus. Scrum helped the team limit their work in progress, and for the first time they could all agree what the team focus for the next 2 weeks was going to be.

Scrum quickly highlighted areas of the project that were not going as quickly as was needed and adjustments could be made to correct this.

Scrum increased the team communication by providing communication structure through the daily standup and ‘after party’ conversations. The product owner set-up ‘clinics’ after every 2nd standup during times when her availability was limited which helped the team get rapid feedback from the PO.

Scrum encouraged the team to break features down to small work packages that could be delivered within days rather than weeks, this provided quicker feedback to the product owner and encouraged more prioritisation.

From the less than ideal start, the team used the retrospectives to continue to adapt their practices. Through the retrospectives the team made a number of improvements over the short 12 week project timeframe (6 x 2 week sprints).

Team improvements included:

• Restructuring the project into two teams (design/development and a content focused team)
• Co-locating the team
• Changing their planning approach
• Improvements on how the team collaborated day-day
• Refining testing and story sign-off process
• Improving their story writing and acceptance criteria
• Other tweaks that helped their process

Get the basics right

When you are starting Scrum, especially in a less than ideal environment, it’s important that you don’t compromise the core principles:

1. Avoid 'wagile' (waterfall-agile) - refrain from ‘design’ in one sprint, ‘development’ in the second, ‘test’ in third
2. Make sure the deliverables are specified as customer focused outcomes that take a number of disciplines to complete during the sprint (so dont ‘wagile’ within your sprint either)
3. Use the standard Scrum meetings to really boost team communication (stand-ups, planning, reviews, retrospectives)
4. Limit your work in progress - agree your deliverables and allow the team to focus
5. Timebox your sprint and keep to a regular rhythm
6. Use the retrospectives so that the team can refine and improve their process

The project successfully met the challenging target of building a working website in six sprints. In my opinion this would not have been possible using a traditional project management approach which does not foster collaborative teams in the same way Scrum does.

Although the Scrum conditions were not perfect at the start, the team took ownership of the process and continually refined and improved how they worked together which in turn helped the team deliver a great result.

The approach gave us the scaffolding needed to deliver a new website in a short time - I'm not sure we could have done it otherwise. We've learnt from Agile the value of "swarming" a problem or issue to get it over the line and breaking stories down into manageable/realistic chunks. The stories we have on our slightly less busy kanban board now are quite different to what we wrote in Sprint 1 - less clunky and more to the point. The other big win for me is the team getting to grips with "good enough" and focussing on delivering a "cupcake" quickly as opposed to a "gateaux" over a long time, which we could have only achieved using the Agile approach, which our customers will benefit from. 

~ Dana Burnett, IT Service Manager - Digital Channels, Christchurch City Council