Over the past few years, I’ve studied what it means to market and sell professional services like mine. Honestly, I’m in a weird place with that, because I’m a huge geek (and still speak FORTRAN fluently) but a lot of what I do is what is sometimes, probably condescendingly, called the “soft skills” realm.
That makes it hard to answer that inevitable question, “So, what do you do?”
I used to reply with variations that started, “I’m a software developer” or “I’m a Unix guy.” But that doesn’t quite tickle the people who really need me.
After a long process, I hit upon a really vivid description. Here’s how that conversation goes now:
Q. (vaguely) “So, what do you do?”
A. “I work with people who have software projects that suck!”
Q. (startled) “Oh! So what do you DO for them?”
A. “I make them not suck.”
Q. (amused) “Hah! No, really, how do you do that?”
A. “Do you have like two hours?”
Q. (pre-emptively bored) “No. You got a card? I’ll file and forget it promptly!”
A. “Here you go. Thanks!”
See how it turns at the “how do you do that” phase? Well, I’m sorry, it’s just really hard to explain. As Tolstoy might have said, every good software project is the same; every bad one is bad in a different way. So there’s not a simple formula that I can rattle off in elevator-speech format.
But I’ll do my best, in this longer forum, to give you a sample.
The first meeting
First, your project sucks and you know it. Or you’ve been told by your boss. You email me. We get together, maybe on the phone if it’s too long a trip, but probably better in person.
If you really want the truth, I’m mainly there to hang out and find out about you. Not the project.
If the project is important to you, like your job or your company depend on it, then having the project suck takes a severe emotional toll. I want to know what you’re feeling and how you’re coping, because just like any other life crisis your options are sharply limited by your own mental state. Are you losing sleep? Are you using alcohol (or other things) too much? Is it distracting? How is your driving? Are you dropping outside activities that have been good for you?
One of the earmarks of Projects That Suck is that they take a long time. How bad can it really suck if it’s over in a couple of months, right? But that means you’re putting off your workouts, your time with family, your home maintenance, your ability to cook and eat well, and a dozen other things that not only make your life good but actually reinforce your presence at work. The same goes for everyone else on your team.
It’s possible for an unhealthy team to produce incredibly awesome software. But it’s far more likely, and a lot easier, to work from a position of personal strength. So we talk about that.
Yes, of course we move along to an analysis of the project’s ostensible (and real) goals, the resources available, that status of work already done, and what you feel still needs to be done. Which leads to…
Drawing a Picture
Figuratively and sometimes literally, we draw a picture of what you want, what you have, and ideally a kind of path that gets you from the former to the latter. If you’re a visual learner, this sometimes leads to a fantastic “Aha!” moment that makes the solution glaringly clear.
Maybe you do better with a more literal approach: you’re one of those verbal people. That’s cool, the picture becomes more of an outline or a mindmap.
Either way, we have a path that has steps. And decision points! Lots of decision points probably.
Application of Perspective
Once I was asked how I could stay so calm in the midst of the upset customers, blown deadlines, and agitated mangement that surrounded the then-current Project That Sucked. It was easy to answer that, because my newborn son had recently been released from the neonatal intensive care unit. The kid had been born with pneumonia and (temporarily) just one functioning lung.
I was freaked out by that. Little dude was in one of those oxygen tents and jacked up with a dozen sensors for several days until the infection cleared.
The lesson is kind of obvious.
When stuff doesn’t work and people are panicking, the first and last thing I care about is: “Is there anyone here who can’t breathe right now?” In between that first and last thing, we have problems, but nobody’s ever claimed they can’t physically breathe.
Look. If your store opens a week later than planned, it sucks to be you, and if I’m being paid to make sure it opens on time it sucks to be me too. But when you think about it, sucking is only the first half of breathing!
Concretely, that means we’re going to tone down the panic atmosphere, whatever it takes. Whatever got us to where we are, the next steps will be like firewalking: deliberate, calm, and quick.
Traditional sit-at-the-table meetings? When you’re already behind the curve and losing ground? No. We’re going to use a straight or modified Scrum process, including the Daily Scrum meeting, also known as “the standup” because ideally there are no chairs in the room.
Everyone whose job is actually working on the project (not “stakeholders” or merely interested parties) takes a turn answering three questions:
- What did I get done since the last meeting?
- What will I get done before the next meeting?
- What obstacles do I know about?
No more status meetings on the half-hour. No more blamefests. No more drawn-out problem-solving sessions that include everyone. Everything at the standup is about communication and moving the project forward. It’s amazing how often this results in better decisions, made faster, with less angst and more energy.
The basic problem when dealing with a Project That Sucks is that it’s already sluggish or out of control, so classical techniques may not work. You need to change tactics at least, but more likely you have to change the entire process and how you look at it. That’s what I do, and this blog post represents a subset of how I do it.