At our last Crisp conference we were discussing different types consulting engagements, and someone (Olle Hallin I think) came up with a useful metaphor – Seals and Albatrosses! Recently we added Ducks and Anglerfishes as well!

Seal consulting



Some of us are Seal consultants. A Seal is faithful and dedicated to one single client pretty much full-time. The Seal consultant takes a deep breath, dives in, and then stays under water with the client for months (hmmm... perhaps Whale would be a better metaphore). The Seal doesn’t have much time for other stuff such as teaching courses or going to conferences. Once in a while a Seal will pop up above the surface, take a deep breath & learn some new stuff, perhaps find a new client, and then dive deep again.

Seal work takes patience and dedication. You need to take special care not to get too deep too long, and remember to come up for breath once in a while to expand your horizons. You also need to select your clients carefully since the decision has a big impact on your daily life.

Seals are usually cute and playful.

Albatross consulting



Some of us are Albatross consultants.  We sail around high in the sky and travel great distances. Once in a while we plunge into the water and grab a juicy fish, then up inte the sky again. The Albatross gets to see many different places – but doesn’t stay still long enough to get to know any single client well. The Albatross is flexible and free. No client will complain if the Albatross decides to spend a week going to a conference or writing a book. On the downside, the Albatross spends a significant amount of his time coordinating with his clients and fiddling with his schedule trying to make everything fit together.

The Albatross has to be careful not to sail too high into the clouds and lose touch with reality. It can get lonely and insecure up there in the sky, always on the move, not having your own cozy little cubicle to call home. The returns are great but freedom does have a price.

Albatrosses are usually swift and graceful.

Duck consulting



Some of us are Duck consultants – a compromise between the Seal and the Albatross.

Like the Seal, we have one specific client that we focus on. Unlike the Seal, however, we don’t spend all our time under water with that one client. Like the Albatross, we sometimes spread our wings and visit other clients or teach courses or attend conferences.  But the Duck has one particular pond that he likes to return to, a client that has gotten to know well and perhaps spends one or two days per week with. Long enough to get to know the client, but not long enough to get below the surface.

Ducks are usually pretty and funny.

Anglerfish consulting



Some of us used to be Anglerfish consultants before joining Crisp.

Anglerfish are way down in the dark, lost, wandering aimlessly with nothing but a small artificial light to guide them. Sometimes they are lucky and manage to attract a small fish. As opposed to the Albatross, the Anglerfish can't see the horizon and doesn't choose where to go - it just floats around and eats whatever scraps it happens to bump into. The Anglerfish never goes up to the surface to see the big picture or learn something new - in fact, he doesn't even know the direction to the surface.

Anglerfish are usually ugly and scary.

Thanks for contributing this one, Patrik :o)

Which type of consultant are you?

Most of us shift roles from time to time. I used to be a Seal. Now I’m an Albatross, and hoping to become a bit more like a Duck during the next half year or so. <sales-pitch>So let me know if you need a Duck consultant for one day per week or so :o) </sales-pitch>

