Scrum as a fully-fledged methodology has been around since the Nineties, as an idea since the Eighties, and has sired many offspring in that time. In some organisations these offspring are given a test straight out of ancient Sparta, where legend has it that newborns were left on a roof to fend for themselves overnight to ensure that only the strong survived. Fast forward two thousand years and a lot of Scrums are also left to fend for themselves and die within a few sprints.

The Happy Birthday goes to the Westfield scrum process. I note that with sprint 42 starting shortly we are exactly two years since sprint zero. It’s fair to say that our scrum process has had to evolve quite a bit since sprint zero, and our organisation with it, so I think it might be worth taking a snapshot at the end of its second year of life.

At the very top level we have a bunch of people coming up with good ideas all the time. Some of these are very large, such as rolling out the platform to the US, some are much smaller, like ways to boost product search indexing. These ideas can come from anyone: the head of the company, a developer, a help desk person, etc. Each is discussed on its merits and if enough people agree (we have a weekly review meeting) it finds its way to the start of the product funnel. An idea’s progress through the funnel can be best described as Darwinian: only the stronger ideas push through to the next stage where they form a cross-disciplinary feature team, where strength is measured in the number of people who care about the idea enough to see it progress.

Once a feature has been created, it is assigned to a cell and stacked in priority order to decide what that cell will work on next, with the possibility that a strong new feature can come to the front of the stack and displace other features. A cell is the group of developers, BAs and QAs who will turn the feature into a set of Epics and break these down into Stories, and then schedule these into the product backlog assigned tentatively to a future sprint.

The way we currently work is that we have four cells of usually around four people, which is looking like a good number: intra-cell communication is pretty efficient and the team is still large enough to deliver a substantial new increment of the feature every sprint. We have settled on a three week sprint since this has yielded higher throughput than two weeks (less time spent on sprint set up and tear down ceremonies, plus it’s long enough to tackle a big vertical stripe – which becomes more important if you have an application architecture of more than a few interconnected services).

The cell concept is also scalable. Individuals can and do move between cells to promote intermixing of ideas, which makes it easier to spawn a new cell if the development pipeline needs to be widened: the new cell can be picked from existing members of other cells, backfilling with new hires, or even outsourced. The crucial thing is that the new cell adheres to the same communications processes as the existing cells so everyone still has an idea of what’s going on across the entire team.

However, scaling cells leads to the standard problem of how to keep everyone informed: inter-cellular communication is a challenge. We came up with two ways of solving this, having discounted the traditional Scrum of Scrums concept since this only involves a subset of the team (we still find it useful to do a SoS that pulls in representatives from the development team alongside customer service, retailer management, etc. but by its nature the SoS only dives into the salient highlights). One idea was to have a single scrum with everyone saying their piece, which only works up until a certain size after which individuals tend to zone out and miss details. The approach we finally settled on was to form an inner circle of cell representatives (an honour that rotates through all cell members) to give their cell’s status, surrounded by an outer ring of everyone else in the team. This lets the entire team dig into particular issues if needed without the stand-up taking fifteen or twenty minutes.

The backbone of the process is JIRA, which has evolved from a bug management tool into a highly flexible story manager through the Greenhopper plug-in. Part of the problem in the early days was that story and sprint planning was entirely divorced from story management, the former being done in an Excel spreadsheet, the latter in a bug tracking tool, leading to the potential for endless confusion and miscommunication. We brought in JIRA and customised the workflows to add in the approval steps our organisation needed and in short time had the business people talking the same language as the development team, planning sprints as easily as dragging and dropping stories from one sprint to the next. Sure, the software costs money, but next time you’re in the middle of a crisis meeting on who committed to what, when, just jot down the collective cost of having all those people in the room for the hour. It breaks even pretty quickly.

As I said previously on Westfield’s Agile approach, it’s not necessarily the steps of Scrum that matter (though there are fundamentals that you need to keep), but it’s Scrum’s introspective ability to evolve itself to fit the organisation. I would now add its ability to radiate information effectively as a feature of successful Scrum. After all, what’s the point of being in a team and being in the dark?