Post Category → Self-Organization

Give feedback to new team members with SaMoLo

It’s helpful for new employees to get feedback on how they’re doing in order to adjust to their new workspace. In traditional companies this might be done by a team lead or superior. In Scrum – as so many other rights and duties – this falls to the team.

Although new members tend to come up as a topic in the team retrospective, it’s usually as a side note and only after they’ve just started. We felt that on boarding new colleagues is important enough to give each their own dedicated retrospective with the following structure:

All team members but the new one meet and collect feedback in 3 categories:  “Behavior we’d like to see the same amount of”, “More of” and “Less of” (SaMoLo). They discuss the issues, group them and decide who will present the feedback. Then the new colleague joins to hear and discuss what they’re doing great and where they can improve.

Continue reading →

Dinner with a Stranger – A Design Pattern for Conferences & Open Spaces

Last year, while studying the program of Agile 2011 I read about “Dinner with a Stranger” for the first time:

Socializing and networking are an integral part of Agile2011. If you’ll be attending Agile2011 alone, make sure to stop by the registration desk and sign up for “Dinner with a Stranger” on Tuesday, August 9th. Just add your name to one of the sign-up sheets with the names of nearby restaurants and grab your “I’m a stranger” ribbon. Later that night, put it on and meet your fellow participants for dinner and great conversation.

Most excellent idea! I wouldn’t limit it to those “attending alone”, though. It’s when I’m with a group that I have difficulty meeting someone new. When I’m alone, I meet new people because I more or less have to. But in a group I get all my information and communication needs fulfilled without stepping out of my comfort zone and reaching out to a stranger.

Put yourself up for Dinner with a Stranger

In the end I did not attend Agile 2011 and planned for ALE 2011 instead. I suggested “Dinner with a stranger” to the organizers and thankfully Marc Clemens teamed up with me. He researched restaurants and made reservations. I spent a weekend creating info flyers for each of the restaurants.

When the conference came, we put up 4 pin boards and watched the participants sign up to the table they knew the least people on.

I went to a Bavarian restaurant and got to know very nice and interesting people. From what I’ve heard it was a splendid evening for all groups. The dinner had achieved its goal: Continue reading →

Visualize it! – An ode to whiteboards

Two months ago I started a new job. I left nice old colleagues and got nice new colleagues. The companies are the same size. No big diff there. But there is a very visible difference in the respective offices:

  • Old workplace: 200 square metres of whiteboard surface + glass walls – all of them covered with drawings, notes and print-outs
  • New workplace: 4 square metres of hardly used whiteboard surface and empty walls

The impact on communication is tremendous. Meetings in which we talk about systems I’m not yet familiar with and no one draws a picture… I’ve always thought I’m the visual learning type. Now I’m sure of it, because without a sketch I can only follow half of what is being said.  I find myself unable to picture it in my head.

Unfortunately I can’t remember what it was like before my last job…

  • Was I once better at picturing stuff in my head, then lost the ability, because visualization made it unnecessary? Like an untrained muscle?
  • Or was I never able to do it? (But since I hadn’t known that 98% understanding are possible, I didn’t realize I was missing out.)

Continue reading →

Na na na na na na na na Bug Slot!

<Sing title to the melody of the batman theme song>

In the company I just left we had a weekly bugslot to stay on top of defects: 2 hours every week during which all developers fixed bugs at the same time. It’s not a perfect solution but solved a number of pressing problems:

  • Discouragingly high number of bugs – accumulated over a long time
  • No overview / documentation / communication of what was fixed, what deployed, and what left to fester
    • We had no bugtracker. (The developers never reached agreement, which one to use.)
    • The same bugs appeared again and again, their symptoms often fixed by different people, so that no one recognized patterns
  • No order given in which to fix
    • Decision if and what to fix fell back on each individual dev. And as bugfixing took time away from the sprint and the team commitment…
  • About 30% of all developers were new hires, yet unfamiliar with the systems
    • The systems weren’t documented, so the new devs had no chance to fix bugs on their own. It was left to the “old” ones, who groaned under the additional workload

The situation in my new workplace is similar enough that I suggested a bugslot as well. It  has a good chance of doing the trick again.

