I’m keeping this writeup definitely shorter than my  writeup of XP Days Benelux. In Karlsruhe, we presented the Science Scrum talk again, that Joseph and I had submitted together. Slides from the talk are here and a podcast was recorded and should become available on the organizer’s site soon.

It definitely was a challenge to boil what was conceived as a 1-hour talk down to a 30-minute time slot, and while we ran slightly out of time in the end, I think we managed to get the core ideas across.   A good idea I  picked up from Ralph Miarka to optimize your talk: Draw up a Venn diagram of “What I want to say about the topic” and “The audience’s needs and interests” … and then talk about the intersection. How true!

We received good feedback for the session, and I hope we will have an even better and crisper version at the XP Day in London this coming Monday, December 7 2009.

In contrast to the Benelux conference, this one had many more structured, frontal, sessions and less collaborative and interactive sessions. The presentations were top-notch for the most part, but having been spoiled by the immersive experience at XP Days Benelux, I felt a certain community feeling lacking – until the last day, that is. The last day was entirely devoted to World Café and Open Space.

What else was new? I finally saw some Pecha Kucha first-hand, and I am not fully convinced of the format yet. It is very easy to go for eye-catcher slides without really aligning them with the message. The format also seems to trigger a lot of buzzword-fetishism, at least in the sessions that I saw. Still, it is entertaining, and if I remember well that Pecha Kucha means “pitter-patter, chit-chat” in Japanese, then I suspect that entertainment is its prime purpose. There was also a really interesting session about Kanban and Lean on the OpenSpace that triggered a few thoughts in my head that still need a bit more processing.

Science Scrum | No Comments »

This year, I attended XP Days Benelux for the first time, and I want to share some of the insights and impressions I got from this event. To tell the truth, I have not been at any XP Days-Events before, and my mind was blown away. This was not what I expected. It was much, much better.

Session Kanban cards at XP Days Benelux 2009

I have attended a fair share of (scientific) conferences, and in my experience, the interesting things always happen in the coffee breaks, or in the poster sessions. Lectures are somewhat stiff, usually scientists talk about work they’ve already published, and it is very rare to hear any truly new insights. Finally, questions after the session are often pro-forma, and rarely lead into deep discussions due to lack of time. Don’t misunderstand me – conferences are important places to meet, but the official program often isn’t too captivating. Go into a lecture hall and watch from the back what all these people with laptops are doing – working, skyping, coding, writing email… but I am getting off track, I think.

At XP Days Benelux, this was all different. People come to share and to interact. From the start with an icebreaker session each morning (and I was still thinking “oh no! psycho-touchy-feely stuff!”…), people started networking, and I have met a lot of interesting people and have had interesting conversations with many, inside sessions and in the coffee breaks. It was a very enjoyable experiences, rounded off with the games night in the bar, where werewolves and belgian beer were the driving forces.

Xavier Quesada and Laurent Morisseau held a session on Visual Management for Agile Teams. Here, we built scrum task boards in groups and discussed the many different ways you can actually do that and what it means for the team and the managers.
The Retrospective Hero session by Nicole Belilos and Willem van den Ende used a role-play simulation that challenged two coaches (and they did warn the audience – don’t be a coach unless you’re experienced) to manage a crisis and lead the team through learning lessons from it. It was scary how well people slid into their roles! One big lesson: In a crisis, try to let the team voice their emotions first, as they will come out anyhow. But (a big but!) do it without going too much into the touchy feely direction.

The action continued into the night with a BoF by Pierluigi Pugliese on his solution focused approach to agile coaching. Another BoF was run by Serge Beaumont on practical tools, like the Ready state and Jeff Patton’s Story Mapping for the Product Owner. Both BoFs have noticeably created a lot of buzz in the community and it seems clear that Pierluigi and Serge have hit a nerve with what they presented. Moreover, I think that there are a number of points that connect the two talks.

In the Solve Conflicts Without Compromise session, which was run by Pascal Van Cauwenberghe and Jef Cumps, the session leaders tried to introduce a model that allows you to (I am simplifying here) figure out in 6 steps that two conflicting goals can – at least very often – be lifted onto a higher level, where all of a sudden their underlying goals are compatible, and it is just a question of carefully assessing all the assumptions that were made concerning the goals. An interesting approach, but at least in the session, none of the (real life) conflicts were really resolved. Then again, solving conflicts in 90′ is a big feat to aim for, if you are doing it for the first time, even more so.

Eating your own dogfood: Using Agile methods to set up conference desk

Finally, Portia Tung introduced us to the retelling of the Wizard of Oz fairytale, and how you can use the yellow brick road as a path in peer coaching. I found this session amazing, since we were in turn describing our problems, coaching others in addressing their problem, or observing the coach-coachee interaction.

