Code Softly

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.

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]

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]

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.)

Tedious tasks aren’t useless.

I’ve wanted to share this tweet for a while, and have finally found a few minutes to post it. I think it’s important.

Sometimes utility feels like futility, but someone’s gotta do it.

When faced with gnarly problems like messy databases and heartbreakingly crufty code we often sidestep the real problem: “Just throw it out and we’ll rebuild it with your favorite sexy big product/framework/language here”.

This is great, but just because something is big doesn’t mean that replacing it will solve your problem. Consider a failing football team. The stadium they play in is certainly the larges part of the operation. Will building a new one make the team better?

In the end a lot of what we do probably should be ditch-digging. Not everything is a do-over.

FUTILITY AND DITCH DIGGING - Knowing and Doing

Working harder doesn’t help.

I’m not talking about it in the “work harder, not smarter” kind of way. I mean the way people use effort as a panacea for their project process woes. It makes zero sense to say “we’ll work harder” to explain why things will be better this time.

Ask a 110 pound kid to bench press 200 pounds. Of course he can’t do it. Would you have him come back in three months to try again, with the only difference being that he’s going to try a lot harder? Heck no. He needs to prepare by beefing up, or alter the challenge to become something he can complete.

Lots of times we do this with software projects. If you’re a serial death-marcher or are constantly over time and budget, the instinct is to try again under the false assumption that putting more effort into it this time will magically create better results.

If your projects hurt too much or don’t come in on time, you probably need to make some material changes. If you really love waterfall, but it’s not working, figure out what you can change to fix your problems. You may want to try something completely different. Whatever you do, don’t spread the rumor that mere effort will make things OK.

If you’re in a typical software shop, you have a ticketing system to keep track of things. Most often these tickets track defects. Bugs.

The proper use of the ticketing system is part art, part science, and part turtle herding. Get it right and your process is a well-oiled machine. Do ticketing badly and your days will be nasty, brutish, and long.

Here’s my list of tips for wringing every ounce of benefit from a tracking tool. Not quite a cheat sheet, but close.

Use A Tracking Tool

Obviously. But I’ve worked on more than one project in which the manager declared “We’re going to track everything in this Excel spreadsheet”.

Do yourself a favor and go get whichever tracker works for you. There are tons out there, free and otherwise.

Write Good Ticket Titles

The title is a ticket’s headline. Like good email subjects, it should be informative and memorable. Your ticket will appear among tens or hundreds of other tickets. Make sure the title conveys the essence of the issue clearly.

Use words like “should”. Don’t use words like “broken”, “hosed”, or “problem”. You’re opening a trouble ticket. Those concepts are kind of a given.

Bad: Problem sorting last name

Better: Last Name Dropdown On Registration Screen Should Be Sorted Alphabetically

Bad: Can’t Buy a Man Purse

Better: Clicking “Buy” On Final Checkout Page Raises NotANumberError

Don’t Confuse Severity With Priority

It’s easy to think that something is of critical importance because it is badly broken. Remember, ticket priority is how important it is that the problem is fixed. Severity is how badly it’s broken.

Low Severity and High Priority:

We’re missing legal copy on the man purse checkout page. We could be sued by pursesfordudes.com for millions because of an obscure legal loophole.

High Severity and Low Priority.

The FAQ page that two people a week visit is totally broken.

Generally, severity is something measurable. It’s something most people should be able to agree to by observing it.

Priority is much more subjective, and the product or business owner is who usually sets this one.

Don’t Send Email

Don’t give into the temptation to send your own mail with the status of the issue or to get information about it. Any ticketing system worth it’s salt sends email, and plenty of it.

3 Reasons Tickets Are Better Than Email

1. They keep a better history of the issue. Who did what and when.
2. Tickets provide an Single Location for information on an issue and what’s been done about it. No chance for multiple mail threads.
3. They leave no doubt as to who has the ball. Whoever is assigned the ticket is on the hook to do something about it or send it to someone who should (just keep an eye out for ticket ping-pong).

Insist On a Ticket

When someone has a problem but hasn’t opened a ticket, gently remind them to do so. This is hard to do without coming off like a jerk.

“Whaddya mean open a ticket? The Website is DOWN! We don’t have time for this!”

My favorite tactic for this is to say or email: I’m taking a look now. In the meantime please open a ticket and assign it to me.

These two sentences appease the reporter that immediate action is being taken, and at the same time reinforce the fact that a ticket should be opened. Works like a charm.

Act On Every Ticket

If you’re going to insist on a ticket, you need to keep up your end of the bargain. When an ultra-high priority ticket comes through, you need to jump.

For lower-priority issues, ensure they get attention or are given a proper burial. Bug scrub meetings are excruciating, but in my opinion essential tools for tending the garden of issues.

Once your users/business-owners realize their tickets get attention, they’ll use them more, and your life will get easier.

Suggestions?

That’s my list. I’m all ears if you have other commandments that have worked for you.

[Tickets Image courtesy of basykes]