Sometimes we all meet up on a rock and make noise together (except for the asocial Anglerfish of course, but I don't think we have any of those at Crisp). For example at Crisp RDs (internal workshops that we do every other week) or international conferences. Great fun!



Are you a consultant? if so, what type? Are you happy with that? If not, what are you going to do about it?

(ps - the photos above are courtesy of whoever I stole them from)

Are you interested in Lean software development and how this relates to Agile methods such as Scrum and XP? Would you like to meet Mary Poppendieck (leading pioneer of Lean Software Development) and Jeff Sutherland (creator of Scrum)?

Deep Lean on May 18-19 is your chance to go beyond the basics, to meet and interact closely with internationally recognized experts within this field, and to trade experiences with peers.

The course was a great success last year, and we have made several improvements to make it even better this year!

Here is the registration page with more info.

Deep Lean participants are also invited to join our Summer Party on Monday May 18, with live music from my band Indigo.

As I mentioned in a previous post, I am right now in Japan with 4 colleagues from Crisp, a few consultants from BestBrains in Denmark, Mary & Tom Poppendieck, Gabrielle Benefield, and some other Lean & Agile enthusiasts. We are visiting Toyota and other interesting companies. It is especially interesting to look behind the scenes of less well-known areas such as how Toyota does software & product development.

Here is our running logbook with our agenda, notes from our daily Hansei (reflection) + links to related blog entries.
http://docs.google.com/Doc?id=dccmt2fq_293cwxgg9gq

We will be adding raw info to this page as we go along.

UPDATE (2009-04-22): sorry, the above document is no longer public. The info there was too raw and subject to misinterpretation. I'll add more info about the trip later.

UPDATE (2009-06-27): Here are some mindmaps summarizing key observations and learning points from the trip.

One of the recurring themes on Jerry Weinberg's PSL course (Problem Solving Leadership) was "There are no hard problems, just hard solutions". Often a problem seems hard only because we make it hard, by attempting a hard solution. When we instead open our minds and find the simple solution, the problem suddenly proves to be simple.

I know, it sounds vague. But we saw several examples of this during the course and, since then, I've started seeing more and more examples of this in real life. Complex problems that more or less melt away once you realize that it was your solution that was complicating things, not the problem itself.

Here's a silly but concrete example :o)

A few minutes ago I was trying to teach Dave (5 years) to eat noodles with a pair of chopsticks. After struggling for a while trying to follow my example of how to hold and manuever two sticks with one hand, he lost patience with me. He dumped one stick on the floor and proceeded to gobble up the noodles in no time using just the other stick.

DUUUH! :o)



So despite our initial efforts, eating noodles with chopsticks wasn't actually a hard problem. It was only my solution that was hard. His solution was simple - and thereby made the problem simple :o)

Sometimes kids can be the best teachers. They are blessed with Beginner's Mind (Shoshin).

Next week I'm going on a "Lean Study Tour" together with a few consultants from BestBrains, some colleagues from Crisp, Tom and Mary Poppendieck, and some other lean enthusiasts. We're going to visit Toyota and some other interesting companies.

A couple of weeks earlier I was at QCon Beijing and QCon Tokyo, so I've had a week of vacation in between. I've spent a few of those days with my family at Tokyo Disney Resort (= Disneyland + Disney Sea), really fun! In fact, Disney Sea in particular is now on my PlacesYouMustVisitBeforeYouDieOrYourLifeHasBeenInVain list, together with Rome and the Grand Canyon.



Anyway to the point...

Being an Agile & Lean coach, I can't help but notice how things are organized - and I'm impressed! Tokyo Disney Resort is Lean!

Read more...

There’s a lot of buzz on Kanban right now in the agile software development community. Since Scrum has become quite mainstream now, a common question is “so what is Kanban, and how does it compare to Scrum?” Where do they complement each other? Are there any potential conflicts? Here’s an attempt to clear up some of the fog.

• Jim: “Now we’ve finally gone all-out Scrum!”
• Fred: “ So how’s it going?”
• Jim:  “Well, it’s a lot better than what we had before...”
• Fred: “...but?”
• Jim: “... but you see we are a support & maintainance team.”
• Fred: “yes, and?”
• Jim: “Well, we love the whole thing about sorting priorities in a product backlog, self-organizing teams, daily scrums, retrospectives, etc....”
• Fred: “So what’s the problem?”
• Jim: “We keep failing our sprints”
• Fred: “Why?”
• Jim: “Because we find it hard to commit to a 2 week plan. Iterations don’t make to much sense to us, we just work on whatever is most urgent for today. Should we do 1 week iterations perhaps?”
• Fred: “Could you commit to 1 week of work? Will you be allowed to focus and work in peace for 1 week?”
• Jim: “Not really, we get issues popping up on a daily basis. Maybe if we did 1 day sprints...”
• Fred: “Do your issues take less than a day to fix?”
• Jim: “No, they sometimes take several days”
• Fred: “So 1-day sprints wouldn’t work either. Have you considered ditching sprints entirely?”
• Jim: “Well, frankly, we would like that. But isn’t that against Scrum?”
• Fred: “Scrum is just a tool. You choose when and how to use it. Don’t be a slave to it!”
• Jim: “So what should we do then?”
• Fred: “Have you heard of Kanban?”
• Jim: “What’s that? What’s the difference between that and Scrum?”
• Fred: “Here, read this article!”
• Jim: “But I really like the rest of Scrum though, do I have to switch now?”
• Fred: “No, you can combine the techniques!”
• Jim: “What? How?”
• Fred: “Just read it...”

