How did you introduce pair programming at sipgate?

Recently I’ve been presenting our Work Hacks at a couple of places and talking about pairing up as part of it. Not only do we pair program but we also mob program and pair up across roles: Dev and UX designer, PO and customer support, UX and PO, dev and customer support, dev and … You get the idea. We’ve done just about every combination our very cross-functional teams allow for.

Whenever I talk about this, a common follow up question is: “How did you introduce pair programming?” or “How did you make people adopt pair programming?”

Short answer:
We didn’t. Nobody made a concerted effort to establish pair programming at sipgate.

Long answer:
Not long after we started using Scrum it dawned on us that Scrum alone wouldn’t save us. Only combined with sound software engineering practices such as the ones from XP would we be able to improve our codebase.

Sometimes I hear tales by developers from other companies about management not wanting them to pair program or TDD. In our case the opposite was true. Our management was okay with TDD and pair programming. There just weren’t many people interested in doing it.

Fortunately “not many” is more than “nobody”. There were some curious minds and teams who started to try it out.

It worked well for them so they kept doing it and told others about it. And what do you know, just a few short years later (about three or so) the tables had turned and pairing up was the new normal. Now you were the oddball when you didn’t want to pair up.

To this day it depends a lot on the team. Some teams pair up all the time, some mob, some only pair up for critical stuff. All of that is okay.

We all agree that pairing programming leads to fewer defects and better readability. And pairing up across disciplines helps us keep tight feedback loops and to spread knowledge.

We have it backwards

We don’t go out and do difficult things because we’re confident. We do difficult things and that gives us confidence.

We don’t work longer hours and get more done. We work less, sleep enough and get more done.

We don’t have more defects in production when we deliver often. We have fewer defects when we deliver more often.

Immigrants don’t take away jobs. Immigrants create more jobs than they take.

Makes me wonder what else we’ve got backwards…

 

Agile is about usability. So is Clean Code.

Maybe it’s because usability was such a strong focus of mine for such a long time but I feel like most good ideas boil down to usability. It’s kind of my “grand unifying theory of good practices”. To me, Agile Software Development is about providing good usability to the customer (not necessarily the user). Clean Code is about good usability for other developers. They’re both about going the extra mile to make someone else’s life easier.

Agile Software Development is about providing good usability to the customer

Not convinced? Well, I hope it’s easy to see how Clean Code will make code more usable for its future maintainers. That’s why I’ll concentrate on making the case that agile software development is for product development what usability is for product. Continue reading

Improve your Retrospectives with this 1 weird trick: Liftoffs

When health is concerned, preventing issues altogether is often easier than treating them once they’ve manifested. The same can be said for retrospectives:

In retrospectives we often make up for the fact that we didn't have a liftoff

Either Deborah Hartmann Preuss or Steve Holyer said that in a conversation and it rang true. Very few teams get a proper liftoff and they lose weeks and months of productivity to initial friction. In contrast, a proper liftoff sets up a team for success by laying a solid foundation of agreements and shared understandings. Then the team doesn’t have to spend their retrospectives patching up problems that could have been avoided.

What are liftoffs exactly?

You might know them as kickoffs, jump starts, launches or project starts – a meeting at the beginning of a team coming together and / or starting to work on something. I’m going with the name “liftoff” because of the book by the same name written by Diana Larsen and Ainsley Nies. Continue reading

Story Cubes for Retrospectives

Sometimes we have guests over who want to learn more about our Open Friday and see it in action. Lately we’ve been asking for a session in return so that visitors add to our pool of knowledge. These guest sessions are often interesting and sometimes you strike gold: Cynthia Hohlstein and Kevin Plechinger hosted an inspiring session on and with Story Cubes. Because neither of them blogs, I get to share their idea with you: Story Cubes are sets of 9 dice with images on them. The images cover a wide range of motives, such as a speech bubble, a sheep, a star, a hand or a walking stick figure. The idea is that you roll 3 dice and then tell a story that contains the 3 motives you rolled.

3 Story CubesThis can easily be turned into a fun activity for agile retrospectives if players answer a question instead of just telling a story. Cynthia and Kevin already had a couple of ideas:

  • What was last sprint like?
  • How do customers view our product?
  • What’s the state of agility here in our company?
  • What was your carreer path? How did you get here?

We spend the hour-long session answering questions in groups of three. It was very interesting because the cubes prompt you to talk about aspects you wouldn’t normally have touched on – you tell the truth and still have to incorporate the 3 images. Among others, we used the “Customer View” question and it was quite revealing. Story Cubes help with changing perspective and add a fun element.

Thank you Cynthia and Kevin for introducing us to story cubes!

PS: Interested in retrospectives? Sign up to the Retromat newsletter to get related news and tricks!

 

5 more things I learned at Agile on the Beach 2016

From Kat Matfield’s session “User Research in an irrational world”:
1) If at all possible, look at records of what people actually did in the real-world situation, (screen recordings, chat logs, …) instead of putting them into a research situation (in which they will always pay more attention) or asking them to remember (memory is extremely unreliable).

From Gez Smith’s session “Agile Marketing”:
2) Maybe 1 thing goes viral per year. Rest is planted and pushed with fake accounts

From Darci Dutcher’s session “Running killer workshops without killing yourself”:
3) If you use dot-voting and don’t limit the number of votes you get information about the long tail of interests. Not relevant in short retros but maybe for a longer workshop.

