Agile Strategy, Not Just Agile Methods

I had a client who obsessed on one approach to agile: “We’ll push everyone in our organization through the [fill in the blank] certification program.” This push would happen regardless of agile learning, experience, or temperament. Everyone would be certified, whether they liked it or not.

This approach perpetuates a problem that has long troubled traditional project management: it privileges method-in-theory over behavior-in-practice. Like many such problems, one root cause is the attitude of executives. Embracing Agile, an article in the most recent Harvard Business Review, pinpoints the executives’ stumbling block. They can talk a bit of agile, but don’t walk it:

"But because they haven’t gone through training, they don’t really understand the approach. Consequently, they unwittingly continue to manage in ways that run counter to agile principles and practices, undermining the effectiveness of agile teams in units that report to them.

"These executives launch countless initiatives with urgent deadlines rather than assign the highest priority to two or three. They spread themselves and their best people across too many projects. They schedule frequent meetings with members of agile teams, forcing them to skip working sessions or send substitutes. Many of them become overly involved in the work of individual teams. They talk more than listen. They promote marginal ideas that a team has previously considered and back-burnered. They routinely overturn team decisions and add review layers and controls to ensure that mistakes aren’t repeated. With the best of intentions, they erode the benefits that agile innovation can deliver."

I appreciate that the executives want to drive strategy execution through agile. And I love the pitch for agile executive training, because we have a great offering. Unfortunately, that first sentence about training misses the root cause of many problems: agile behavior is what transforms, not knowledge. In fact, an improper reading of the article could perpetuate the problem. Its prescription starts with an agile method overview, and concludes with a section on “destroying the barriers.” Even then, what was the example used for barrier destruction? Yes, it’s a methodology.

Methods and tools are good and valuable. They lay the foundation of awareness and understanding that promote right action. Rote memorization of artifacts, roles, and frameworks don’t inform the decisions you’ll need to make when leading agile.

Let’s tie this back to my post on the PMI-ACP® certification. Memorization may even fail you when sitting for a certification exam. Here’s an example of advice an agile leader often needs to give to his team, and it’s a question similar to what you would see on the PMI-ACP® exam.

One of your team members insists that the Product Owner write the acceptance test cases for all stories in the current release (it consists of eight, one-week iterations). Since this isn't a long release, the team member suggests that the Product Owner write them all at once. That way the team can do better estimation and planning. If you were the team’s ScrumMaster, what would you do in such scenario?

How would you answer this one?  I’ll answer and explain in my next post.