What must be delivered to add value. Robin Goldsmith, in his book about REAL Business Requirements (yes, he’s yelling) nails the definition of requirements. Who could argue? Within that phrase, we intuitively know that the three critical words in the phrase are. “Value” – if no value, then stop right there. “Must,” is seminal because it is this adverb that centers the discussion on requirements—if it must be done, it’s a requirement—and “what.” “What” is that thing you might buy, put in place, make, code, or fix to improve your business or solve a business problem.
And yet Mr. Goldsmith is literally a voice crying in the wilderness. He openly admits being at odds with IIBA[i] and the BABOK[ii] in his perspective on requirements. His isolation emerges when he uses the second word, the famous qualifier, and talks about BusinessRequirements. After 20 years in IT, I feel his pain, share his frustrations, and wish that the qualifiers of the term “requirement” would just go away. No functional, non-functional, technical, business, high-level, detailed, qualifiers. Just “requirements: what must be done to deliver value.”
As IT practitioners, we lack the courage to abandon these adjectives, because, when we peel back the grape, we know that some times, maybe even often, the path best traveled will have nothing to do with software development, modification, or improvement. Root cause analysis, in the IT universe, decomposes only computer programs (or lack thereof) to find some “root cause” there; after all, to stray into the realm of possibility that something else might be the problem would be overstepping our collective boundaries, right? But the reality is that business is where it starts and business is where it ends. I mean the generic term “business,” what it is that a company or organization does. IT, collectively, is a set of tools to get business done. It has no inherent utility beyond business goals, the obvious exception being companies that produce software.
IIBA and many other scholars of requirements state that business requirements are “high level” and, by implication or overtly, dismiss their utility in getting software projects done. I would counter that business requirements are all that matter and those business requirements need to be as detailed as they need to be to reveal the problems the business faces and provide a path to a solution. This is the premise on which Goldsmith’s Problem Pyramid is based. His well-written tome describes how you go about decomposing business requirements and then prescribes the conversion process to functional requirements for software development. I’m not going to do a mere book report here, but rather need to credit his insight in talking about how business requirements, their quality and their test-ability, are focal to success in any business venture, especially software development. My orientation here is to talk about his fundamental premise as the cornerstone of success in deploying Agile approaches to developing software.
The Agile world, especially SCRUM, is littered with overwrought and often comical metaphors. The obsession with doing things a certain way seem, at times, to belie the liberation they claim to make from their more structured counterparts. I find myself looking for the man behind the curtain who’s pressing levers to make smoke and sparks fly all around. That being said, I think Agile principles are solid and its various methods are valid. Agile can and will be the single most important transition a company will make to improve the outcome of its software projects. But for me, it really only boils down to one underlying principle that proper Agile organizations embrace—it’s about the business.
The single most critical lynchpin to success in an Agile environment is the active, daily, participation, investment, leadership, and communication between the business owner of the problem, product, challenge, and the development team charged to address said problem / challenge. Like most “movements” in organizational transformation, Agile will die a scary death in an organization that doesn’t buy in from the top down. Co-location is simply a physical manifestation, or requirement, of the over-arching truth that, without the constant and active investment by those who own the business objectives, the software project will underperform at best, and fail or cost more than is justified from an ROI analysis at worst. The “product owner” to use the SCRUM term, defines the business requirements. It doesn’t matter if they are called user stories, but it does matter that they have a useful level of detail. The “discovery” process that continues to build out the content of sprints must be limited to how their efforts will contribute to business goals that are clearly known from the start. If you don’t recognize the cause of the pain or inefficiency, if you don’t identify specific gaps that hinder your optimal path, up front, then why are you starting a software project in the first place? I hope it isn’t because the IT function suggested it.
It doesn’t even matter if there is some software program in the middle of your pain. The software’s presence doesn’t presuppose that it’s the cause of the business problem or even instrumental in its resolution. Software might be the problem, if it’s critical as a tool to get your business done and it’s not well designed. It’s also possible that something else is wrong with the business and changing or enhancing tools will do nothing to fix it. Developing detailed business requirements will expose the root cause.
Agile development can and should proceed with speed and focus; get to done, validate with the owner of the business objectives, adjust, and get to done again, until it’s done. But don’t even start down the road until you develop Business Requirements. Detailed business requirements.
So what do detailed business requirements look like?
Consider that a company wants to reward its “active” customers in good standing with some type of program that provides “special” attention or pricing. This can be an IT solution, maybe it is likely an IT solution. Let’s focus on what will help the business and “get specific” about it.
Business Requirements Decomposed: Create a Preferred Customer Program
1. Provide a means for a verified existing customer in good standing to receive special pricing and product selection considerations.
1.1 Identify and define “super” customers.
1.1.1 Provide an input mechanism to identify the customer.
1.1.2 Approve a valid application input
126.96.36.199 Guide the applicant to provide a complete and actionable application.
188.8.131.52 Provide an accurate means to screen out “pretenders” who are not customers in best standing
1.2 Verify that the existing customer‘s status is in good standing
1.2.1 Process customer-validating information
184.108.40.206 Define verified existing customers as those actively doing commerce with company in last 3 years
220.127.116.11 Verify that the customer is in good standing with no holds
18.104.22.168 Set up a way for the customer to provide verification and easily join the “preferred” program.
1.2.2 Reject customers not eligible while encouraging additional sales
22.214.171.124 Distinguish between bogus claims to being a preferred customer and those not yet meeting thresholds
126.96.36.199 Provide a pathway and incentives to eligibility
188.8.131.52.1 Set up a trial membership to encourage more activity
1.3 Ensure that an account exists and that the customer initiates the special relationship by verifying their “regular” account status.
1.3.1 Set a rule that makes preferred customers eligible after they verify their regular account status.
1.3.2 provide a secure and brief way for a preferred customer to make contact with the firm to leverage the special account for which the customer is qualified and accepted.
184.108.40.206 Set up a limit to the number of attempts a user can make to participate in the program when he is not enrolled or qualified.
When the business is done decomposing business requirements–taking an honest and detailed look at their gaps and their challenges–then and only then do they turn to IT to see if they hold the keys to a solution. Then and only then can the Agile team make a meaningful journey to “done” and “discover” the requirements that will leverage technology to make things work better.
“Thinking of everything” still pays off, even as we admit that solution requirements in software engineering are discovered along the way. Adopt an approach that makes you intimate with the business problem, so that we know the “done” we’re trying to get to is really worth starting on the journey.
Apple’s success in the marketplace comes from understanding their market and putting the needs of their consumers front and center. I don’t know if they build everything with agile teams, whether they adopt Kanban principles, whether they use the 5 Ses and do value stream mapping based on Lean principles. I just know that they spend a lot of effort to understand what people want and need. It’s not a “high level” endeavor for Apple. It’s fundamental.
Paul Antelman, PMP, LSS, ITIL, is a consultant for Sogeti, a Capgemini company. He has worked in the IT field as a business analyst and project manager for over 20 years.
Goldsmith, Robin: Discovering REAL Business Requirements for Software Project Success, c 2004 Artech House, Norwood MA.
Manifesto for Agile Software Development, www.Agilemanifesto.org
SCRUM Alliance, www.scrumalliance.org
[i] International Institute for Business Analysis
[ii] Business Analysis Book of Knowledge