Kanban vs Scrum - a practical guide

This is a draft - any feedback is welcome! For minor corrections email is probably best (henrik.kniberg AT crisp.se).

---

By the way, on May 27 we'll be teaching a one day course called "Future of Agile" together with David Anderson, one of the early pioneers of Kanban-style software development. If you're interested in this stuff I suggest you join us!

A German translation of my book Scrum and XP from the Trenches is now available. Thanks Robert Sösemann & Andreas Schliep!



Russian, French, Spanish, Japanese, Chinese, and Portuguese translations are also available. Korean, 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.

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.

1-2 days every week I schedule "slack" days, where I try to catch up on emails, do some admin, prepare for future engagements, and such. During the past year I've been using the Pomodoro technique more and more consistently and, the more I use it, the more I find that it really works well! It has changed the way I think of time.



Pomodoro is similar to Scrum - but at a "micro" level. Although it can be used for pairs and teams, it was originally designed for individual use. To me this feels sort of like a single-person Scrum with 25-minute sprints, with many of the same benefits :o)

There's an increasing amount of material available on this, but I find myself re-reading the original paper about the Pomodoro technique (by Francesco Cirillo) about once every 1-2 months. It's an excellent read.

Staffan Nöteberg introduced this to us at Crisp a few years ago, he now does a lot of courses and talks on this. Here's Staffan's blog with some video presentations and slides and such.

Give it a shot!

A French translation of my book Scrum and XP from the Trenches is now available. Big thanks to Guillaume Mathias, Bruno Orsier, Emmanuel Etasse, and Christophe Bunn.



Spanish, Japanese, Chinese, and Portuguese translations are also available. Korean, German, and Slovak translations are underway. I never cease to be impressed by the agile community!

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.

A Portuguese translation of my book Scrum and XP from the Trenches is now up on the Brazilian InfoQ site. Big thanks to Renato Willi for initiating and coordinating this effort, and thanks to all the other 30 contributors as well who made this happen (listed at the end of the book)!



Spanish, Japanese, and Chinese translations are also available. Korean, German, French, and Slovak translations are underway. I never cease to be impressed by the agile community!

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.

Here are the slides from my session "Multi-team sprint planning" from Scrum Gathering 2008 in Stockholm.

Here is all the other material from the Scrum Gathering. Interesting stuff!

Here are the slides from my session "Bootstrapping Scrum - Lessons learned helping companies get started" from Scrum Gathering 2008 in Stockholm. I used the same slides at the Scan-Agile conference in Helsinki Oct 29.

Here is all the other material from the Scrum Gathering. Interesting stuff!

Yesterday I was at the "Agile i Sverige" conference in Stockholm and did a keynote called "Lita på mig - löften och lögner i agila project". In English that would be "Trust me - promises and lies in agile projects".

Here are the slides. The slides are in Swedish (although I ended up doing the talk in English).

I think this topic is interesting and important so I do plan to write some kind of article or summary in english - but no promises :o)

Here's the abstract in English, just to spark your curiousity:

The agile manifesto says "Customer collaboration over contract negotiation" - but customer collaboration is based on trust. Sometimes it is hard to tell the difference between promises, estimates, and lies. We will go through some frightening examples and discuss trust in agile projects.

Here are the slides from my presentation "Vadå Lean Software Development" (Introduction to Lean Software Development) at HiQ on Oct 13.

Note - the picture above (the last slide in my deck) can easily be misinterpreted when used out of context. It is not meant to imply that XP is a subset of Scrum, or that Agile is a subset of Lean. It just means that Lean addresses a very wide scope - principals like "limit work to capacity" and "continuous process improvement" are applicable in just about any context. While XP is more concrete and limited to the domain of software development. Scrum is somewhere in between - it is not limited to software development, but still mandates the use of timeboxed deliveries (sprints) and a product backlog. Agile is higher level - just a bunch of values and principles and no practices at all. Etc.

There are lots of ways of visualizing this. My picture is simplistic, if anyone can come up with a better one let me know.

Here are the slides from my session Multi-team sprint planning. The session took place at the Scrum Forum meeting in Aarhus on Oct 1, in conjunction with the JAOO 2008 conference.