The developer sprints in Randa are officially over. I spent my
first full day at home today, and it feels almost odd to be in my
quiet office after all the energized atmosphere we got there during
a full week.
Anyway, remember the
[Platform11 Kanban](http://ervin.ipsquad.net/2011/06/04/sticky-notes-markers-and-chocolate-platform-11-in-randa/)
we setup on the first day? Well, here is how it looked on the last
night:
[](http://ervin.smugmug.com/Events/Platform-11/17377032_2nhXRP#1328247947_QMMK56V)
I think we made "some" progress. And that's not counting the
technical tasks which got handled in a separate Kanban. If we had
another day I wonder where we would have put the done tasks. As you
might notice on the picture above we simply reached the floor in
the "Done" column. :-)
[](http://ervin.smugmug.com/Events/Platform-11/17377032_2nhXRP#1328247933_Zgn8mQk)
So, is everything said and done now? Well, not really, what we did
really was putting into motion the on-going effort which will lead
us to the first iteration of the KDE Frameworks. We tried to create
the tracks in Randa, and I'm looking forward to get on the train
for this exciting journey!
[](http://ervin.smugmug.com/Events/Platform-11/17377032_2nhXRP#1328249452_b6L5GmZ)
[](http://ervin.smugmug.com/Events/Platform-11/17377032_2nhXRP#1320952718_CZ9tGh6)
It almost feel like forever since I blogged last. Turns out that
I'm on the road again for a KDE event and so it's the right time to
open my blog and take a few minutes to write something.
I'm sitting in a large house in Randa as I took some time to attend
the Platform 11 sprint. It seems to become a small tradition in the
sprints I attend to setup a
[Kanban](http://en.wikipedia.org/wiki/Kanban_(development)) to keep
track of what we're doing. Since this sprint is about giving some
love and direction to our frameworks offering, I also used the
opportunity to experiment with a couple of
[Innovation Games](http://en.wikipedia.org/wiki/Innovation_game).
The aim of those games was to facilitate the brainstorming groups
we had on the first day. We broke out the output of those groups
into discussion topics that we track in our Kanban, I think the
result is really telling:
[](http://ervin.smugmug.com/Events/Platform-11/17377032_2nhXRP#1320952863_sxRFJqW)
What you can probably imagine from that wall is that we have a lot
of ground to cover. So far it's going on at a nice pace, I'll
probably make another picture at the end of the sprint. We also
have some smaller somewhat individual technical tasks that we're
tracking in a smaller specific Kanban, I might take a picture of
that one as well later on.
We obviously had some very important discussions already, so we
have interesting preliminary results... But I won't talk about that
today, the paint is still fresh on them and we probably need to
consolidate all of that at the light of discussions yet to come.
If you like our frameworks already, or if you were too shy to
really use them: stay tuned for more awesomeness and love coming to
them!
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:
- How the Free Software community works;
- The practices used in the agile project management community;
- How both community driven development and agile management can
influence each other;
Then, you can safely skip this post... But if at least one of those
topics raised your curiosity, then brace yourself and keep reading.
:-)
### Introduction
We have a strong tendency in the [KDE](http://www.kde.org "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](http://en.wikipedia.org/wiki/Scrum_(development) "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.
### The three cardinal sins of *Developers Sprints* regarding agility
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 know provide us tools that we can reuse by bending
the rules while retaining the spirit and values of the original
rule set
([Shuhari](http://en.wikipedia.org/wiki/Shuhari "Shuhari")). The
tools I'm proposing to reuse and combine are the
[Kanban](http://en.wikipedia.org/wiki/Kanban "Kanban") (even though
in an incomplete version for now), the
[Exploration Phase](http://en.wikipedia.org/wiki/Extreme_programming_practices#Planning_game "XP Planning Game")
(in the [XP](http://en.wikipedia.org/wiki/Extreme_programming)
meaning of the term) and
[Pair Programming](http://en.wikipedia.org/wiki/Pair_programming "Pair Programming").
### The perfect experiment: Solid Developers Sprint 2010
So, how did we proceed for this sprint? Let's stop the suspense
now. :-)
#### Exploration through Discussions and Goals
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:
- the person who brought up the topic had to detail it in front
of everyone;
- it was achieved by giving a small status update on the topic
followed by the actual problems which were in need to be solved;
- people could then discuss the topic, provide input, disagree
and so on (a moderator might be needed there, we didn't need one
though);
- discussion stops after 20 minutes (it's a soft limit of course,
if something interesting is coming out of the discussion wait a bit
before stopping it);
- if everyone was feeling the topic still needed more
discussions, it was allocated an extra slot after all other topics
got discussed (so you could iterate a couple of times before
emptying the topics list);
- no laptop allowed policy (except for the one typing the
minutes), and this one is a strict rule.
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](http://www.flickr.com/photos/vizzzion/sets/72157624950127005/with/5047791559/ "Sebas' Solid Sprint Pictures").
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.
#### Introducing the Kanban
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](http://www.flickr.com/photos/vizzzion/5048389060/in/set-72157624950127005/ "Solid Sprint 2010 Kanban in Final state")
online.
The Kanban itself was divided in three areas: *Waiting*,
*In Progress*, *Done*.
- In the *Waiting* area one could find all the tasks known for
the sprint. When someone was done with a task, he would turn to the
*Waiting* area to pick a new one;
- tasks picked from the *Waiting* area would end up in the
*In Progress* area you could see at a glance all the task which
were worked on by the other members of team, good way to take the
pulse of the project;
- when a task was done, it was moved to the *Done* area.
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.
#### Raising the bus number through Pair Programming
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.
### Where we could improve the model ([Kaizen](http://en.wikipedia.org/wiki/Kaizen "Kaizen"))
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:
1. the developers would have to pick tasks which are not directly
in their core domain (stimulates even more collaboration among the
team and then cross-pollination... it basically puts the Pair
Programming on steroids);
2. the person in charge of the *Selected* area could influence the
priorities of what is achieved during the sprint (of course, that
puts quite some constraints on the person, in our context that has
to be someone with a good overview of the project, and enough
empathy to actually make sure people keep having fun during the
sprint).
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.
### Conclusion
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.
