About two years ago, I toyed around with the idea of a “Scrum Master Emergency Kit“. Today I’d like to show you the kit tray I really use. I hope it’s useful for people new to facilitating retrospectives (or meetings in general):
My tray contains (ordered by frequency of use):
Whiteboard markers (no Flipchart markers, so there can’t be mix-ups)
Post-Its in various sizes
Pin-It-Cards (which I don’t pin but “magnet”)
Blank paper (about the same size as “letter”)
Old plans for retrospectives and material for them
Anyone else up to showing how they haul around their stuff? And what stuff it is in particular?
At my workplace we’ve recently started following Scrum and Kanban. I head the product management team with 2 newly minted product owners. They used to be a product manager and sales engineer respectively. One has limited experience with Scrum, the other none. So how to help them find their footing in their new role?
There’s a lot to learn from trainings and books, but there’s a difference between hearing and reading about what an agile workplace is like and experiencing the reality of it. That’s why I contacted my PO friends at my former employer to see it they would let them take a peek. They would. (Thank you!)
A crate of Füchsen changed hands and N. and N. got to observe a planning meeting and afterwards asked scores of questions. They returned completely psyched: “So that’s what it’s like, when it’s ‘finished’!”
Then at last week’s agile meetup, Sven mentioned that he’d like to do a similar exchange, but that it can be difficult to find a partner, if your company doesn’t have several people in the same role and you lack connections to other agile companies.
Wouldn’t it be great to have a place to look for such exchange partners? Our neighbors, the Software Craftmen, are already talking a lot about craftsmen swaps. We could copy that and make it more broad. Swapping jobs for weeks might work for Coaches and Scrum Masters, but is probably difficult for Product Owners. For them Pairing or even just passively observing are more viable options that still provide valuable insights. And while we’re at it, let’s include the lean practitioners as well!
There are many ways, such a platform could work. Here’s my concept:
You don’t have to wait for the One-on-One. Give feedback when the event occurs and both parties still remember what it’s about.
“The was a great presentation!” is not as helpful as “The part with the examples was great!” is not as helpful as “The part with the examples was great! I think this helped everyone to orientate and get started quickly.”
The “specific” bit is the one I struggle with the most. Fortunately the following three feedback models help me with that:
1) Situation – Behaviour – Impact
Applicable after you’ve witnessed specific behaviour. Even suited when you do not have formal authority with someone, because you’re not telling them what to do. You merely mirror their behaviour back to them as factual as possible.
In the meeting, when you started to sketch on the whiteboard you really helped getting everyone on the same page.
In the meeting, when your cell rang and you answered it, it distracted us all a lot.
[English Summary: A list of meetups on Agile or Lean topics in Düsseldorf - where I live - and its surrounding cities.]
Heute habe ich zum zweiten Mal eine Liste aller agil angehauchten Stammtische in meiner Umgebung zusammengestellt. Sobald ich etwas zwei Mal mache, wittere ich ein Pattern. Vielleicht ist die Liste ja für noch mehr Leute interessant. Here we go:
Every once in a while I think about developing a product and / or founding a company. Up until 5 years ago I thought “the idea” would be crucial – that the product idea would make the difference between failure and success. Then I realized that ideas are cheap and the hard part is follow-through: To pick one idea – out of the millions of ideas out there -, make it a reality and sustain it. That’s the hard part!
The Lean Startup is about learning what your customers really want. It’s about testing your vision continuously, adapting and adjusting before it’s too late.
Makes sense, doesn’t it? You’ve got an idea, test it, implement a minimum viable product, hone it and are hopefully successful. And yes, it does make sense, but it still has the premise of “idea first”; even if it incorporates that your initial idea and the product you end up with, won’t have much in common.
Last month I discovered that you can also arrive at a successful product from a very different starting point: Amy Hoy makes a case for choosing your customers first and then creating a product for them. Instead of a Minimum Viable Product find Minimum Viable Customers! *mind blown* Continue reading →
In his superb video explaining the role of the Product Owner Henrik Kniberg chooses “Number of completed stories” to measure the teams capacity (velocity). He mentions story points, but chooses a less widespread measure. Why did he choose it? Don’t know. I only know that I would make the same choice:
Any metric can be gamed. Story points are especially easy to game, as the amounts are only meaningful within one team. And it takes just one ill-timed “Why isn’t the velocity going up?” to kick-off story point inflation.
But hey, can’t “Number of completed stories” be gamed just as easily? The team just has to make the stories smaller.
Why, yes. Precisely! It’s a metric I want teams to game!
In my experience it’s difficult for “fresh” agile teams to cut stories down. It’s a skill that grows with practise. People not accustomed to splitting stories into nice vertical slices tend to think it’s not possible. And they often don’t see the value in it, so they don’t really try.
Pointing out the value I see doesn’t necessarily help, although small stories…
… are more thought-through
… have less open questions
… have a lower probability to turn out way bigger than expected
… contain less uncertainty and bad surprises
… have a higher chance of being completed in one sprint
This time we tried out the “Lean Coffee” approach to facilitate a discussion in the whole group about a range of topics. As the meetup takes place in a brewpub for Düsseldorf’s typical type of beer “Altbier” we dubbed it “Lean Altbier” and it went down like this:
Everyone writes down topics they’d like to discuss on stickies (1 topic per sticky)
Stickies are collected and read out. The person who wrote it describes the topic in 1 or 2 sentences
We put all stickies on a cardboard menu and passed it around the table so that everyone could distribute 2 votes
Order the stickies according to votes
Start with the topic of highest interest
Originally we thought we’d just talk about each topic until the discussion dies down, but it seems that discussions rarely completely die. Just more and more people detach until only 2 or 3 keep talking. So I’ve started to set a timer and once the time is up, people give a quick thumbs up or down. Majority of thumbs up gives the topic an additional time box, thumbs down moves the discussion on to the next topic. This makes sure that the discussion stays interesting for most participants. Continue reading →
… or Scrum Master or whoever is at times upset with processes, structures or systems.
Last Tuesday at the agile meetup in my hometown we started to joke around about what happens when projects or processes go awry. In the course of the evening we came up with 5 fitting songs – title-wise at least: