"Hi, Maya," Herman said as she picked up the phone. "Ready for another round?"
"Sure, fire away," Maya replied.
"I'm struggling with tracking progress using agile practices. I don't see accountability. When things change during an iteration, you just replan. When developers don't meet their estimates, you change velocity. How can management have any confidence in project status?"
"Mainly because in every iteration we deliver features that are tangible evidence of progress. Whether management likes the results or not, they are confident in our status," said Maya.
"My management just wants to see budget and schedule reports ," said Herman.
"But how can they really know your status if they don't talk to you? I sit down with my boss and the product manager, and we discuss issues in depth. I try hard to understand the business drivers, and my boss gets an earful about the technical challenges from my technical folks. We jointly decide on how to adapt going forward, usually with schedule as the highest priority."
"Well, that's what they claim around here, too, but it's really a farce. We never make our dates."
"My management is tough, but they're willing to make tradeoff decisions. They push us, but they understand our situation, and they're not unreasonable. Well, not very."
"It sounds like there's a lot of give and take," Herman said.
"Right," said Maya. "You should hear some of the 'discussions.' It gets hot and heavyboth with management and within my team. But we're honestly trying to get at what's going on, how to make the best decisions. The dev team stays involved in these discussions, so they feel included and are willing to hold themselves accountable for the results."
"That all sounds good, maybe too good. But what happens when the execs cut the schedule? They do it all the time here."
"Last year that happened . My team looked at where we could cut, and we didn't think there were many features that could be pruned and still have a competitive product. Hiring was frozen at the time, so we recommended sticking with the plan or killing the project."
"They grumbled some, but after grilling me for an hour , they killed it."
"Wow!" said Herman. "And you're still employed?"
"Sure. It turned out to be the best thing we ever did. If we'd come to market with a poor product, the competition would have killed us," Maya replied. "Oh, which reminds me about managing between the activities."
"What? This your newest insight?"
"It hit me when I was skiing the North Face last weekend at Crested Butte. Looking at trees is one surefire way to hit them. You start worrying about hitting one, and, bang, you do. I keep my eyes focused on where I want to go, the space between them."
"And this relates to project management how?" Herman queried.
"Most project managers are so worried about the silly old maxim that projects get late one day at a time that they micromanage tasks on a daily, or even hourly, basis. Detail tasks are like the trees. The managers lose track of the goal, of the result the team is trying to deliver that iteration. By constantly harassing the team about whether they finished some four-hour task, they run into project trees."
"But what about control?" Herman asked.
"I manage feature completion at the end of the iteration, not daily tasks. Our control mechanism may seem less robust, but it works," said Maya. "The trick is to narrow uncertainty over the life of the project. It completely solves the 90% complete problem 90% of the time."
"We usually have the opposite . The further we get into the project, the more frustrated our management becomes that we haven't hit the original plan, even though in many cases they have caused problems by changing priorities and shuffling people," said Herman. "They always forget that the original plans were often done very quicklyat their requestbefore we fully understood the requirements."
"So," said Maya, "even though conceptually your traditional process should work fine, in reality it puts all the burden on the project team and almost none on management and the customer."
"Well, I guess you could put it that way," Herman mumbled. "I'm beginning to see how your approach makes it so each party has to step up to their responsibilities. Maybe that's why I'm having a hard time getting people around here to buy into it. Oh well, I'd better get going. My weekly fantasy reports are due."
Note: Although both the Adapt and Close phases are included in this chapter (because the information on Close is brief), it is critical to remember that the Adapt practices are an integral part of every iteration, while Close occurs only once, at the end of the project.
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