Introduction

Today was my last day with my current former employer, as you may have heard from my (also now-former) coworker.  We quit on principle after having several irreconcilable differences of opinions with our management over how to manage and execute a software project.

As you might imagine, after a rather trying and emotional last few weeks and especially day, I did a lot of reflection and introspection — trying to see where I was wrong (I admit, I wasn’t right on every point, but I’m pretty sure I wasn’t wrong on every point either).  As if by providence, when reading books to my 2 year old for bedtime, I actually grabbed a book (I swear) by total chance that turned out to be a retelling of Aesop’s fable Tortoise and the Hare.  Surprisingly, this story almost completely captures the entire point of the arguments I’ve been trying to make the past couple weeks. It’s a short one, please allow me to indulge you in its entirety:

Once upon a time a hare saw a tortoise walking slowly along and began to laugh and mock him. The tortoise challenged the hare to a race and the hare, thinking himself the fastest animal around, accepted. They agreed on a route and started off the race. The hare shot ahead and ran briskly for some time. Then seeing that he was far ahead of the tortoise, he thought he’d sit under a tree for some time and relax before continuing the race.

He sat under the tree and soon fell asleep. The tortoise, plodding on, overtook him and finished the race. The hare woke up and realized that he had lost the race.

Moral: Slow and steady wins the race.

Especially, almost perfectly, this applies to software development and project management. Any project, of any sufficient size, must achieve some sort of steady pace, a rhythym, a momentum to achieve success.  The more starts and stops, context switches, jostles, or sporadic/inconsistently-timed changes you introduce, the more likely you are to affect that pace negatively to the point where you setting yourself up for failure.

The Hare Mentality killed our project

There is a point in every project — well, every project I’ve ever been a part of in one shape or another — where panic starts. I’m not quite sure what starts it every time, but the ones that I do know of have all been about money and ‘burn rate’ and I’m willing to bet that all of them (even the ones that were not made known to me) are about that. The point of Agile, in my opinion, is to allow visibility and more frequent opportunity for decision points for the stakeholder for just these types of moments.  The appropriate response, when this moment of panic is about to ensue is for everyone, especially the stakeholder, to put on their big boy pants and start making the hard decisions about what to cut.

The inappropriate response — oh there are many, but they boil down to this — is to start mistrusting the developers and start assuming they’re lazy SOBs who have been cleverly avoiding work throughout the whole project.  Looking back, nearly every single time the panic season started, this was the demeanor the stakeholders took.  Instantly the project went sour, all pace was destroyed, morale tanked, some people went into psycho 100hr/wk work mode to prove the stakeholders wrong, others proved them right by giving up and not doing anything. Ultimately, the project died a rather undignified and flaming death. Failure resulted (or perhaps success didn’t happen to the degree to which it needed to happen), the team burned out and most left while the stakeholder was stuck with a failure product and all their critical brain trust gone or demoralized.

Leadership is about, among other things, trust

If you wish to avoid the later crash-and-burn scenario I described above, you should strive, instead, to achieve the former scenario — the one where everyone rolls up their sleeves and makes tough, but smart, decisions instead of accusing each other of tanking the project before it’s actually was tanked, thus self-fulfilling the prophecy.

You interviewed these developers, the project manager, the project lead, the testers, etc. You saw their resume, you may have even checked their references. They’re here because YOU brought them here. YOU pay their paychecks. Therefore, YOU must enable their success and let them do what they have been hired to do. If you don’t trust them to do that, then, it must be asked, why did you hire them in the first place? Or more presently, why are you keeping them on?

When you reach the crumbling precipice edge of Panic Chasm, resist the urge to accuse other people for the impending doom — thus forcibly casting the entire project, its team, and quite likely yourself into that chasm.  Stop, step back, take a deep breath. I guarantee you the 5 minutes it should take you to do this properly will be the most important 5 minutes of the project. Do the rational thing and pick up the phone or march into the team room/lead’s office/cube, etc and tell them that you’re gazing into Panic Chasm and it’s time for Plan B.  At this moment, you MUST trust the lead to do the right thing. No other choice will lead to any hope of success. Only trusting the project lead and the team will ever ensure any hope of yielding any success that matters.  That doesn’t mean it can’t still fail, but it will at least fail truly — on merit — because it simply was not accomplishable by the team you had assembled.  At this point you will have a solid failure and you will have clear knowledge of why it failed with no gray area for abstract finger pointing. A clear failure, in my opinion, is better than a fuzzy failure (for which some may declare success, take credit, and leave you holding the bad of that ‘success’).

Plan B

So the time for Plan B has arrived. This is it, there’s no turning back. Everyone on the team — stakeholder and producer alike — must trust each other to make the hard decisions and cut what they must to make the plan happen. You must resist the urge to bear down, roll up your sleeves and do everything wrong as fast as you can and ruin everything you’ve strived for. It’s during the hard, trying times that discipline pays its debt. Soldiers don’t go to boot camp to learn how to salute during peace time, they go there to learn how to be disciplined when the bullets are whizzing past your ears. The only thing that will save you know is doing what you know how to do, according to the process and procedure you’ve established and trying to eliminate as much waste and extra work as you can.  Stakeholders must make tough decisions about which of the ‘Absolute must-have’ features has to go. Producers must make the tough decisions about where they might skimp on some design discussions and sign up for some technical debt. Everyone must make decisions about where they might be able to live with a little less testing here and a little less design there. It will be hard, and it will make you cringe, but as long as you do it with discipline and full knowledge and cooperation among the team members, you can get through it and arrive with success that you can sustain going forward. You may have to cycle back and remove some technical debt, fix some bugs, add back in some tests that you had to skip, but you stuck to the process, kept the faith/discipline, and you arrived with your dignity in tact and the knowledge that you didn’t sacrifice the whole project for the sake of one deadline.

Aftermath

Because, as you know, after that deadline, there will be another deadline. And another. And more tough decisions and known, documented shortcuts that will have to be paid for later, etc.  As long as you have a process to keep everyone focused, a team that’s committed to not panicking, and a level of trust to carry you through the roughest times, you will be able to make it through them all.  If you do panic, and you allow yourself to descend into going off the process and ditching the discipline, you will most likely never be able to get back onto it and you will almost certainly fail the next, last deadline as there probably won’t be any more after that and all will have been for naught.

Final thought

If you remember nothing else from this post, remember this: DON’T PANIC