A team has a common goal

At the moment I’m part of a really great team. We don’t even have a proper backlog, but it still works, because we have common long-term and short-term goals and a very clear shared vision.

However, in 2010, we already had teams, too. Well, “teams”. Teams in the name only.  See, back in 2010 we were still siloed. The “teams” were actually just a bunch of people sitting in the same room, doing similar things. We would say “backend team” although everyone in the group build and maintained their own system. To say it with Shakespeare:

Sharing a room doth not a team make.

A team has a common goal. Team members help each other reach this goal. None of the members has an individual goal more important than reaching the team’s goal. If there’s no common goal, don’t call them “team”. Call them “group”. Thank you!

Bias for Action

… or the Anti-“Somebody else’s problem field

At one point I worked at a company where I would waste 5 minutes every time I wrote an email, thinking about the recipients of that mail. Not about who needed the information, but about who would be pissed – for vanity or political reasons -, if I didn’t include them. Besides time it wasted a lot of my energy because I disliked these games so much. A “cover your own ass” environment like that is toxic for initiative. It leads to a “not my job” attitude, if even slight deviation yields repercussions.

How much could we have achieved if us lower level employees could have run with our ideas? If we had been encouraged to show initiative and implement improvements right away?
Fortunately I work in the promised land right now: People running with their ideas and taking responsibility happen all the time at my employer and it’s awesome!

Example: Demo time

It was demo day. For us that means that all teams present what they launched in the previous 2 weeks. All in all 30-50 people. Usually we do this in the big conference room, but it was closed that week due to water damage.

10 minutes prior to the demo my colleague looked up from his screen and asked “Huh, where are we going to demo with the conf room out of order?”

In pre-agile 2010 times that would have been it. End of story. We would have assumed that “somebody”, e.g. the scrum masters, took care of it. All teams would have congregated somewhere and spend 10+ minutes watching someone set up a projector and screen and laptop and … 40 people looking on for 10 minutes? That’s a whole work day we would have collectively wasted.

Not nowadays, though. We were aware of the problem and we were capable of solving it. So we did.We used 10 minutes of 4 team members to get the equipment, set it up and gather everyone in the new location. Everything was set up and running at demo time. Nobody bored. Nobody annoyed. No time wasted.

How did we get here?

What happened between pre-agile 2010 and today? Do we just have more initiative? Though we do hire differently now, I think that only a small part of it boils down to how much drive individual employees have.

Here’s what’s IMO more important: Knowing that #1 you are permitted – heck, encouraged! – to improve whatever needs improving and #2 you have the time to do so. Your time and the time of other people that you need to make it happen. (Money is less important, but it helps that even bigger amounts are just one question away.) Continue reading

Yammering helps (to get rid of emails)

Is your inbox overflowing? Mostly with company internal mail? Yet, you and your colleagues still miss vital information? E.g. a year too late you find out that colleagues in France did the exact same work your team did?

That does seem to be a common complaint. Not where I’m working, though. I get maybe 2-7 emails a day. At most half of these require an answer or action on my part. It used to be many more, about 25-40, which is still little by many people’s standard. So how did the whole company – not just me – reduce their mails and everyone is still vastly better informed?


Don’t know what “Yammer” is? Think “Twitter” but just with people from your company and you join / follow groups instead of individuals. (You can follow individuals but that has never made sense to me. Unless of course I want to stalk someone and want to read their every thought even those in group “Dung worms of South East Asia”.) Continue reading

The Product Owner’s tasks according to the Dev Team

One of the questions that inspired Mail-Skills.com is: “What do you expect of a PO? What are her tasks?”

As always, the answer is “It depends”. One major influence on what I expect from a PO is maturity. Not the PO’s, the Dev Team’s.

A team that’s recently started using Scrum usually expects a user story to come with a subset of the following:

  1.  detailed description
    • sometimes with a specific solution
  2. further details as acceptance criteria
  3. list of test cases
  4. Photoshop mockups of all interfaces
  5. everything clarified with stakeholders

Can you feel the remnants of a compartmentalized, planning-heavy process?
Yet, I wouldn’t try to shake all of the habits right away. A PO trying to share those duties with the team rightaway will often be seen as not doing her job. “That’s what YOU’re here for, aren’t you? Do we have to do your job, too?”
Heaven forbid that the dev team have to clarify details with a marketing guy themselves…

The trick is for everyone to slowly evolve from “everything’s pre-chewed” to “we can and want to do this together – results will be better”.

A PO that fulfills none of the above can actually be a great PO – to a mature team. Much better than one who stifles the team’s creativity by over-specifying everything: Continue reading

One-on-Ones in Agile (Transitions)

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

Lean Altbier (aka “Lean Coffee”)

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

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