Active positive feedback

Posted by Patrice Neff Thu, 20 Nov 2008

At we have a Wall of fame in our wiki. In my personal opinion this is one of the best ideas we’ve ever had when it comes to our team organisation. The reason is that negative feedback gets delivered very quickly and all the time. Strangely enough you have to invest more in making sure positive feedback also gets around.

So what happens now is that if somebody helps a colleague or the whole team in a special way, that person gets an entry in the hall of fame. It’s a really encouraging sight to scroll through that list and see how much people are helping each other. And how thankful the recipients are.

This image shows an anonymized extract.

Overcoming Scrum prejudices

Posted by Patrice Neff Tue, 18 Nov 2008

Scrum is a software development method. It’s been on my radar for a long time but mostly with a negative air to it. After I finally overcame a lot of my prejudices, I recently started to look into it seriously. And it turns out it makes a lot more sense and it’s a lot easier than I used to think. I blame the gazillions of Scrum consultancies out there for sometimes overcomplicating things. In the end it comes down to these few points:
  • Team: Each team is able to fulfill its goals without having to rely on the outside world. They coordinate very intimately – ideally with a short status meeting every day.
  • Scrum master: A person appointed by a team. His job is to keep the team focused, to prevent them from getting interrupted by outsiders and to remove hurdles which keep the team from working efficiently.
  • Product backlog: A prioritized list of stories (aka projects or tasks) which need to get done. Only the top stories get specified and it’s length estimated.
  • Product owner: This person is the lord of the product backlog. He’s the lone decision maker for priorities in the product backlog but coordinates with all the interest groups to make sure it’s balanced.
  • Sprint: The teams split their work in sprints – which by default have a duration of exactly 30 days. At the start of the sprint the team takes the top n items from the product backlog. How many items they take depends on how much they think they can get done. During the sprint the list of stories must not change anymore and the team should not be asked to do things which have not been specified in the sprint.

If you understand those points you get Scrum. Seriously, don’t try to make more out of it.