Agile platform development. The problem.

  • Article

Classic scrum

Our team uses Scrum to manage it's software development. A key tenet of Scrum is that there should be a product manager (PM) who own's a backlog (that is, a ranked list) of customer facing stories. Scrum organizes development work into sprints, typically 3-4 weeks long. Before each sprint, there is a sprint planning exercise, where:

  • the PM communicates the stories to the engineering team
  • the team tell him or her what's possible and where the engineering dependencies are
  • the team estimate how long it's going to take to build each story, and, by identifying 2-3 day tasks required to develop that story
  • the engineering capacity for the sprint is worked out, taking account of vacation and other activities
  • they all agree what the main theme of the sprint is - what's the overall goal of their work this time round
  • with all that information the PM and engineering team narrow down the scope of stories, re-rank, and draw a cut line

Need - build a (tooling) platform in an agile way

Now I'm part of a team in the business of creating a tooling platform, including tools built on the platform to build other tools that work on that platform (tools to build tools). And my job as a program manager is to come up with those stories that can be used to drive sprint planning. And I also want to do it in an agile way, so that it can be managed by the same process, and in a way that fully exploits the creativity, ideas and expertise of all members of the engineering team for whom I have the deepest respect.

Problem 1: Mind the gap

A problem we've identified with classic scrum is that it doesn't take into account the often large gap between business need and the software solution proposed to fulfil that need. Indeed, the process assumes that somehow the product manager will pluck out of thin air customer facing stories which are fine-grained enough to make sense to feed into the sprint planning process. That may work if the project is about adding new functionality to an existing website, say, but with a platform it's not so obvious how this should work.

Problem 2: Two or more customers

When building a platform, you've got two customers at least. You have the customers who use applications built on the platform, and you have the developers who use the platform to build (author) those applications. I tend to call these users and authors. With a tools platform, there's also a third customer, which is the one who uses the applications built using the tools built on the tooling platform. This impacts the way you write scenarios/stories, specifically there are stories targeted at the user and stories targeted at the author. It also impacts the meaning of 'agile'. Platform has to be delivered in time for the authors to build the applications on that platform that their customer needs. If the author is running an agile process to build their application, then you're going to need to understand their stories some sprints before the author is going to implement them, so that you can get the platform pieces in place for them to build on in time. Or you try to do it all at once, but there lies a hornets' nest.

 

After 5 years experience of doing this in Microsoft, I'm starting to get a handle on a process that seems to make sense, and I thought it would be fun to try and relate that process here and see what others think.

So watch out for postings with a title of the form:

"Agile platform development. ..."

I'll also tag them as follows...

Technorati Tags: Agile platform development