Last month I saw a great presentation by Gil Izarry of Constant Contact titled Beyond Scrum of Scrums: Scaling Up Agile with Kanban.  I have attended a number of “scaling agile” presentations and I often come away disappointed by the lack of insight.  In contrast, I found myself agreeing with almost everything that Gil had to say, and I found that it matched pretty closely with our own process and with a similar presentation from the Google Chrome team.  Gil's slides are here.

Constant Contact gives us a bridge between the world of corporate agile, and the world of startups.  “Agile” as a word has been co-opted by corporate consultants and trainers.  Corporate agile processes are often about scaling and training and predictability, but they often fall short of being agile.  On the other hand, startups are almost always agile.  They need to be.  They don't even talk about it.  Sometimes, they have problems scaling and taking on big projects.  Constant Contact is now pretty big.  Gil talked about having 13 development teams contributing to each release.  So, they are big enough to really appreciate what the consultants describe as Agile process.  On the other hand, they are still basically a startup, using rapid release cycles to claw their way to the top of a very competitive Web product category.

Let’s look at some of the good stuff in the presentation:

They adapted scrum to eliminate the big rush of testing and bug fixing stress at the end of an iteration.  They adopted some Kanban techniques, and they also did two things that Assembla does in its iterations.

First, if a feature is not ready to release, it skips the release, and goes into the next one.  The Google Chrome team also uses this technique, and they support it in code with flags that can turn a new feature off if it doesn’t pass release testing.  You can do it with flags, or you can do it by deciding what to approve or merge from your various source repositories.  I actually think this is a major trend, which I will call “Backward Agile”.  Instead of planning the entire release in advance, you decide near release time what you want to include.  This is a lot less management intensive than planning and estimating the release scope in advance.

Second, they add and remove tasks as the iteration progresses.  Gil presented a picture of this process.  In the graph below, each task is a horizontal line which starts somewhere in the first half of the release chart, and goes through various stages.  You can see that about halfway through, the total number of tasks drops, as a bunch of features that were in the User Story and Wireframe stages are swept into the next release.   Features continue to be trimmed as the release converges.

They moved from planning poker style estimating, to very simple estimates.  Each task gets tagged as “Small” “Medium” or “Large”.  This takes little time, and they can get a pretty good estimate by calculating the average time required to finish each size of task.  We’re building this into our product.

Finally, they have an "All at once planning meeting" between all of the teams to work on dependencies.  Each team reports things that they are waiting for that depend on other teams, and the other teams report on the status of those things.  It seems to me that “dependencies” is a much clearer focus than a typical “scrum of scrums”, which just brings agile back to all of the problems of hierarchical management.  I have argued that most  of the problems in scaling software projects come from dependencies, as noted here.