It’s Time for Requirements Craftsmanship

After spending years as an Internet entrepreneur, a sales and marketing executive, and an enterprise agile and lean coach, I have come to realize that the biggest challenges facing agile transformation today are no longer creating high-performing teams or for those teams to create working software. It is making sure that we are creating working software that is valuable to the business. To quote the first of the twelve principles in the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Even when we deliver early and continuously, how do we know that we are delivering valuable software?

I ask myself these questions: Why doesn’t using agile methods always mean success? Why are enterprises with high-powered agile development teams still falling behind the competition? As the community of “guiding agileists,” aren’t we responsible for continuing to help our clients sustainably and iteratively produce software that no one will buy, no one will use, and will ultimately cause our clients’ enterprises to be left in the dust by the competition? Should we really be satisfied with “better ways to create software” as an end goal, or is it time that we should aim for something more meaningful, like delivering a competitive edge, enabling enterprise success, or perhaps creating higher stock prices for our clients?

Those of us who have spent any time working on agile transformations intuitively know that success depends on more than the software development organization, yet I have heard many seasoned colleagues dismiss success criteria as a “business problem.” This attitude leaves product owners and product management teams to struggle with how to prioritize what will mean valuable and usable software for the business. These business people and business liaisons are also the usual folks left to live with the product created by the “high-performing team.” The developers are free to claim success and move on to another effort. It is no wonder that acceptance of agile is still spotty and businesses are often reluctant to engage, and when business people do engage, they don’t understand how to create a backlog based on vision and solid data. This is especially severe in large and more complex enterprise environments.

As an agile community, we need to start feeling a responsibility to help create success from the results of delivering valuable software early and frequently, or else risk failing to truly help our clients and community. How do we assure that the software we produce is valuable? Requirements craftsmanship.

From the beginning, the Agile Manifesto has valued minimizing waste (documents that need to be refactored), face-to-face communication (to decrease misunderstandings), and customer satisfaction over contracts. Lean manufacturing has also added more language around minimizing waste. But agile and lean are not only suggesting minimizing waste in all of its many forms, but also encouraging understanding the economics. For example, what is the cost of delay for implementing one requirement over another?

Some folks in the industry are using some of the tools for requirements craftsmanship. Those who have spent any time with scaled agile framework by Dean Leffingwell (and others) or read Don Reinertsen’s book The Principles of Product Development Flow can see elements of planning and prioritization based on value. Reinertsen suggests “taking the economic view,” and Leffingwell prioritizes based on “weighted shortest job first.” But, sadly, coaches in these scenarios usually end up coaching the planning processes and assume that software craftsmanship and requirements craftsmanship already exist in the organization.

So, who are requirements craftsmen? In the lean start-up community, Eric Reis and colleagues such as Steve Blank, Patrick Vlaskovits, Brant Cooper, Alex Osterwalder, and Yves Pigner seem to have requirements craftsmanship well in hand. According to that community, you need to test your assumptions in real time while developing a product. Then you pivot as needed, change your business model as you learn, and constantly get out of the building and gather data to determine your minimally marketable product.

A perfect example of this is a scene in the movie The Social Network in which Mark Zuckerberg is racking his brain, knowing the product didn’t yet have what it would take to be a success. A classmate named Dustin runs over:

DUSTIN: “There’s a girl in your art history class. Her name is Stephanie Attis. Do you happen to know if she has a boyfriend?”

MARK: “Why am I being interrupted?”

DUSTIN: “Have you ever seen her with anyone? And if not, do you happen to know if she’s looking to go out with anyone?”

MARK: “Dustin. People don’t walk around with a sign on them that says—“

Mark stops right there as he realizes what his product needs to be successful: a relationship status. And the rest is history. Mark left his dorm room, went out into the world, listened to his users, and immediately changed the product based on what he learned. It was somewhat successful.

The lean start-up model contends that if your business isn’t doing what Mr. Zuckerberg did, you might as well just burn your money because you won’t build the right product. This approach works, and some smart enterprises are already adopting as many aspects of the lean start-up as possible. This is one of the ways you can make sure you are creating the valuable requirement to execute to because this is the path to requirements craftsmanship.

In the meantime, what is the agile community offering? We say the product owner owns the backlog, and sometimes that’s the full extent of our participation in requirements craftsmanship. Sometimes we might say something really smart, like, “You need to break epics into features and then break those down into stories, and further define these terms by saying that a story fits into an iteration and a feature should fit into a release cycle.” Where is the value? Where is the guidance to assure that value is being created based on solid empirical data?

We must start owning both software craftsmanship and requirements craftsmanship or we will never fulfill the promise of delivering valuable software early and continuously. We will never truly be agile.