But, as I said in the opening paragraphs, the sessions are excellent but aren’t really what makes this gathering great. It is the very open spirit, a genius loci (there really isn’t much more to do around the conference center either), which makes the participants try to learn from each other rather than try to get the daily office work done on their laptop during the sessions. Oops, there I am back with my initial rant – so I better stop right

Science Scrum, pix, tech | 1 Comment »

Ich werde an den XP Days Germany zusammen mit Joseph Pelrine (@josephpelrine) eine 30′-Version unseres Erfahrungsberichts mit Scrum im Management einer Uni-Forschungsgruppe präsentieren. Der Vortrag ist auf Deutsch (was mir nicht schwerfallen sollte, aber dennoch ungewohnt ist), im Gegensatz zu der Session, die wir ein paar Tage vorher an den XP Days Benelux halten werden.

Besonderes Augenmerk werde ich auf die Einsichten legen, wie Scrum funktioniert, wenn man nicht etablierte Praktiken aus der Software Entwicklung zugrunde legen kann, da es gar nicht (primär) um Software-Entwicklung geht.

Ich werde also einige der Themen ansprechen, die ich hier im Blog angerissen habe.

Das Abstract des Vortrags findet sich übrigens hier.

Ich freue mich bereits, nach Karlsruhe zu kommen, und mir die Keynote von Alistair Coburn und das Tutorial von Ralph Miarka anzuhören, die vielen Sessions mit spannenden Titeln und Abstracts, das Pecha Kucha, den Community Day, und und und…

See you in Karlsruhe!

Science Scrum, deutschsprachig | No Comments »

In this article, we take a look at the roles of management and product ownership in university research.

There was recently not so long ago a discussion at InfoQ, triggered by an opinion piece by Amr Elssamadisy. Michael Hedgpeth suggests that the bad reputation Scrum attributes to “classical” management may backfire in corporate cultures run by people who believe in traditional management. This made me wonder about the management culture and styles that we can observe in academia.

In brief, the argument goes that developers like Scrum, because notions like “chickens and pigs” put the pointy-haired bosses in their place, and give all the power to the team, but that it is this rebellious notion that makes Scrum unpopular with management.

In university, I have observed the complete opposite: It’s not the managers who are uncomfortable with Scrum, but rather the scientists and developers, who feel that their personal liberty is at stake — slightly causticly defined as: “I come in to the office in the morning, and do what I feel like, without feeling committed, and hopefully, great things will result”.

The management hierarchy in university research groups is rather flat, with a PI (principal investigator, group leader), usually a professor, on top and in charge of the project overall plan and finances, and a group of post-doctoral fellows, grad students and undergrads, as well as technicians or programmers, working on subprojects within the overall plan of things.

Apart from this, there is no explicit hierarchy, at least in the majority of groups that I have seen. Still, there is of course implicit hierarchy, based on seniority and in the best cases, on experience and merit, after all, the university is the one place that should reward learning and experience.

As we started implementing Scrum in research groups, we wondered what the best way to distribute the Scrum roles is. The answer, of course, is “it depends on the circumstances”. Still, here’s my current best thinking on this item:

The first question is who owns the project, especially if you are avoiding solo scrum by running a sprint with many several subprojects, as  I described in a previous article. Is the individual scientist the Product Owner? After all, she’s the “single wringable neck”, the one person ultimately responsible for the work being done correctly and timely.

On the other hand, an individual scientist, in particular at the graduate student level, often lacks the seasoned view of the veteran and isn’t able to perceive what avenues are promising, lacking the experience of long years of trial by fire. Here, the group head can contribute his or her experience, and the big picture view of the research subject that results from having been there, done that, and written a couple of reviews about it, as well.

So, we decided that the PI, or group head, should be the product owner in a science scrum project. Not an autocratic PO, but rather someone who listens to valuable input from his constituency, the grad students and post-docs, who might lack the big picture view, but who offer valuable input “from the trenches” nevertheless. The group head must take their input seriously (which should be de rigeur in any scientific endeavor, it goes without saying) but is in charge of planning and keeping the product backlog up-to-date, regardless of whether you’re producing software or writing papers as the end result.

(No funny lead picture about restaurant complaints this time … but a comic. Thanks for staying until the end.)

Science Scrum, tech, words | No Comments »

I will be attending XP Days Benelux this year. Joseph Pelrine and I have proposed a session called “Science Scrum: Managing a Research Group the Agile Way”, which will be opening the conference proper right after the plenary. We’ll speak about some of the things I have covered (and have been meaning to cover) here in this blog and much more.

I am very excited and look forward to being there and participating in the action! Drop me a line if you are going, too, and want to meet up.

Science Scrum | 1 Comment »

A quick, simple and tasty recipe (if you like liver). Based on an article in La Cucina Italiana.

