Monday, September 21, 2015

The Unofficial Scrum Checklist

After finishing the book "The Checklist Manifesto: How to Get Things Right " from Atul Gwande I was thinking about a number of checklists that I am using on a regular basis myself. One of those lists is the unofficial Scrum Checklist by Henrik Kniberg.

The Scrum Checklist is a simple tool to help you get started with Scrum, or assess your current implementation of Scrum. Note that these aren’t rules. They are guidelines. A team of 2 people might decide to skip the daily Scrum, since they are pair programming all day anyway and might not need a separate meeting to synchronize. Fine. Then they have intentionally skipped a Scrum practice but ensured that the underlying purposeof the scrum practice has been fulfilled in another way. That is what counts! If you are doing Scrum it might be interesting to have the team go through this list at a retrospective. As a discussion tool, not an evaluation tool.
click to enlarge
How to use the checklist

Joe: “For this retrospective, I’ve brought a useful little checklist. Is there any of this stuff that we aren’t doing?”

Lisa: “Hmmm, let’s see. Well, we’re certainly missing Definition of Done, and we don’t measure Velocity.”

Joe: “Well, ‘Definition of Done’ is listed under ‘Core Scrum’ so it seems pretty important! Velocity is listed under ‘Recommended but not always necessary’ so let’s wait with that and start with the core stuff.

Lisa: “Look, we’re also missing ‘Delivering working, tested software every 4 weeks or less’. That’s listed under ‘The bottom line’! Makes sense, because marketing is always complaining about that!”

Joe: “Maybe a concept like ‘Definition of Done’ could help us take on smaller bits per sprint and get stuff releasable more often?’

Lisa: “Good idea, let’s give it a shot.”

How NOT to use the checklist

Big Boss: “OK team, time to see how Scrum compliant you are. Fill in this checklist please.”

Joe: “Boss, I’m happy to report that we are doing everything. Well, everything except Sprint burndown charts”

Big Boss: “Bad, bad team! It says here that you should be doing those… er…  sprint burning thingies! I want them!”

Lisa: “But we do 2 week sprints and almost always manage to deliver what we commit to, and the customers are happy. Sprint burndown charts wouldn’t add value at this stage.”

Big Boss: “Well it says here that you should do it, so don’t let me catch you cheating again, or I’ll call in the Scrum Police!”

You can download the PDF version from Henrik's website.

Read more…

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.

Read more…