Interesting week, I think that's the first time I attend a sprint where I don't write a single line of code. Wait! What? Me? Not writing code!? Yes... I guess it was doomed to happen since I've been doing more and more sprint organization lately.

This one was a bit special though, I'm not really a very active contributor of our workspaces. I care about them of course, but I just provide a patch here and there from time to time. Lately, there's been new blood getting involved in the workspaces, which is great of course, but that's also challenging. When you get such a community growth, it is often difficult to keep everyone on the same page.

I've been doing organization work, I care about our workspaces, and I'm a rather neutral/free agent in that area so I decided to attend. Indeed, it seemed that I had a proper profile to facilitate the meeting, and help integrate people, so I tackled that task. It was probably risky in retrospect, but no one got hurt, that's a good sign. ;-)

Of course, since I'm working on KDE Frameworks as well, I could from time to time bring the "people from the basement" perspective. :-)

So, what did we achieve during that week? Maybe not a lot code wise (yet), but definitely a lot on the bonding and community front. That's fine as it was the main goal!

I planned several sessions throughout the week to prepare the proper mindset. Of course it all started with hugs and massages (I've been told it relieves tensions, so it was a proper first step I think). Then we had a first meeting where Marco and Sebas presented the terminology and the concepts used around Plasma. It of course raised some controversy, but we quickly moved on for the time being as it was more about sharing the current state of affair, not more.

We then took on a long tour of group activities.

First Björn helped the people to build a set of personas to help thinking with the user point of view when dealing with our software. We came up with Carla and Raj who helped quite a bit during the sprint. Hopefully, they'll help us more generally when designing to keep a user centric approach.

Then we had two innovation games named Speed Boat and Prune the Product Tree. They were respectively meant to figure out the pain points around the workspaces, and to find out the product core features and its dynamics. We did a terrific job on those games along the course of two days... They were exhausting for me though! Keeping your attention focused to facilitate the process, get the people to share, make sure everyone can talk, etc. Pfew! That wasn't even the end of it all... I still had to process all the generated data!

Luckily, those games completely met my expectations so it was worth the effort. They indeed confirmed some of the assumptions we had about our products, but they also helped to discover some unsuspected dynamics. Of course I pushed all the data and results on our wiki.

We concluded this process with two meetings. The first one to revisit the terms and concepts extracted on the first day. Those terms and concepts got adjusted a bit, which is a very good thing, allowing everyone to appropriate them. The second one was more technical, and the people extracted together tasks to move the products forward. It helped fill up a Kanban that they're supposed to use over the week-end now (I can only assume, I unfortunately won't be there to live the experience, I had to get back home).

Of course, throughout the sprint, there was quite some slack in the schedule for the mandatory cooking activities (led by our own personal Dario The Cook), table tennis games, naps and messing around with the swimming pool. That helped keep a playful atmosphere which was definitely welcome.

Anyway, during this week it was fascinating to see less and less controversies appearing during discussions. They got replaced by more and more group thinking, consensus creation, etc. Definitely more pleasant for everyone. I dare believe the activities we proposed through the week helped pave the way of this shift of mindset.

As you can see on that group photo, very nice atmosphere in the group this morning! I hope it'll stick... only time will tell.

PS: For more pictures with sexy hackers or the usual sticky notes, I already uploaded them in the Sprint gallery

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 we setup on the first day? Well, here is how it looked on the last night:

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. :-)

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!

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) 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.

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:

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 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 "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). 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.

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. 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 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)

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.