If you've been in the game long enough, you get informed by upper management of a grand promise due in just a little over a month. Something like rewriting an entire suite of applications in a new technology in 6 weeks. That's what I'm facing at the moment. The promise has been made, so after you pick your jaw up off the floor, what can you do?
If you are in an environment where continuous deployment is already in place, then the only thing you really need to worry about is getting the product owner in front of the app and using it often.
Do What You Can
The number one thing that causes your gut to tie itself in knots is all the stuff you know you don't know. The unknown things linger in your mind like a cancer undermining anything possible. Norman Vincent Peale is credited with the quote "Shoot for the moon. Even if you miss, you'll land among the stars." Aside from the bad astrophysics, that sentiment is what you need to start with. Be aware of the deadline, but don't let it consume you. It's too easy to spend a lot of energy fretting over it that is better spent on just getting stuff done.
Get the Griping Out of the Way
It's natural to gripe and push back when you receive what you feel is an unreasonable demand. It's part of the process to see how hard dates are, what is most important to get done. If the dates aren't changing, the best thing you can do is to roll up your sleeves and get to work.
- Plan enough to know what you need to do, but no more
- Deploy often to course correct before you go too far down the wrong trail
- Get the product owner involved so they can see your progress and answer your questions
Lean on Institutional Knowledge
This isn't the time to do something new and shiny. If your company has experience with a particular architecture, then you can lean on others to help you get set up as soon as possible. They can also help you get unstuck quickly. Just as importantly, if you need to surge your team with more folks, you aren't spending time getting the new folks up to speed with how things are put together. You'll still have to train them on the domain knowledge, but the fewer new things to learn the better.
Test Early and Test Often
The sooner you fail the sooner you can get over it. When you apply a little scientific method to your software process, it's amazing how well things can fall into place. That's how Test Driven Development (TDD) works:
- Prove your code doesn't do what you need it to do
- Make the changes to fix it
- Clean up after yourself
Sometimes You can Succeed
Once you get the negative energy out of your team, you can focus. When you can focus, you can fix things quickly and move on. When your customer is in the loop and engaged, they can help you reprioritize on the fly and they will have something they can use by the proposed date. You'll probably have a lot more work to do, but the customer is happy and they can use the new app.
For the manager who made the promise: reward your team when they make good on your promises. They definitely deserve it. And maybe don't do that too often or you'll burn your team out.
I used to have a boss who thought, because he was so computer-ignorant, that I could simply press a button and fulfill promises he'd made to his overlords. Sometimes I would have to tell him, "You lied, didn't you?"
ReplyDeleteNot that I would drag my feet or fail to try to meet the deadline, but I felt that if someone was going to be wringing their hands, he could take care of that aspect while I devoted my energy to fulfilling his "request."
His "attaboys" were sometimes slower-coming than he'd have liked, but through the process he came to learn that spreadsheets didn't design themselves, dBase apps didn't write themselves, and databases didn't populate themselves.