For 2 Persons:

250 onion, chopped sideways into fine strips
250 veal liver, cut into small pieces
30g butter
Extravirgin olive oil
2 sage leaves
handful of parsley, finely chopped
1 glass dry white wine
salt, pepper

Preparation:

On medium heat, melt 30g of butter and olive oil in pan. Add chopped onion and sage leaves and cook covered for 10 minutes until soft, golden and sweet. Add liver and keep stirring until liver isn’t raw on outside anymore. Add glass of wine, cover and let cook for 3 minutes at medium heat again. Remove cover, add parsley, and let liquid evaporate. Pepper and salt lightly before serving.

Goes well with a white risotto or polenta.

food | No Comments »

Ask a scrum practitioner what the right size for a scrum team is, and he’s likely to tell you “7, plus minus 2″, the canonical Scrum answer. Here, I want to consider lower limits of Scrum teams and how to overcome them.

This seemingly magical size of teams of between 5 and 9 members being able to interact well goes back to the channel capacity of human cognition, studied by George Miller in 1956 [Miller, G. A. (1956), Psychological Review, 63, 81-97. (1956)]. Incidently, and probably unrelated, we can also keep about 7 items (give or take a few) in our short term memory.  So, there are at least two good reasons to keep a scrum team within that range: you can interact well with them, and you’ll be able to remember their names when first introduced.

I’m working with a biology research group and introduced them to Scrum. They use it to organize themselves in projects  that are even less steady and predictable than working with a vagarious customer: Pushing the limits of scientific research. Agile practices work very well in this context: you’re dealing with a complex interconnected topic, and the regions where new discoveries are made are those where there are few tried recipes. To make Scrum work in this domain, it needs some adaptations, and I will talk about those here and in future entries.

Here’s the problem: In this research group (and I know many groups that are alike), the median team size for a project is one. One Ph.D. student wondering how she’ll ever finish up her thesis project, or one ambitious post-doc trying to show the boss that his ideas work after all and can be published in that highly-cited journal. Sometimes, there will be a technician or programmer helping part- or full-time, but by and large, science is a lonely pursuit, overseen only by the group leader.

One solution is a large set of Solo Scrums for each scientist, with the group leader in the PO role for each of them. This is actually quite close to the way academic projects are often run: More or less regular meetings with your supervisor, who will tell you what to do next, and what avenues to better stop pursuing (product backlog prioritization). An added benefit is the use of a sprint backlog, which will tell you what you should do to ensure a happy boss come next meeting. Plus: The notion of time-boxing will keep meetings in control and let you do more science instead.

I prefer another solution: Make them all join one larger scrum team. We found that their projects are separate, and to some extent have to be – a PhD is awarded for a unique contribution to science – but the research topics overlap a fair bit, as well as the methodology. This provides more than enough attachment points between the group members.  A trade-off is that it will be more difficult or even impossible to find a sprint goal that is valid for all members. On the positive side, though, you get a real, live, interacting team rather than the slightly schizophrenic solo scrum situation.

Talking about your project with your team mates gives you new ideas about your own problems and challenges your own beliefs on what works and what doesn’t. It brings the team together and creates a form of group conscience, even though the team doesn’t work on one single product. In the daily scrum meetings, the team begins to understand better what everybody is doing, and gentle ribbing as a form of peer control usually happens when we see that one of the team members hasn’t really worked on what he promised to do this sprint. These checks are not only beneficial for the group, but also for the individual, as a way to focus and organize your work towards a goal.

For the group leader, too, using Scrum is beneficial. The meeting overhead is reduced, and there are fixed times every two weeks, when the team presents in a concise form their latest results and plans what to look into next.

Using Scrum to manage research projects, rather than building software, we had to change some of the definitions to make the process work in this altered context. In the next post, I will talk more about how we adapted Scrum to work with science projects.

Science Scrum, words | 1 Comment »

From @daveharvey: Booklog (n.) – All the books you’ve ordered on a whim or recommendation and are piling up, unread. Can be prioritised like any backlog…

Good idea… I’ll show you mine, will you show me yours?

(not yet prioritized, except that I’m reading the top one right now)

PS: What a pity that the next decent bookstore is in Bern. Or Portland, but that’s hardly around the corner.

books, pix | No Comments »

Even if time has become a valued commodity lately, I still like to cook, and to occasionally try out new things. On this long weekend, I ventured to explore a heavenly taste combination: Basil and Strawberries. I remembered this combination from idly thumbing through Culinary Artistry, an extraordinary and inspiring book by Andrew Dornenburg and Karen Page. Follow me below the fold for the recipe! Read the rest of this entry »

food, pix | 2 Comments »

Read the rest of this entry »

mobblog, pix | 5 Comments »