Phase: Envision

Scope Evolution

"Hi, Dudess, how's it going?" Herman's voice boomed cheerfully in Maya's phone.

"Hermie, who you been hanging with lately?" Maya retorted.

"Just my team. I guess they're beginning to rub off on me a little. They're kind of cool when you get to know them."

Maya laughed. "Well, don't go changing too much, or I'll think the body snatchers got you. But seriously, how's it going with APM?"

"Good and bad. We're trying to use iterations and features, but I can't get around management's fixation on scope control," Herman replied. "They read the reports on project failures from scope creep, so we've got stringent change control procedures."

"Have they worked?" Maya asked. "My experience has been that strict change controls usually freeze requirements. The customers get so frustrated with the procedures that they just stop asking for needed changes."

"Well, we have managed to stabilize our project, but I'm not sure our customers are very happy. I think our concerns about destabilization have caused rigidity. There's a middle ground with how much change makes sense, but I admit I haven't found it yet."

"That's because it's always changing. An assumption that made sense at the beginning of the project clearly won't work by the time you're in the middle. We've found that you need to accommodate normal scope evolution rather than just try and control change."

"But I don't see any options; you either control scope or you don't," Herman said.

"Not quite," Maya responded. "Let's go back to one of the basic definitions of agility as 'the ability to balance stability and structure.' I look at it as trying to create a both/and situation rather than an either/or one. We think we can do both, and the secret is self-discipline. In the past, we've had both customers and developers who have made changes on a whim "

"Oh, we have that all the time. First the customer wants one thing; two weeks later he wants the opposite . The project teams feel whipsawed back and forth. Unfortunately, they react by ignoring the customers."

"Right. We used to have similar problems, which were exacerbated by developers wanting to add features willy-nilly. They got away with it for a while because we were so scared about being rigid; we went overboard the other way for a time. Now we analyze changes fast within the team and document them with informal notes. It's really about attitude changefrom change resistant to encouraging change. Change control is about coordination, not denial."

"Do you differentiate between minor and major changes?" asked Herman.

"Well, if the change impacts the overall boundaries of the project, we talk with the executive sponsor. Previously we found that minor changes based on a whim were destabilizing to our projects. Once we became self-disciplined about changes, even major changes tended to stabilize the project at the same time we were adapting to the change. It sounds weird, but that's how it worked for us."

"I don't know," said Herman. "You seem to be saying that self-discipline is the key. If I'm understanding you, undisciplined flexibility descends into chaos, while undisciplined stability creates rigidity."

"That's a good way to put it. To create real agility, we balance flexibility and structure through the application of rigorous self-discipline," Maya said. "Hey, I kind of like that! Gotta go. Next time."