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?”
We didn’t. Nobody made a concerted effort to establish pair programming at sipgate.
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 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…
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.
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
When health is concerned, preventing issues altogether is often easier than treating them once they’ve manifested. The same can be said for retrospectives:
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
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.
- 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!
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 🙂
Well, yes, it’s promising. Baby elephants – What’s not to like. But what are they a metaphor for, pray tell?
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.
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 😀
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.