Over the course of the last 3 months, I have been coaching my team through a transition to scrum development. This hasn’t been simply an exercise in trying something new for the sake of something new; this move has been an attempt to alleviate the problems caused by years of technical debt and unsustainable work practices that have resulted in significant points of pain for our organization. While I would certainly like to get into the why (and that will almost certainly be a topic for a different post), I’d like to focus on some of the details as to how we have chosen to execute the transition.

From the start, it was a given that we were not going to be able to simply change the entire team and all of its projects over to a new process overnight, so we were forced to get tactical. I designed¹ a process by which we might iteratively advance our current process from “agilefall” to “something not entirely unlike scrum”.  I selected two projects to be pilots based the criteria that:

1. The development team was minimally distant from the client
2. The project team was not especially change averse
3. The attributes of the project looked suspiciously similar to those of projects that have caused us problems in the past

Note that none of my criteria spoke to the inevitability of success–I did not choose projects based on easy wins or certainties of success. Either this process would start showing improvement with projects that were representative of our normal projects, or it would not be considered a success; no layups to be found on this list.

I next put together a list not entirely unlike a project backlog that consisted of features of the scrum framework that weren’t currently a part of our development strategy–this was the easy part, the list could be fairly accurately summarized as “all of the attributes of team practicing scrum.” The tricky part was grooming the list; organizing the list from maximum business value to least valuable.

Maximum value often gets oversimplified. I have sat through numerous explanations of agile strategies during which the speaker drills home the simple and untrue fact that “maximum business value” means “makes the most money” for most companies. Typically, this is reinforced by trite examples like “you can’t purchase things without a shopping cart, so start there” or “you can’t buy what you can’t see, so build a catalog.” Our business value had to be broader than that; our algorithm had to take into account obtaining buy-in to progress further, enhancing quality, and taking a longer view of business value by saying that feature A might make a big impact now, but feature B will allow our overall impact to be greater.

Using this broader (and I would argue, more accurate) definition of “maximum business value” I organized our list of changes by priority and specified some important features of our transition:

• Each iteration would last 1 month; enough time for two of our 2-week long work sprints to happen in each project so that we get a good sample of hour our latest changes work in “the field”
• The members of the team acting as scrum masters would meet with me once per week during each iteration
• One of these meetings would be used as a retrospective for the previous iteration where we would course-correct
• One of these meetings would be used as a kickoff for the next iteration

And just like that, we were off! In my next post, I will get more specific about kicking off the iterative version of these two projects as well as how that first iteration went.

 

---

¹ I’m sure I’m not the first one to come up with this “clever plan”