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
Another month, another agile meetup:
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
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.
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.
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
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.)
<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
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.
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
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.
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
Wanna know how we distribute support tickets between developers / scrum teams? I’ll first describe an approach that didn’t work, followed by one that works for us (and Immobilienscout24, because we totally copied it from them). Continue reading