How exactly does a bugslot work?

  • 2 hours each week for fixing (non-urgent) bugs
    • At the same time every week
    • All developers at the same time
    • Pick a week day and time that most developers will be there. Lunch time’s holy, though 😉
  • Before: Order the bugs. What needs fixing first is first in line
    • Can be done by product owner, stakeholder such as costumer support, …
    • Publish the list highly visible
      Continue reading →

Want Change? Make “your” way the easiest way

If you want to establish new ways to do things (i.e. processes), make sure that this new way is the easiest route for people to reach their goal. If the old way is easier, the new one won’t ever be adopted.

Example:
There is a new way to handle support, designed to let the developers work in peace: The supporters place tickets up a wall that the teams pull and solve within 24 hours. Dean, a developer is upset because Stan, a supporter, ignores the new process. Stan approaches Dean directly – ruining his flow – to push him support tickets. Just as he did before the change.

I’m Dean’s scrum master and Dean’s venting his anger about Stan’s frequent interruptions. Dean wants me to do something about it. The catch is that when Stan approaches Dean directly, Dean actually solves the support ticket directly. Not only does Stan’s shortcut work, it works faster = better, than the official way! Sure, it’s harmful to Dean’s work, but that is a pain Stan doesn’t feel. Continue reading →

Systemic Consensus

Cover: Systemisches KonsensierenYou know that saying “Don’t judge a book by its cover”? Well, I usually do jugde a book by its cover and I’d never have bought “Systemisches KONSENSIEREN” (“Systemic CONSENSUS”)! When a colleague dropped it on desk, I made fun of it – its whole appearance is “touchy-feely” in a bad way and, come on, CAPS? Really?

Fortunately, I picked the book up on a whim and its main (and only) idea immediately took the top position on my list of “things to try out”: When voting, don’t have the usual majority vote that generates winners and losers. Turn traditional voting upside down and determine least resistance!

Let me illustrate how that works with the first example in the book: Continue reading →

Getting things done: Daily goals

Searching for ways to stay more focused on the stories, several of our teams use the following trick: Each morning during standup they set themselves a daily goal.

Daily goals (“Tagesziele”) for each team member

In some teams these goals are for the whole team, in others each team member sets a goal for themselves (or pairs). Either way works fine for us and achieves several things:

  • It creates a mini-deadline that helps those who thrive on deadlines and for whom the end of a 2-week sprint is to far ahead
  • Finding the next day that you reached the goal gives a sense of achievement (a bit more than moving stickies)
  • If the goal doesn’t change (because it’s not reached) it becomes blatantly obvious that there is an impediment and you can thus address it

Daily goals for a team

So if you’ve got problems focusing or with impediments not being raised, daily goals might do the trick 🙂

PS: In case it wasn’t obvious: The teams set their own goals, not someone else.

Places for information radiators

Big visible charts are a great way to convey information. The more visible something is, the less likely you are to forget or disregard it. This week we tried a new location, when we needed additional maintainers for a handful of systems: Right next to the rest rooms (the door slightly ajar is the Gents).

“Daemons looking for a maintainer”

Works pretty well, much better than the lone email, that we traditionally sent. Already 5 out of 6 daemons have found a loving home maintainer. Added bonus: By striking out these daemons we indicate the progress for everyone 🙂 Continue reading →

Eliminate Waste: Caretaker of the Week

Apparently I’m stuck on the topic of decisions, but whereas the last post was about manifesting decisions, this one is about avoiding them. Well, at least a certain kind of decisions: The kind where teams need to do something regularly, but it doesn’t matter which team member does it, as long as it gets done. Let me give you some examples:

  • Who takes care of ad-hoc support requests in a team of admins doing kanban
  • Which scrum master writes the weekly “What are the scrum masters doing, anyway”-email
  • Which team member attends the SoS. (In my workplace the SoS is a stand up of team members, not the scrum masters.)

Because each of these decisions is tiny and not very significant on its own, people are sometimes reluctant to agree on a long-term arrangement that eliminates the string of tiny decisions. They figure, they’ll just take them each time they present themselves, because, hey, tiny, right? What ill could possibly happen?

Turns out, a variety of ills: Continue reading →