I went to see Johanna Rothman speak last week at the Software Quality Group of New England. I like Johanna because, as an expert in management, she can spot a line of management B.S. from a mile away.

I don’t have this skill. As a coder, my special power is spotting crappy code. If another developer shows me crappy code, I can describe 7 ways to Sunday why it’s a bad idea and 10 ways to fix it. But management B.S., that’s harder. Kind of like those game shows that turn seemingly intelligent folks into complete idiots… that’s pretty much the effect management B.S. has on me. I will actually sit there, stupefied, trying to reason some sense out of what they tell me. “Well, of course there’s no time for us to do things the right way. BUT, if you can just deliver this 6 month project in a 3 month period, that leaves you a whole 3 extra months to clean things up!” Uhhhhh.

So, I liked Johanna’s presentation, Schedule Games: Recognizing and Avoiding the Games We Play, because it makes me think there might be hope for us managerially-challenged developers yet.

Here’s the first game she described – stop me if this sounds familiar:

Manager: How long will this project take?
You: 3 months
Manager: Can you do it faster?
You: Well, maybe… if we got another developer we might be able to finish it in 2 1/2 months
Manager: Can you do it faster?
You: Um, well, maybe, if everything goes perfectly, it’s possible it would come in a few days earlier
Manager: Can you do it faster?
You: No.
Manager: Well, what can you give me in 1 month?

This, my friend, is the Bring Me a Rock schedule game and it has been the cause of many a management cursing.

Her suggestion: turn the conversation around. At that very first “can you do it faster?” explain to the manager what they get for that 3 months. And then, if they continue to ask, explain what they’d get for 1 month. Features cost time. The more time you’re given, the more features you provide.

Somehow, while we all understand that side of the equation, we get kind of stupid on the flip side and decide that while more time == more features, less time == we just have to find a way to go faster.

Bzzzzzzt! Wrong answer.

Less time == less features, no matter how optimistic we happen to be feeling at the moment. So, instead of “well, maybe we can go faster”, explain what complete, quality, production ready functionality can be delivered if the time is chopped in 1/2 or 1/3rd. I know, this can feel like an impossible task if you’re thinking in terms of complex functionality that requires months worth of work to complete. So instead, think in terms of small features or user stories – what complete user stories could you deliver in that time? Specified, designed, developed, tested, production-level quality stories. What stories can you complete in 1 month? 2 months? 3 months? Ask the manager for a prioritized list so you can work them in priority order and get through as many as you can within the time period given.

Whereas in the first scenario, you’ve hidden the downside to less time (“we’ll just work faster”) and so, of course, there is nothing but upside to the manager in asking for less and less time. In the new scenario, you’ve made the tradeoffs visible to the manager and you’ve given him control to not only select the balance that makes the most sense from a business perspective, but also to prioritize the order that will provide the most value. Smart developer, smart manager.

Of course, as we see, it takes a bit of work to get to the smart side of things. Here’s a few more games Johanna described – let me know if you’ve heard them before:

Hope is our Most Important Strategy

We’ve never done anything like this and we totally don’t have the experience/resources/training/knowledge for it, but that’s okay because we really think we can do it!

Queen of Denial

You may think it’s impossible, but I have faith in you, I know you’ll find a way!

Even though it has absolutely no relation whatsoever to our product schedule, we just HAVE to release something on this particular date because <insert silly reason here – e.g., “It’s the boss’s birthday!”>

Schedule == Commitment

Even though you had absolutely no input into this schedule, this is THE SCHEDULE and therefore, you will be held accountable for it.

—

If you’re like me, you hear these and panic. Oh my God, how will I ever make it work?! And, like the “we’ll just go faster” answer, all this does is to force the team to shoulder an unreasonable burden while completely hiding the problem from the manager. No downside to manager, so manager keeps pushing. Stupid manager, pissed developer.

So what do we do instead? We start by recognizing these for what they are. Recognize that they’re not reasonable. Recognize that it’s the managers job to make the project successful, not doomed to failure. And, recognize that in all likelihood, the manager really does want to make the project successful – so helping them once again become smart manager by presenting options that can work.

Want to take on a project we know nothing about? Let’s not just blindly assume we know all the answers up front and just Hope everything will go right (read: Waterfall). Instead, let’s do some short, time boxed iterations that run through a “Hello, World” equivalent of the project to try to gather more information about what the work will entail and what issues and questions we’ll need to address moving forward. Let’s be flexible and follow a process that can accommodate the continual changes we’re going to run into as we learn more about this new area.

Got a flaky senior executive that likes asking for releases on random dates? Work in short iterations that always result in production-ready product so that you can be ready to deliver at almost any time.

I don’t know why manager’s play games. Of course, developers play games too. Maybe its just our knee jerk reaction to the ridiculous levels of complexity we have to deal with. It seems so much easier to Deny the facts, declare a Happy Date and Hope beyond hope that it will work because the Schedule says it will. But then, of course, there’s reality…

What schedule games do you play on your projects? And how do you deal with them?