David Barnholdt and I recently attended a 1-week PSL workshop (Problem Solving Leadership) with Jerry Weinberg, Esther Derby, and Johanna Rothman, one of the best courses I've ever attended. After that course we've been thinking about ways to make our own training courses more interactive.

David was first out and invented a brilliant exercise demonstrating the power of open-ended requirements. I built upon that idea and tried out my own variant for the first time last week, with 20 people divided into 4 teams. Here's what we did:

Step 1 - follow open-ended spec:
Team 1 & 2 were given the task "Draw a summer meadow", Team 3 & 4 the task "Draw a christmas card". The teams were given direct access to the customer (me & Arne, my co-teacher). When they showed prototypes and asked for detailed requirements we were cooperative but gave only high-level answers such as "I want the picture to make me long for summer" or "Some more life would be nice", letting the teams figure out the implementation.

Step 2 - write detailed spec:
The teams were now asked to write a detailed specification for their picture, so that offshore teams could re-create the same exact picture as closely as possible. Due to "bandwidth cost restrictions" we only allowed written text in the specification :o)

Step 3 - follow detailed spec:
Send the spec to the "offshore team" - i.e. team 1 & 3 swapped specifications with each other, and team 2 & 4 did likewise. No communication between the teams. So now each team had to try to recreate the other team's exact picture using only an overly detailed spec ("draw a 2.5cm wide blue cloud 2 cm under the top-left corner"....etc)

Step 4 - art gallery
All pictures up on the wall. Each person got to grade each picture (draw 1-5 dots on it) indicating which pictures they would most like to take home.

Step 5 - debrief
Not surprisingly, in 3 of 4 cases the "offshore team" pictures from step 3 were significantly uglier. See the examples below. We talked about open-ended specs vs detailed specs, and how this can impact the overall quality of the product. We also talked about how each of the first three steps felt like. Several people mentioned that they recognized the feeling (and result) from real projects they'd been in.

My conclusion:
Fun exercise! The debrief part was a bit too rushed and controlled from my part, I should have been more open-ended there (go figure...). And I might work on the timings. But everyone I talked to liked the exercise, and people referred back to it several times during the course, so I will most likely do this again!

Thanks again David :o)

So, here's one of the examples. Guess which picture below was drawn to en open-ended spec and which was drawn to a detailed spec...

Cross-functional team doesn’t mean everybody has to know everything - this seems to be a common misinterpretation though. Cross-functional just means that the team as a whole has all skills needed to build the product, and that each team member is willing to do more than just their own thing.

Are you unsure if your team is cross-functional enough for the product they are building, or are you sensing a lack of teamwork? Here’s a useful workshop technique (with a  slight teambuilding effect as well):

Get the team together and bring the product backlog. Ask the team “what are the main skill areas needed to build this product?” and list the skill areas on a whiteboard or flip chart. Then give each person a pen and ask them to rate themselves within each skill area.

• Star = I’m good at this, or this is my main skill area.
• Dot = I know a bit of this, enough to contribute. Or I can learn and am willing to do so.
• Empty = I can’t or won’t do this at all.

This usually triggers valuable discussions and insights such as:

• Joe: “Looks like we don’t have as much of a specialist problem as we thought!”
• Lisa: “Yeah, I didn’t even know Jenny could code Java!”
• Jenny: “Well, I’m not too good at it but I have some personal hobby projects and I really would like to learn more! I'm sure I can contribute as long as I don't have to do the hard parts.”
• Joe: “I thought I would be a real bottleneck as DB expert, but now I see that Lisa could help me with some DB stuff!”
• Lisa: “Yeah. Java is my main skill but it seems I’m the only person other than you that could do DB stuff, so I should probably spend more time helping you with DB work instead of just coding Java.”
• Joe: “DB knowledge is still a potential weak spot for us as a team though, so I’ll talk to the product owner and look ahead in the product backlog a bit. If we see DB intensive stuff coming up it may be worth getting another DB-skilled person on the team, or at least giving us access to a contractor for a sprint or two.”
• Erik: “I really hate testing, really suck at it, and am not interested in learning more about it. So I’m really happy to see that the rest of you guys are willing to test, now I don’t feel as bad focusing on my other skill areas instead.”

It may even trigger the insight that this team is incorrectly staffed for the product being built. That’s extremely useful to find out early!

A good rule of thumb is that each column should have at least one star and one dot (or two stars). That means we have at least one guy who is good at that job, and at least one additional person who can help out when needed. And the team won’t be completely helpless if the star person gets sick or hit by a bus.

I like this exercise because:

• It’s quick & easy.
• It triggers valuable discussions.
• It helps visualize the team's strengths and weaknesses.
• It encourages teamwork (“how can we help each other succeed”)
• It counteracts pidgeon-holing (attitudes such as “I’m the Java guy and you’re the DB guy, so the DB stuff is your job!”).
• It helps people get to know each other better.
• It takes into account the fact that people can (and often like to) broaden their skills.

Here's a great list of agile tools on Mike Cohn's User Stories site! Primarily for product backlog and user story management.

Only problem is that there are way too few reviews so far. Are you using an agile tool? Go submit a review now and spread the link to your friends! Let's help build this thing :o)

Great initiative Mike!

(sorry, this article is in Swedish, because it is a response to a Swedish article. I won't make this a habit.)

I en artikel i Computer Sweden den 3 feb står det ”siffror visar att nio av tio Scrumprojekt misslyckas”. Men de angivna siffrorna handlar i själva verket om något helt annat - att 9 av 10 personer som säger att de kör Scrum inte implementerar Scrum fullt ut. Detta säger ingenting om huruvida själva projektet lyckades eller inte (eftersom Scrum inte är ett självandamål). Denna typ av sensationsjournalistik gynnar ingen - utom möjligen tidningen som vill öka sina tittarsiffror, men på bekostnad av trovärdighet.

Låt oss därför titta på lite mer relevanta siffror istället....

Read more...

A Russian translation of my book Scrum and XP from the Trenches is now available. Thanks Aleksey Solntsev for initiating this project, and thanks to all of the 17 people who contributed (listed on the first page in the book).



French, Spanish, Japanese, Chinese, and Portuguese translations are also available. Korean, German, Italian, and Slovak translations are underway.

I never cease to be impressed by the agile community! So far, every time I've blogged about a new translation it's taken less than one day before someone offers to translate to the next language :o)

All translations are listed on InfoQ as well. Feel free to email me (henrik.kniberg AT crisp.se) if you want to translate the book to your language.