4) A retro is a sub-kind of workshop. I never thought of retrospectives in those terms. Nice realization.

From my own session:
5) Putting your cell phone near a mic is a really bad idea (audio feedback)

I also learned about Jeff Patton’s Cups, the sticky note bonus shape and that I’ll try to remind more speakers to repeat the audiences question before answering it.

All in all, a very nice (knowledge) haul 🙂

 

 

Of Baby Elephants and MVPs

As you know, I’m a sucker for a good metaphor be they coconuts or hosting. I’ve got a great new one for you: Baby Elephants! Fantastic, right?

Well, yes, it’s promising. Baby elephants – What’s not to like. But what are they a metaphor for, pray tell?

Cute baby elephant courtesy of Beratung Judith Andresen

Cute baby elephant courtesy of Beratung Judith Andresen

Judith Andresen introduced baby elephants as a metaphor for MVPs at Agile on the Beach 2016. One immediate benefit is that it short circuits endless, mostly fruitless discussions along the lines of “What exactly is an Minimum Viable Product?” “We need  an Minimum Marketable Feature instead!” “No a Minimum Loveable Feature is the way to go!” “No, it has to be a …”

Instead of arguing about different concepts, baby elephants give people concrete images to work with:

  • “I think we’re building a teenager elephant here, not a baby anymore.”
  • “We’ve got too many baby elephants in the stable already. Let’s get those out before acquiring a new one.”
  • “What are young mammoth trees (which the elephant is supposed to move) in our context?”

Judith’s fable includes much more, e.g. the context in which a baby elephant is an excellent MVP. Read the whole fable about nature-oriented forest management with baby elephants here.

Sense-Making Machines

Once, on our way to the movies our tram stopped at “Heinrich-Heine-Alley”. It’s a popular tram stop in Düsseldorf, especially for tourists. One such (German!) tourist exited there with his family and remarked: “Ah, Heinrich-Heine-Alley, he was mayor here once.”

That tourist was making sense of his surroundings and “previous mayor” seemed like a reasonable reason to name a street and station after. It is reasonable. It is also wrong. Most Germans (and surprisingly Russians) know that Heinrich Heine was a poet. (I think Heine was born in Düsseldorf, but I don’t really know. I’m just sense-making here ;))

Humans are sense-making machines in search of a narrative. If facts are missing, we’ll often make them up. Once we got the narrative established it’s hard to let go. It’s why we keep going in the wrong direction, despite disagreeing signage. I love this episode as a reminder of how (made-up) context is everything in Usability. There’s no telling where users end up if they start with a warped context and it’s not their fault. It’s surprising to me that a fellow German doesn’t know Heine, but I’m also aware that it’s entirely possible to be smart and live a good life without knowing that tidbit. It’s not essential. Neither are the ins and outs of your software and its context. Be as obvious as you can.

PS: Fact-checked Heine: Yes, he was born in Düsseldorf, died in Paris. He was never mayor 😀

Host Leadership is the better metaphor

Whenever someone mentions “Servant Leadership” it triggers an almost Pavlovian reflex in me to say: “Have you heard of ‘Host Leadership’? IMHO it’s the much better metaphor for Scrum Master work.”Host-Leadership

Part of SM work is enforcing rules. How can you do that as a servant? The metaphor breaks. As a host it makes perfect sense: You have to make sure that everybody is having a great time and not one person ruining it for many. As the host you set house rules.

Despite being a big fan I haden’t even mentioned Host Leadership in this blog, yet. Until now 🙂 If you’d like to know more, here’s the 6 roles of Host Leadership and the official webpage for Host Leadership.

Letting go of decisions

When building self-organizing teams, one of the hardest things for their (former?) managers is to pass power on to the team. Power as in “the possibility, ability and duty to take decisions”. If you pass a decision on, you have to let go of your “solution”. There are infinite solutions out there. Don’t expect the team to pick the exact same one that you would have. The chances are rather slim.

Unfortunately this is how I sometimes see it go down:

Manager thinks: “The solution is obvious. But I’m supposed to empower them, so I can’t just tell them what to do.”
Manager to team: “It’s your decision. Figure It out. You can do it.”
Team goes and figures it out.
Team to manager animatedly: “Look, here’s our solution :)”
Manager: “Umm, no. No, it ain’t. <Some leading questions> It’s your decision. Figure It out.”
Team goes and figures it out. Again.
Team warily: “Sooo. Here’s our solution attempt.”
Manager: “Umm, wouldn’t it make sense to … <Some more leading questions>”
“Together” they arrive at a new solution.
Team is quietly steaming.

This is the opposite of empowerment. Having to reverse engineer a fixed solution by trial and error is painful, disheartening and teaches a terrible lesson. As someone who used to be on the receiving end of this, I’d love for the manager to just straight out say what they want. They are the boss. It’s okay for them to dictate the solution, if there’s no wriggle room. But making teams guess over 3 rounds, because they don’t want to dictate a solution? That achieves the opposite of want they intended. Plus, they blur the line. It becomes harder for teams to tell when they really own the solution and when they secretly don’t.

Sometimes the solution mismatch stems from the manager having more information than the team. As the team, strive to become good at asking questions about constraints.

As the manager pass information on to your team as soon as you notice they’re missing. If it’s classified information, you probably shouldn’t that particular decision on to the team.

And check out Delegation Poker. It can help managers and teams figure out, how much power is really conveyed for each pending decision.