This post is the second one out of two covering my thoughts about the Solid Developers Sprint 2010 which happened this week-end. My outbound flight being delayed, I’ve plenty of time for introspection in the Madrid airport. :-)
Disclaimer: This blog post evolved as a short essay on “Agility in a Free Software Developers Sprint Context”. It is then a somewhat long read (I don’t blog often but when I do…). If you are NOT interested in at least one of the following topics:
Then, you can safely skip this post… But if at least one of those topics raised your curiosity, then brace yourself and keep reading. :-)
We have a strong tendency in the KDE community (and even the Free Software community at large) to organize so called Developers Sprints. We use them to gather contributors (despite their name they’re actually not developer only events) sharing a common project. A Developer Sprint is going on a short period of time (generally not more than a week, very often less than four days).
Now, one has to be careful not to confuse our Developers Sprints with the Sprints used by the Scrum practitioners community. They might look similar, in both cases people are trying to get as much work done as humanly possible on a time-boxed period of time. But they have a major difference: Developers Sprints are irregular events, while the Scrum Sprints are cyclic. In the latter they form the backbone of the iterative development advocated by the agile community.
As I happen to teach both how to work in Free Software communities (through the KDE student projects) and how to work with agile project management (in particular in an eXtreme Programming context), it made me wonder if the way Scrum Sprints are managed could be a source of inspiration for the way we manage Developers Sprints. And as some of you might have noticed, in the past few days I had a perfect environment for experiment… The Solid team of the KDE community had a Developers Sprint where I ended up managing the work to be done there.
As I pointed out in the introduction, our Developers Sprints are irregular events, but also you don’t have the same participants from one sprint to another. Because of that, the ability to refine the velocity (estimation of the amount of work that can be achieved by the participants during a sprint) is severely reduced if not completely void.
In turn, without the possibility to estimate the velocity, it becomes dubious that estimating the work to be done is of any interest. Indeed, what would be the point of estimating the work to do, if you have no idea how much you can handle?
Even worse, most of the time there’s nothing looking like a product backlog (a list of fine grained user stories which is “consumed” from one sprint to another) as advocated by the Scrum practitioners. At best we have before the sprint starts a list of very broad and general goals, or discussion topics (a.k.a pain points)… And, of course, we also have the closest thing to a product backlog: our bug-tracker. Which is borderline useless in such a context, it’s generally a white noise generated by the support function, where we mix what we’d like to do, what user reports (with plenty of duplicates) and so on. Of course, it has value but in my opinion not to drive a project.
Because of all that, the situation sounds pretty bad to practice agile project management during a Developers Sprint. We don’t know how much we can do, in turn there’s no point in knowing how much time is needed by some piece of work, and finally when the sprint starts we have a very partial view on what needs to be done.
Luckily, as we will see in the last parts of this essay, agile practitioners now provide us tools that we can reuse by bending the rules while retaining the spirit and values of the original rule set (Shuhari). The tools I’m proposing to reuse and combine are the Kanban (even though in an incomplete version for now), the Exploration Phase (in the XP meaning of the term) and Pair Programming.
So, how did we proceed for this sprint? Let’s stop the suspense now. :-)
Obviously, it all started before the official start date with something we’re used to for our sprints: provide an agenda. Well, we did it in a specific way: very lightweight (a few bullet points with no much discussion between the participants), split into “discussion topics” and “goals”. The reasons for it to be a lightweight process we’ll see below, I’ll first examine the splitting in two lists.
The reason for the goals list is kind of obvious: we go to a sprint to get stuff done, so we have goals. Stating them before the beginning is actually a good way for people to engage into the sprint and collectively give it a direction. The discussion topics list is here to uncover all the things we don’t want to look at. In this sense, it is the complete opposite of the goals list. When someone states a goal, he generally already have a plan in mind, is motivated by it and feels it can be done, we’re in the comfort zone. If something still requires discussion, it means we’re uncertain about it, so putting it on the table when everyone is here is the best (if not the only) way to push the issue forward and transform it into a goal later on.
We then waited for the sprint to start (remember, collecting those two lists is a very lightweight process). When everyone arrived at the sprint we then started an Exploration Phase. To do so, we got through the two lists we built. Each of the goals stated on the corresponding list got split into tasks (this is the straightforward part of the exploration). And each of the discussion topics got (surprise!) discussed… this one was less straightforward, so let’s see how we managed those discussions.
We generally find those discussion topics in our sprints, they tend to be broader though and to be mixed with “presentation topics” to give an update to the other participants about the current state… The problem is that it can quickly degenerate into a slide fest, lots of presentations and so on. So we just set a few rules:
By using such constraints we managed to keep everyone focused on the discussion. They couldn’t derail in a bike-shed because of the time running, etc. In the background I was monitoring the discussions to identify actual tasks to be done during the sprint (and added them to the tasks coming from the refining of the goals list).
Thanks to this very lean process, we managed to go through the exploration phase in roughly two hours! That’s really not much when you think about it. I think it comes mostly from the way people ended up being very focused some of the pictures taken that day clearly show that. Look at the people faces for some of those pictures, you can clearly feel how concentrated they are.
Once the Exploration Phase was over, we were sitting on a large pile of tasks… That’s obviously solving one of the cardinal sins I pointed out earlier. Thanks to the exploration, we have a clear picture of what needs to be done at the very beginning of the sprint. Now, we still need to process those tasks in a meaningful way, and remember we basically can’t estimate.
Since we can’t estimate (remember the other cardinal sins above), and that we’re in the unknown regarding the amount of work the team can do during the Developers Sprint, we’re then in the situation where we want to maximize the throughput of the team. No matter how much they achieve in the end, what matters is that they were running at full speed (in other words: sprinting). That’s why we introduced a Kanban, it’s the best tool I know for such a situation. It comes from the Lean approach, and Scrum practitioners tend to give it a close look these days, some are even talking about “Scrum-ban”, some hybrid between a Kanban and the usual Scrum task board.
Anyway, our implementation of the Kanban was very low tech: a whiteboard, plenty of sticky note, a couple of pens, a marker. No need for anything fancy or expensive. We used the colors of the sticky notes to give us a nice visual feedback on the type of tasks: yellow for the regular ones, pink for the urgent ones, green for the non technical ones (like writing a blog, documentation, etc.). We regularly took pictures of its state for reference purpose and blog, you can see the final state of our Kanban online.
The Kanban itself was divided in three areas: Waiting, In Progress, Done.
There was two ways to complete a task in order to move it to the Done area. Either it was fine grained enough and then you just had to implement/write what was required (roughly an hour of work maximum) in order to consider it done. Or, it was too big and abstract, in which case completing it meant: analyze it, do some preparatory work to actually split it into smaller tasks added to the Waiting area. In such a case it could be a good idea (even though not mandatory) to add a small note to the original task explaining that it got split further.
As you can clearly see from the description already, using this system gave a lot of transparency about what was going on during the sprint. Everyone could all the time check what was worked on, how much was left, what was already achieved, etc. It also came in very handy during the regular wrap up sessions we had. One could just go through the Done area to remember all the tasks he worked on, and then provide details about the outcomes, the problems to implement the task, etc.
Instead of implementing the complete Kanban model (which would, for instance, limit the number of items in the In Progress area), we tried to regulate the flow by another mean: Pair Programming. By asking people to work in pairs, we were trying to indirectly limit the amount of tasks which could be in the In Progress area.
The reason of this trick was that in the case of the Solid Sprint, we try to blend more and more what used to be scattered teams. Pair Programming is a good way to give the feeling of a single team and to improve the knowledge sharing inside of this team. This way you can effectively raise the so called bus number of the team. That’s definitely critical in a community based environment building on the work of volunteers who sometimes drop unexpectedly.
In short: re-introduce more of the Kanban features. For this first experiment, I think we slightly oversimplified the model, removing some of the constraints of the Kanban. We tried to hide the slightly more rigid structure of the Kanban through an external constraint of the type: “work in pairs as much as possible”. Sounded like a good idea, except that this kind of discipline is just extremely hard to acquire alone or by being told. On the other hand, modifying the rules of the game can gently push you in the right direction.
And indeed, the Kanban provides us with the necessary rules: you’re supposed to cap the maximum number of tasks in the In Progress area for instance. Make that number slightly below the number of participants, and you should see people pairing more often. It honestly sounds a bit harsh put this way, but that’s likely a good temporary measure to give a taste of Pair Programming in a team.
Another potential improvement we could have used during the Solid developers sprint was to split the Waiting area into Waiting and Selected. Again, the number of tasks in the Selected area needs to be caped (generally at a somewhat low number). Then someone would have to be responsible into making sure that the Selected area is always full. By doing so we’d achieve two things:
Last but not least, the task splitting during the Exploration Phase could have been a bit better. I was basically monitoring the discussions and adding new task on the board each time I caught something which looked like an action item. I had to proceed this way because at that time I didn’t introduce the Kanban to the team yet (not to scare them away to early ;-)), but as a downside I probably missed a few tasks in the process or introduced some tasks which still needed to be refined. Next time, we should make sure it is the person bringing the discussion who adds the tasks to the board. By doing it this way the discussion will naturally flow toward this task splitting.
I think this Solid Developers Sprint 2010 was quite different from some of the other Developers Sprints we (KDE) had in the past. It really gave a pace to the whole team, and improved the transparency within the team. As a consequence, it improved the cohesion as everyone could easily know what was going on and exercise their curiosity.
Of course, it was not perfect either, and I highlighted in this essay what we could do better. I’ll very likely experiment those improvements the next time I have an opportunity. In particular I’m looking forward to stimulating even more team cohesion, we’re sitting on a tremendous potential here, let’s turn it into an asset!
PS: If you read until this point: thank you and congratulation! I hope you found this (somewhat) short essay at least a bit interesting. Feedback, questions and comments are welcome.