A tale of martyrdom
Since early October, it’s become much easier to determine where people fall on the political spectrum.
If they refer to the health insurance exchange website as the “Obamacare” site, they’re a conservative. If they refer to it as “HealthCare.gov,” they’re a liberal.
If they call it “not surprising,” they likely work in software development.
When the stories started to surface, I was in Boston, MA, attending UIE’s User Interface 18 conference. A few of us joked about the irony of being at a UI conference when the president was on TV talking about an “unusable” website.
Being a software project manager, I could picture how things went down and started to feel for the managers and devs who were in the middle of it.
At Boston’s famous Quincy Market, my buddy and I sat down at a communal table with some kind-looking older folks. After learning we were in town for a “website convention,” our new friends shook their heads.
“It’s a shame,” the gentleman said, “we have a nephew who works with websites. He says it’s really hard to get anything done. It’s no wonder this HealthCare.gov site is a mess, too.”
Knowing I could trust them, I shared my thoughts.
“Somewhere in DC is a project manager who saw it all coming, and hopefully, she went to her boss. Chances are she was told to go back to her desk and keep working. She’s likely losing her job right now. But at least she raised her voice.”
Unfortunately, she probably said things that nobody wanted to hear.
Failed software projects don’t just happen.
Failed software projects are a sprawling network of tributaries, with switchbacks and rocks and an occasional small waterfall. These lead into streams, then rivers, and eventually to an ocean of mismatched data types, trimmed zeros, and botched customer records, washing up on a beach littered with Mountain Dew cans.
Then everybody stands around a boardroom table and wonders what went wrong.
“It’s a management problem.”
As a software PM, I resented this statement. How could it be my fault if my devs don’t do their work? How is this a management problem when I’m such a good manager?
It wasn’t until I’d lived through a failed project or two that I realized the “management problem” everyone’s talking about isn’t our inability to make estimates, keep abreast of development, or keep an eye on the budget.
It’s often a fear of re-planning.
Re-planning is everywhere. How many times do you go to the store and only buy the items on your list (if you made a list at all)? How often does a dinner party go as planned? And, with kids in tow, how many times do you leave for vacation, school, or grandma’s house at the exact second you’d hoped to?
We humans naturally re-plan and revise every minute of our lives (this sentence brought to you by over 20 seconds of back-spacing).
But when it comes to software projects — especially large-scale and well-documented ones — there’s sometimes a fear of re-planning.
Because to many people, this feels like admitting a mistake.
I’m not claiming to have any insight into the planning of HealthCare.gov or to have a clue about what should have been re-planned. Yet, all the risk assessment matrices in the world won’t do you any good if everyone involved isn’t aware of them — or isn’t cool with changing things up if needed.
If re-planning isn’t discussed up front so that everyone understands, you’ll have some people — most dangerously, managers and higher-ups — who are afraid of it. Bottom line: Be cool with re-planning. It’s gonna happen.
“But we totally had a process.”
“So, are you guys straight-up agile, or agile with some waterfall, or strict waterfall, or what?”
Years of conducting developer interviews has me anticipating this question and trying to come up with an answer. Regardless of what your answer is, everyone has some kind of process.
For a while now, many companies have been “going agile,” mostly out of a desperate attempt to get people talking. Scrum and other agile methodologies seem like a perfect silver bullet for all the development teams out there that can’t seem to get anything done.
The world is filled with countless managers — including myself — who have thanked the Gods of Backlog for bestowing us with the amazing boon of the Daily Scrum.
It all seems so simple, right? Just look at the amazing benefits!
Requirements written in language that stakeholders can understand!
Daily meetings where we can actually discuss progress and impediments!
Time-boxed development cycles!
Not convinced? Wait, there’s more!
Retrospectives— postmortems!—where we can talk about everything that went wrong and then fix it!
Just call the number on the bottom of your screen to have this life-changing software development process delivered right to your door for the low low price of solid requirements plus tax, paid in easy, two-week installments.
Ok, enough silliness. Agile can be great — lots of very successful companies use it to pump out some really cool stuff — but agile for the sake of agile, or process for the sake of process, isn’t gonna cut it.
I’ve talked to folks who have worked on teams that keep moving ahead with sprints despite a need to stop, assess what’s going on, and re-plan.
“We kept getting behind and rolling stuff over to the next sprint,” they said. “But we had to have another sprint planning meeting the next day, so there wasn’t any time to figure out why this was happening.”
Teams sometimes keep using a process because they’re afraid not to have a process — they keep having daily stand-ups even though everyone says the same thing every day—and rush through those once-promising retrospectives because everyone’s too nice to say what went wrong and it’s time to start planning the next sprint.
I have no idea whether the teams working on the HealthCare.gov site were or weren’t agile, but I’m guessing their work had at least some of these elements. And when you keep using the process because it’s the process and you need to use the process, it’s easy to lose sight of what you’re actually doing.
“Software isn’t complicated. People, on the other hand…”
I was once talking to a woman whose development staff served in a staff augmentation role for clients. For one client, they’d gone through four PMs in one year and were about to introduce a fifth. The client was obviously skeptical.
“We hired these dudes coming right off of their PMPs,” she’d said.
But as soon as they talked to developers, they only heard the teacher from Charlie Brown.
Now, I love developers. Some of my best friends are developers. But, the more I talk to folks in my industry, the more I learn that this is unique.
I imagine that most PM-developer conversations go something like this:
PM: Hey man, how’s it going?
Dev: (Removes earbud) It’s going.
PM: So it’s all good?
Dev: Yeah bro, it’s all good.
Then the PM walks away and tells his managers that yep, everything’s on schedule, everything’s “all good.”
Chances are, though, that even if my mythical dev’s work is “all good,” what about the other guy? What about the dude writing the API? Or the new chick in the design department? How’s her stuff coming?
If PMs don’t actually talk to devs and ask real questions about what they’re working on, or don’t have someone else who can do this for them, “all good” can quickly turn into “total bullshit.”
And even if it’s not BS, “all good” might actually mean that:
A) the dev is totally going to pull an all-nighter to get this shit done
B) his work is “all good” but who knows about the other guy
C) both A and B
D) neither A nor B.
I’m not saying that all PMs should be devs in a former life. Hell, I’m an copy editor-cum-manager, and some of the best project managers I know couldn’t SELECT * themselves out of a paper bag. But they know what SELECT * does; they have a general idea of why you shouldn’t always use it; and they can talk the talk enough to be taken seriously.
It also helps to have a nose for BS and a good sense of humor. And when you’re talking to developers about estimates, it’s always a good idea to ask them how long they think it’ll take the team to do it, not how long it’ll takethe dev to do it.
(Believe me. I have a formula: dev estimate x 6 = real estimate. It’s pretty accurate, and takes into account communication, testing, deployment, confirmation, and things I forgot [TIF]. Give it a try and let me know what you think.)
“It just takes a lot of ‘giving a shit.’”
— J. Endler, musician, developer
Some people, at times myself included, are surprised that any software products work at all.
Truth is, a lot of them don’t, but most of them work well enough for us to keep our jobs.
It doesn’t have to be this way. Engineers — just like we say we are — have built bridges, nuclear reactors, and that giant-ass building in Dubai.
We put people on the freaking moon. So what’s the difference? Physicality? Maybe, as we can’t actually “touch” the API that runs our Google maps.
I think it’s more about risk. Say the bridge you’re building can’t hold trucks. What happens? People die.
If that hotel in Dubai has an elevator that’s designed incorrectly, people die. If your lunar lander can’t make it back to earth, people die.
Houston? Here’s the problem.
We all know that complex computer programs are running systems critical to public safety, and their failures can, and sadly do, result in death (think: Toyota break recalls).
But for the vast majority of people writing software, nobody’s gonna die. Nobody’s gonna die if your datatype is wrong. A few records might get botched, but nothing huge. Nobody’s gonna die if your site takes over 10 milliseconds to load.
And as another designer friend once said, “Nobody dies if I choose the wrong blue.”
Since no one’s gonna die, and more often than not, no one’s gonna get fired, what’s our incentive? Good companies know that good software sells products and builds customer loyalty.
But lots and lots of companies are putting out software because they need to get something on the web — and if it pisses you off, well, sorry, bro.
This is where it helps to “give a shit.”
In our high-paying, low-stakes world, all we have to do is give a shit. We have to give a shit from top to bottom, from CIO all the way to the guy who pushes the button to run the automated tests. Because even if what we’re doing isn’t going to kill anyone, we should care about it. We should want to do good work. We should all want lighter sites and clean code and better user experiences.
It’s our duty to hold our peers accountable for this, for our managers to hold each other accountable, and for the people above them to do it, too. But what do we even have to say?
“Hey dude, I hope you care?”
Which brings me to our martyrs.
For the first time in my professional life, and maybe for the first time since “the modern web,” we have an epic fail to talk about. A Hindenburg. An Apollo 1. And as much as it grieves me to say, a Challenger disaster.
On HealthCare.gov, something went wrong. Somebody messed up.
Or, a lot of somebodies messed up. Maybe a lot of somebodies were messing up, and nobody thought it was a big deal or had any clue as to what a big deal it was going to be.
These somebodies have given us a gift. They have given us the words we need to talk to our bosses, and our boss’s bosses: a cautionary tale.
And even if our companies aren’t anything like the federal government and our projects are only a tenth of the scale of HealthCare.gov, messing up and failing to re-plan, use a good process, talk to people, and give a shit will cost our companies money, and someday, maybe our jobs.
We don’t want that. We can’t let it happen.
To the PM I believe is out there: thank you for your sacrifice and for giving us what we needed.
I promise not to go forth in vain.