Holly Bielawa explains that being a a requirements craftsman means that 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.
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.