I was teaching a class a few weeks ago on Agile Methods. One of the crucial aspects of an introductory course, at least from my perspective, is an introduction to agile requirements. I usually start the discussion by trying to explain the large differences between traditional requirements and their agile equivalents.

Now the end results each tries to steer towards are the same. But how they approach providing functional direction can be very, very different. Here is a table that tries to illustrate the primary differences:

One of the students really had a problem with this. We were doing a simulation around an iPad application. We developed a Minimal Marketable Product definition for an R1 release of the product. I then asked the student teams to write user stories in a story writing workshop. These stories were intended to align with the MMP they had defined. The next step in the class was to do a bit of release planning.

One of the teams pulled me aside and said that they were having a lot of difficulty with the exercise. In essence, they were struggling with the ambiguity and the lack of finely grained requirements. They were incredibly uncomfortable with aligning high-level stories with their MMP. Essentially—they wanted to be told what to do. Thinking and ideating on their own was simply too hard. It was also fraught with risk and responsibility.

In the class, I ‘forced’ them to try and deal with the ambiguity and complete the exercise. But it struck me that all they wanted was to be micro-managed.

Micro-Management

You all know what micro-management is from a leadership perspective. You’ve all probably worked for a micro-manager. They get involved in everything you do—looking over your shoulder, assessing your progress, and giving you advice at every turn. Usually the advice is staid and conservative. Aligning with how things have “always been done this way”. They don’t like anything that is risky or performed outside of their comfort zone. And usually, consistency in execution is very important to them.

Why don’t people typically like working for a micro-manager?

I think some actually do. Those employees with little experience, or drive, or desire to take ownership of their work. They embrace simply being told what to do, then do it, and then go home; satisfied that they met their boss’s expectations.

But in my experience, many more find this dissatisfying. It’s constrains them; limits their innovation, creativity, learning, risk-taking, experimentation, and yes, fun. Quite often it doesn’t drive the best results either.

But I need to get back to requirements. So what does micro-management have to do with requirements?

I think quite a bit. I think of traditional requirements as having many of the same attributes of micro-managers. They simply tell you what to do—in excruciating detail. There is no wiggle room, little area for thinking or discussion, and certainly there is no room for discussing option with the customers or creatively solving their problems.

Often, Business Analysts are the bosses with respect to traditional requirements. Sure, they try to be collaborative. But in the end, it’s their job to figure the direction out and describe it to the team. Then it’s the teams’ job to implement the product…as described and directed.

Agile or Not…Let’s Stop the Insanity

Whether you’re operating in traditional or agile environments or something in between, I’m now predicting the demise of this pattern of Requirement Micro-Management. And I hope it’s a ruthless, quick, perhaps painless, but permanent death. No matter how we approach it, it does need to stop.

Why?

Because it doesn’t work! You might ask what’s wrong with the traditional approaches to requirements. In answer, I might offer the following (non-exhaustive) list:

1. They presume that a few can figure everything out
2. They don’t easily adapt to change or discovery
3. They don’t communicative well; writing being the primary medium
4. They constrain innovation and creativity to only a few
5. They imply that solutions are fixed
6. They imply that teams simply follow the recipe; fostering little true collaboration
7. They often miss the mark; disappointing customers
8. They can be confusing; but impede asking questions
9. They work more poorly as complexity rises
10. They should be continuous rather than a leading activity

So, whether you’re agile or not, please consider adopting the mindset of agile requirements and putting behind the notion of micro-managing requirements.

The world will be a better place for it and we’ll certainly create better products.

Stay agile my friends,

Bob.