Principles and Practices

"Hi, Maya, it's Herman."

"Hi, dude, how's your project going?" asked Maya.

"Pretty well. Things are actually moving along. We've implemented a few of the agile practices. But you know, I'm just an action kind of guy. Just explain the practices to me. The principles stuff still seems like fluff."

"I thought they were fluff, too, at the beginning," Maya responded. "But once you've used APM for a while, you'll understand that it's the principles that make the practices flexible."

"OK, apply principles to iteration planning."

"Think about Deliver Customer Value. For us, this principle guides the selection of features. We're constantly asking ourselves whether one feature is more valuable than the next ."

"But won't most of the features ship anyway?"

"Possibly, but we keep two things in mind. Sometimes we release incremental versions, and the goal of always having a releasable product really keeps us on our toes."

"Isn't early release unlikely ?" Herman asked.

"Mostly, but last summer we had a customer with a critical problem. We were able to take a product that was three- quarters finished, do a couple of quick special features for the customer, and deliver it in three weeks. The customer was blown away, and this one spends megabucks."

"So, on to the Employ Iterative, Feature-Based Delivery principle. That seems redundant with the practice to me, but maybe that just reinforces its importance."

"That's the general idea. See, you already understand this stuff, Herman! You just don't trust it yet." Maya grinned to herself. She knew it was hard for Herman, who worked for a 75-year-old insurance firm, to break with the conservative, traditional approach that Great Mid-West had always taken to everything, but he was trying, and she gave him lots of credit.

"That's fine as far as it goes, but does this scale? You and I both know that any competent PM can complete a small, short- term project on force of will alone, but that all changes when you scale the whole thing up."

"Yeah, but that's where the Simplify principle comes in. It's how you scale everything up without tripping over yourself and your process. For example, on Jupiter, the new project I'm running, we have a big team. And to make matters worse , one feature team is distributed. Adopting a collaboration strategy was a given, but we also figured that we might need some additional documentation to keep everyone in sync."

Herman interrupted with a "See, I told you so."

"But the Simplify principle keeps it from turning into the pounds of paperwork you generate," Maya laughed. "We're bears about using the simplest documentation that accomplishes the goal. We work with just a few documents and keep them as informal as we can. Then we adapt them from time to time as we find what works and what doesn't."

"So, you use the principles to help adapt practices to specific situations," Herman said.

"Right. Without these guiding principles we could get hung up on the specific practices instead of understanding the intent of the practices. They keep us from going overboard."

"One I really get hung up on is Encourage Exploration," Herman replied. "This whole notion of responding to change over following a plan, of actually embracing change, is really foreign."

"That's a tough one," said Maya. "We can respond to change and deliver reliably. It's all in how you look at the relationship between uncertainty and time."

"My management doesn't care. They just want a commitment," said Herman.

"There is no way around the fact that the higher the uncertainty, the wider the potential schedule variation," said Maya. "It's too bad you aren't hereI need a whiteboard to draw this, but imagine that the probability curve of schedules is a skewed distribution curve, one with a long tail of possible very late delivery dates. High exploration-factor projects have a lot of possible dates based upon technology and requirements volatility."

"Everyone around here just assumes a project is a project is a project. There's no allowance for riskier projectswe just get the mantra 'on time, on budget, on scope' over and over. It's like a broken record."

"Don't remind me. Hopefully we're past that. In effect, the role of dates changes. In low-uncertainty projects, dates are predictions . For high-uncertainty projects, dates are boundaries, as in 'We will deliver as many features as possible by June.' Does that make sense?"

"I think I understand, but I'm not sure if the folks around here will get it," Herman said.

"It took us a while to work through it, too," Maya continued . "That's why the principle Encourage Exploration is critical to reducing people's anxiety. I have to keep encouraging people and reminding them that responding to change is part of our day-to-day work. We always have a few people from a conformance-to-plan type organization who get a little crazy at first. We project managers have to encourage them."

"Lots to think about," said Herman. "Bye for now."