Phase: Envision

Table of contents:

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."

The Agile Revolution

Guiding Principles: Customers and Products

Guiding Principles: Leadership-Collaboration Management

An Agile Project Management Model

The Envision Phase

The Speculate Phase

The Explore Phase

The Adapt and Close Phases

Building Large Adaptive Teams

Reliable Innovation

Agile Project Management. Creating Innovative Products
Agile Project Management: Creating Innovative Products (2nd Edition)
ISBN: 0321658396
EAN: 2147483647
Year: 2003
Pages: 96
Authors: Jim Highsmith © 2008-2020.
If you may any questions please contact us: