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?

Buying Back My Soul

I recently traded away my beliefs for security and comfort. I had taken a three-month contract-to-hire at a local software company.

What had I hoped to gain?

  • The company is three miles away from home, a commute of 6 minutes with only one traffic light on the way.
  • They are stable. I received an offer at the end of three months. Due to the industry (government “defense” software), it’s likely I could have stayed there for many years to come.

What was my alternative?

  • Travel. I ultimately chose to return to a life of sporadic travel, consulting and training for Langr Software Solutions. The work is great–I love what I do and love helping people. But it’s travel. For those who’ve never traveled extensively, it’s entertaining the first couple times out. After that, you quickly realize that living in hotels, suffering the hell of airline travel, eating in often-lame restaurants, and being away from home and family is simply not fun at all.

So what was wrong with the local gig?

  • Money. I’m not all about money, and we don’t live extravagantly, but this was the second time I’d taken a pay cut in two years. It’s always tough to cut back on your lifestyle.
  • Industry. I’m a realist, so I understand that “defense” work is necessary, but I’d just as soon not be part of it.
  • Process. I thought I’d be ok with skipping process for a while (they had close to zero process elements). I’d hoped to help introduce some useful techniques and ideas, but it quickly became clear that the culture wasn’t going to support it. They had been reasonably successful without any real process. Not to say that they couldn’t have taken their game to the next level, but one individual can’t change a multi-hundred-person company with zero support.
  • Culture. The folks were nice enough, but I didn’t feel like I was a part of anything. Developers tended to stay in their cubes and keep to their existing cliques. I worked on a two-man development effort (fun stuff; I learned a good amount of Flex/ActionScript). I saw my team member and my boss (both good guys) a few times a week each. The remaining 97%+ of the week, I had close to no additional human interaction.

I sold my soul. Granted, I got to build software, something I love to do, but it was a lonely existence. Had I felt like I was part of a team, as opposed to a bunch of individuals who just happen to reside in nearby cubes, I might have stayed.

I’ve bought back my soul. What’s interesting is that I’m still not part of a team–as a consultant, you are an outsider when you’re traveling, and on your own when at home. But the tradeoff is worth it: I get to help others experience the joy of being part of a true, effective team.


One thing I’ve done over the years is to mentally characterize the groups I work with and for. From my experiences with dozens and dozens of teams, I’ve come to some unsupported conclusions. Here are a few thoughts:

  • Out of 20 people, two are excellent. Three are good or have the right attitude, five are worthless or worse, and the rest will do the work but are largely there to collect a paycheck.
  • You can’t instill the desire to learn in an adult.
  • It’s very hard to teach an old dog new tricks. Forty is old.
  • Teams predominantly composed of 30-year-olds usually have their collective head on straight. Teams predominantly composed of 20-year-olds already know everything.
  • One counter-productive person on a team is enough to sabotage a project.
  • Hiring for attitude, not technical skill, results in a much more productive team. But you still will need experts. Don’t attempt to figure out on your own what expertise will get you more cheaply.
  • Forcing experienced developers to do things never takes. The team has to decide themself what they want to do.

These of course are obscene generalizations. Your mileage may vary.