We currently are in a great debate, one that will potentially define our industry for the upcoming decade – or at least a few days. Like Abe said, “The world may little note nor long remember what we say here, and it probably won’t matter diddly, anyway.” – or something like that.
What Debate? I thought you’d never ask! The problem starts with the general misconception as to what Business Analysis is. In a nutshell, should you do “Agile Analysis” or “Lean Business Analysis”.
You may have noted the recent buzz about eliminating waste in the requirements discovery process. Followers of this blog know that I have been riding that horse for several months now primarily because of my ongoing assessment of the field and feedback I get from readers and customers.
Agile Is a Software Development Approach
The term “Agile” has been usurped by the IT community as a philosophy for eliminating waste in the software development process. As a result, many feel we should adopt the name “Agile Analysis” to emphasize our adherence to the principles of the Agile Software Development effort.
The Agile philosophy gives disciples a set of principles and practices published in the Agile Manifesto. If you read that venerable document, it’s pretty obvious that it specifically targets software development.
The first hint is in the opening paragraph of the Manifesto that starts with “We are uncovering better ways of developing software…”. In the ensuing 12 principles, “requirements” are mentioned exactly twice:
- Welcome changing requirements, even late in development.
- The best architectures, requirements, and designs emerge from self-organizing teams.
What’s with the Word Requirements?
Now, the Business Analysis profession is tasked primarily with defining requirements; that’s our thing. Hence, we own that word. The conflict is caused by the ambiguity of the term itself. (Gee, where have we run across that problem before?)
Business Analysts deal with Business Requirements, Stakeholder Requirements, Solution Requirements, and Transition Requirements. Whereas Business. Stakeholder, and Transition Requirements address business needs, Solution Requirements speak primarily to the IT community.
Solution Requirements Are Agile
The Agile team is undoubtedly best equipped to identify and refine Solution Requirements that the software product must meet. At that level of detail, I would actually encourage the use of the term Agile Analysis because it fits there. Solution Requirements need to be negotiable and evolve as product development progresses.
Obviously, Business Analysts can and should be involved as needed in supporting members of the Agile team in interpreting software requirements. However, that is actually one of the simplest components of the complex process we call Business Analysis. We have a thundering herd of tools and techniques to apply at that level. The real challenge is getting to that level.
Business, Stakeholder, and Transition Requirements Impact Much More than Software
All other levels of requirements set the stage for successful products, projects, or initiatives that may or may not involve software development.
The real challenge of Business Analysis lies in ensuring that all requirements align with the business strategy, goals, and objectives as defined by senior management. That’s why we put so much effort in communicating requirements that can be understood by both sides of the great divide, the business community and the technology or digital solutions groups (formerly known as IT).
Lean Business Analysis Says It All
The requirements discovery process that gives decision makers the basis for making intelligent decisions far exceeds the Agile Manifesto. Because Business Analysis at all levels is a process that does not depend on software, I maintain that Lean Principles are much better suited for improving your Business Analysis activities.
The Lean philosophy has deep roots in the manufacturing world. It is primarily concerned with maximizing the business value by eliminating waste in every process. At its core, Business Analysis is a business process. Lean Business Analysis, like Lean Manufacturing, promises to deliver a superior outcome more efficiently. From that perspective, calling it “Lean Business Analysis” is a no-brainer for me. Then again, since my loving wife once accidentally called me the “Brainless Professor” (she is German and was just learning English), maybe that statement should not be coming from me.
Getting and Writing IT Requirements in a Lean and Agile World
Learn Business Analysis Techniques for Discovering Requirements, User Stories, Features, and Gherkin (Given-When-Then) Tests
