Wednesday, September 02, 2015

Scrum beyond Software

In the past I used Scrum and other Agile methods very successfully on Software Development and Business Intelligence projects. That these kind of projects can benefit tremendously from Agile methods is covered in many books and articles across the globe. Of course, it only made real sense to use Agile methods when most of the requirements were not known upfront, the requirements were not stable during the project and incremental product development was possible. And of course, the best results came when the whole organization was willing to embrace Agile and not just the development team.

The last six years or so I kind of specialized on large Data Migration and Legacy System Migration projects and used Scrum on most of them. With a few add-ons and guidelines, which I will cover in a follow-up article, I found Scrum to be the ideal framework for such larger migration projects. This is kind of a logical consequence because a large Data Migration or Legacy System Migration project is typically a combination of multiple Software Development and Business Intelligence projects (ETL). The things that come on top with such projects are the new business processes, the data clean-up and the actual crossover from using the old system to the new one. Large migration projects typically mean multiple teams, so scaling Scrum becomes a topic as well, but this is no different from any larger Software Development project with multiple teams. You could use for example the LeSS Framework for guidance.

My latest project was an actuarial modeling project for a large insurance company (See 14 Principles of Agile Actuarial Modeling). Actuarial modeling applies mathematics and statistics to assess risk in the insurance and finance industries. Building actuarial models for clients, including internal clients, is a difficult and complex task. Much has been written on how to approach the challenge of managing a modeling project, and almost all of this guidance describes, more or less, a Waterfall model. They may use different terms, but it is the same: specification, design, development, testing, and implementation.

It's no surprise that actuarial modeling projects that follow this method suffer from similar issues as software development and BI projects that are managed this way. My recent project was no exception. Therefore, we decided to implement Scrum for managing the modeling project. I was charged with helping to make the transition. During the transition and after the first few months of running it with Scrum, I learned many new things. Although actuarial modeling has some similarities to software development, it is not quite the same. But Scrum fitted very well for us, and we all were very happy with the results.

This experience got me curious about what was known on the use of Scrum in other areas as well and I started searching for some well-documented case studies. These are a selection of my findings:


Marketing teams can use Scrum to organize their campaigns and draw readers from the top of the funnel down toward conversion. Campaign phases can be broken apart into sprints of varying scope, either dealing with the entire funnel stratum or dealing with a set of content that needs to be created. Marketing-software company HubSpot has used Scrum to achieve greater transparency and prioritization in their own campaigns. See Get Agile: Running a Marketing Team Like a Startup


Wikispeed’s 100 miles-per-gallon, road-legal prototype car is a nice example of using Scrum to design and manufacturing. Wikispeed founder Joe Justice used his 44-person team to develop a functional prototype of the car in just three months. He used weeklong sprints to produce a new iteration of the car every seven days until completion. See


Lonely Planet’s Travel Guides
Prior to Scrum, the development of a book was very sequential and required many hand-offs and took a long a time to get a book out from conception to publication. Now they involve all players needed to put a book together (writers, graphic artists, desktop publishing, marketing, editors etc) and incrementally develop the book chapter by chapter following the Scrum framework.
Posted on Wednesday, September 02, 2015 by Henrico Dolfing