Not Enough Time

When you have NotEnoughTime, you are stuck. There is no way to make more time, and attempts like working longer hours don't take long to backfire, leaving you with less effective time than before.

I have found it helpful to think instead that I have TooMuchToDo.

--KentBeck

At one point on ChryslerComprehensiveCompensation, we got behind. KentBeck was on site that week, and we spent a bunch of time talking about the fact that we didn't have enough time to do what we had to do.

Kent and I were at a loss, we didn't see a solution. Then ChetHendrickson "snatched the stone from Kent's hand". He said, "It's not that we don't have enough time, we have too much to do."

Kent came in the next day and drove the point home. (Used Chet's watch to tell Chrysler what time it was.) We identified the FourVariables of projects: Scope, Quality, Resources, and Time. Your quality requirements are (or should be) fixed. Your resources probably won't change, and time cannot change. The only thing you can really deal with is Scope: when you're behind schedule, you have to do less.

At our next IterationPlanning meeting, the customer, literally with tears in her eyes, began pulling UserStory cards off the table. She realized that the only way she could contribute to on-time delivery of the product was to reduce the scope -- so she did what she had to do.

Sure, pull a little overtime once in a while, it's good for you to make your commitments. But when you're really behind, agreeing with your customer to reduce scope is the only hope you have.

--RonJeffries

This triggered a thought in me (a rare occurrence, thought). Does anyone have some insight as to ways to get your management to start allowing customers to do this, while keeping them from trying to modify time estimates (as described in ExtremeProcess)? Every place I've worked, the management seemed determined to keep customers in the dark about overload, and make its own decisions both about what would be delivered, and how much time it would take.

You may find a solution to this dilemma by reframing the question. Who is really in a position of higher power, management or the customer? Can managers really disallow this kind of customer behavior, or can they just attempt to disallow direct communication between project teams and customers? Maybe the answer is: do not allow your team to follow a management that is not really leading.

Typically, developers do not talk to customers during the requirements phase (around here, anyway), and so far as I know customers to not get called into the meetings where it is decided what will get cut from a release. Some of this is because the products are often intended to be more generic that any one customer will be interested in helping with (We don't want to develop a solution that will need extensive rework to fit another customer's workflow, frex). As for not following non-leading management, that tends to be difficult to do and stay at the same job -- especially when there are still plenty of people who will do CowboyCoding elsewhere in the corporation who will play the old way.

See: CountTheHands

CategoryTimeManagement