June 2010 Archives

I love standup meetings. Not because they’re fun little quick interactions with all the people I love, but because they’re a springboard for the discussions where real progress is made.

Too often people make the morning standup into a communal high-five. Everyone performs the ritual, then silently scatter back to their respective cubes. This is sad. I think one of the secret benefits of the standup is the opportunity for the micro-meetngs that can be spawned.

I grab at least one product manager or developer after the huddle and drag them to my cube to physically show them what I’ve got.

Sometimes it’s a whole lotta nothing. They look at the screen, kind of shrug, and go away. Often, though, we end up having a tremendously productive session about what direction a feature should take, or what the technical approach should be on a certain point.

Remember, even if your product manager is never available, you’ve got them in person for that team standup. Take advantage of that face time and solicit some real feedback.

Bottom line, if you’re not talking to people from the standup after the standup, you’re doing it wrong.

Military Agility

| Comments

Here’s a paper on agility[pdf] put out by the Department of Defense Command and Control Research Program.

It’s short and puts forth some generic but excellent points on why agility is going to be a big deal.

In a Nutshell

  • We face “Complex Endeavors”: problems/projects/missions that are complicated and require lots of people/systems/tools to finish.
  • Accurate prediction when working with a Complex Endeavor is impossible.
  • Agility succeeds where prediction fails. So be agile.

My Favorite Parts

We are incapable of adequately predicting the future; yet, we still design and optimize our organizations and systems based on flawed predictions.


People provide the most effective means to compensate for shortcomings in organization, process, and systems; yet, we are not investing in nurturing and enhancing this innate capability.

The Agility Imperative: Précis (pdf) by David S. Alberts - [The Command and Control Research Program]

via - Agility, the Age of Interactions, and the Military [Agile Advice]

Recipe for a Death March

| Comments
Skull and Crossbones!

My software death march recipe.

1. Big-Ass Requirements Documents

Business owners, take heed. The first whiff the developers get of an incomplete requirement, they’ll sit and hold their breath until someone acknowledges their collective awesomeness and the failings of such a poorly defined specification.

Take the time to create a monolithic testament to verbosity and complexitude. It will pay off in spades.

2. Lots of Approvals

Once the massive requirements doc is done, be sure to have it approved. By everyone. Take lots of time for minor tweaks to language and debate over everything. This will take as long as it takes. You can’t rush approvals.

Oooh, and also get a bunch of visual aids and pixel-perfect mockups. Have those approved, too.

Do not, under any circumstances, plan for what might happen if things aren’t approved. That’s crazy talk.

3. Lots of Big Meetings

If the sacred Requirements Document doesn’t provide some detail, stop all work and call a meeting. The more people in the meeting the better. It should break down like so:

  • 5 minutes to clarify the feature
  • 10 minutes of re-hashing that same point
  • 45-65 minutes of wild divergence to other gripes since people feel guilty cutting such a well-attended meeting short.

4. Shorten Testing Time as Needed

Remember, testing is the most flexible phase of your project. If development runs long, don’t change the live date, just squish the QA time. This always works.

5. Don’t Change Scope

If things aren’t going too well, DO NOT even hint that some features could be dropped, or that the live date move. Just ask everyone to work harder, work weekends, or perform some kind of digital miracle.

6. Complain

Developers, take the necessary time and effort to complain to whoever will listen about the weak-assed requirements, and how it’s impossible to work with them. Do not find any product owner. Do not engage them in informal face-to-face meetings. They have their own cubes for a reason.

7. Never Look Back

No two projects are the same. Anything you might learn from this one is useless on the next. Don’t waste time with silly retrospectives, improvement ideas, or a dumb “lessons learned” document. Move on and be thankful this thing launched and is done with.

[photo courtesy Chris Flemming. Some rights reserved]

sharpie_magnum.jpg

My brother the architect once quoted some design guy at me:

If you get stuck, grab a fatter marker.

I like that idea. The bigger marker makes it impossible to draw small details, thereby making you focus on the larger design as a whole.

If you’ve been in a meeting where a programmer says “whatever, we’ll figure it out”, they’re not being dismissive, they’re just doing the nerd version of getting a fatter pen.

Of course at some point you’ll need to figure out those details, but attempting it too soon means you can lose sight of the goal. Stepping back can also eliminate some of those gnarly details if doing so makes you realize they’re really not needed.

(PS - if you know who that quote is from, I’d love to get it right and give credit.)