Feedback is important. Only by knowing how our actions affect others do we know what works and what doesn’t. Feedback becomes more effective, when it is frequent, timely and specific.
Giving feedback only at quarterly or yearly reviews wastes a lot of time during which people could already have improved. Weekly One-on-Ones (that I recently proclaimed my undying love for) are a great opportunity to provide or get feedback.
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.
2) What worked well – Even better if
Have you ever had regular One-on-Ones (“O3s”)? If not, I think you’re missing out. Mark Horstman and Mike Auzenne describe them as:
- 30 minute conversation every (other) week
- Between a manager and one of her team members. (Each team member gets their own O3 each week.)
- Default time division: 10 minutes team members topics, 10 minutes managers topics, 10 minutes for coaching or mentoring
Now that I finally experienced O3s, I agree with Mark and Mike that they are the “single most effective management tool“.
Here’s what I think is awesome about O3s for the team member:
- It’s a very close feedback loop – You always know whether what you’re doing contributes to the company’s overarching goal
- Which for me goes hand in hand with “Having Purpose”
- Validation – You are important enough for your boss to take time to listen to you
- Guaranteed sync point – You don’t have to disturb your boss because you know there’s a time to tackle all non-urgent issues in the O3
As the manager you can: Continue reading
[English Summary: I’ve translated Henrik Kniberg’s excellent “Product Owner in a Nutshell” into German. Next post will be in English again, pinkie promise!]
Kennt ihr schon Henrik Knibergs exzellentes Video zur Rolle des Product Owners? Falls nicht, lege ich es euch sehr ans Herz. Jetzt sogar auf mit – frisch übersetzten – deutschen Untertiteln:
Ich bedanke mich herzlich bei Cédric Chevalerias für die französische Datei als Vorlage und hinterher das Video mit eingebetteten Untertiteln.
… or Small stories kick ass!
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
- … are more focused on value-adding functionality
- … easier to talk about Continue reading