Code Socialization

The first rule of Fouled-up-code* Club is you don’t talk about the code.
The second rule of …

We don’t talk about the code, and so most of us are members of F’d-up-code Club. We’re not socializing the code enough. Shop upon shop I visit, I ask when the programmers discuss what’s in the code with each other. The usual answer?  “Once in a while.”

If you’re not regularly talking about the code as a team, it’s getting worse. And “it” includes the time to understand the code, the time to fix the code, the pain the code causes you, the defect count, and ultimately the extent to which you have a real team.

We create standards but they idle and adherence falls off, and the code shows it, and attempts to get back on track fall short. We pair-program, but don’t switch pairs mid-story, and the solutions show it. (Yes, two heads produce a better-than-one solution, but a pair deep into understanding of their feature can easily produce a solution that makes little sense to others.) We hold tepid brown-bags that bore attendees and ultimately taper off in quantity. We hold retrospectives, sometimes, but the process crud dominates, and the audience isn’t usually right for talking about code problems. We sit in the same area (well, a small number of us do), but rarely call others over to our monitor to look at some cool or challenging code.

Try this (the opposite of the prior paragraph, duh):

  • Revisit your standard once a quarter at least, or simply when someone wants to visit a specific standard issue.
  • Pair program and take advantage of the two-heads effect. If you can’t pair, incorporate a streamlined inspection process. If you can pair, switch pairs at least once mid-feature. See if the third party can make sense of your tests and solution with minimal assistance from you.
  • Run end-of-day code sharing sessions on the LCD projector. Limit them to 15 minutes, and shoot for 5 minutes. “Hey, can we stop doing this in the code?” Or, “Here’s a new reusable construct that we should all be using.” Or, “Here’s an effective tool tip I learned.”
  • Find 60 minutes for a programmer-only retrospective each iteration. Make sure what comes out of them are commitments to improve that are actually met (otherwise don’t bother).
  • Don’t wait for the end of the day or a pair switch to discuss something important in the code. People should feel comfortable about standing up and finding an audience for a 5-minute ad hoc code discussion.

* More blunt folks can substitute other words for “fouled.”

How’s Your Daily Standup Working for You?

a daily scrum
needing the walls to stand!

I posted a response to a blog post entitled “Why I hate SCRUM daily standup meetings,” but it’s still awaiting moderation after a couple days. I’m impatient, so here’s my comment:

====== From: @jlangr ======

“On top of this, they need to setup a meeting to learn what my collegues are working on feels so wrong to me.”

Agreed. If you are a good team that already finds ways to get together and talk about what’s important, a formal meeting is a waste of time. Sitting in a common area where this can happen throughout the day can make it even less useful.

Having said that, it’s great starter discipline, and can be useful in environments where it’s not easy to get people together (I’ve been in places where I wasted way too much time trying to track people down or when my attempts to discuss things were rebuffed by people who were “too busy”). I’d start a new team on daily standups, but would push the team to find ways to eliminate the need for them once they got better at working together.

Also, most shops that run daily scrums and don’t get much out of them aren’t collaborating enough. It becomes one person reporting status, while the others worry about what they’re going to say when it’s their turn (because “that stuff” has little to do with what they’re doing). If that’s the case, you may as well revert to people sending an email with their status to the project manager, who gathers and emails a summary of what’s important to the team.

But…that’s not what works best in agile (or lean). See Stories and the Tedium of Daily Standups: What works best is real collaboration, which in turn makes the stand-ups far more useful and engaging. There’s also an Agile in a Flash card for that!

I’d love to hear more positive stories about stand-ups, given that most of the time I hear from people who’ve learned to detest them. Good or bad, how’s your stand-up meeting working for you?

Atom