Are you exploring a business analysis career in an agile software development environment? Are you concerned about keeping your business analysis skills relevant in an increasingly agile world? Would you be interested in learning how you can evolve your business analysis skill set even if your organization has not yet embraced more agile practices?
It’s my honor to bring you this interview with Ellen Gottesdiener and Mary Gorman. They recently published a new book – Discover to Deliver – which makes a significant contribution to the business analysis profession. I was privileged to be an early reviewer and I highly recommend their book to anyone looking for a solid grounding in how to apply BA practices in an agile environment.
In this interview, we cover why Ellen and Mary embraced agile analysis, the business analyst role in an agile environment, and list specific practices you can use to evolve your business analysis skill set and stay relevant in an increasingly agile world. (And if you are interested in the book, there’s a discount for Bridging the Gap readers at the end, so be sure to check that out.)
About Ellen and Mary
Ellen Gottesdiener, Founder and Principal with EBG Consulting, is an internationally recognized facilitator, coach, trainer, and speaker. She is an expert in Agile product and project management practices, product envisioning and roadmapping, business analysis and requirements, retrospectives, and collaboration. In addition to co-authoring Discover to Deliver: Agile Product Planning and Analysis with Mary Gorman, Ellen is author of two acclaimed books: Requirements by Collaboration and The Software Requirements Memory Jogger.
Mary Gorman, Vice President of Quality & Delivery with EBG Consulting, is an expert business analyst, facilitator, coach, and trainer. She has deep expertise in business systems and product development. Mary writes on requirements topics for the Agile and business analysis community and is a Certified Business Analysis Professional™. Mary was instrumental in developing the IIBA® Business Analysis Body of Knowledge® and the IIBA® certification exam. Mary is co-author with Ellen Gottesdiener of the recently released book, Discover to Deliver: Agile Product Planning and Analysis.
Making the Transition to Agile Analysis
Laura: Over the last 10 years or so, you’ve transitioned from a focus on business analysis to Agile analysis. What was the key driver in this transition for you both as consultants, coaches, and trainers?
Ellen and Mary: We’ve been on this journey for about 12 years now, and we’re seeing more and more organizations adapting lean/agile practices. Just as important, we’ve seen how lean/agile practices amplify the benefits of business analysis.
Here’s why. Increasingly, our clients—like most organizations—need faster product delivery, super-efficient practices, and, above all, a relentless drive toward value. At the same time, they face a host of practical problems. First, products are complex and therefore expensive to build and maintain. Second, customers are getting more savvy and demanding. Next, requirements risks continue to be the most insidious challenge in any development effort. And then there is the fourth practical problem—people. Products are discovered and delivered by teams of human beings whose best work emerges from healthy collaboration. But that doesn’t happen spontaneously. People need to learn how to systematically plan and analyze the product at a high level while at the same time drilling down to the details.
A core element of these problems is the need to specify product requirements, the basis for development and delivery. While technologies get better and better, requirements remain a conundrum—they are necessary to know, but wickedly difficult to obtain and agree on. Requirements will always be, to paraphrase Fred Brooks, the most difficult part of any development effort.
The world recognizes the value of lean/agile development for many products: you have to plan for uncertainty, work on small batches of requirements, deliver them as soon as possible, test your assumptions about which requirements will deliver the most value, and all the while instill a sense of partnership among stakeholders. We’ve found the best products come from teams that act as a living learning lab—constantly delivering, learning, and improving. This continual improvement cycle is the hallmark of a successful lean/agile team.
Agile analysis synthesizes a toolkit of practices drawn from business analysis as well as requirements, project, and product management; strategic thinking; and collaboration. We’ve been fortunate to work with a variety of clients either interested in or compelled to adapt how they go about business analysis and requirements practices.
When calibrated for the situation at hand (after all, context counts) agile analysis practices help product partners build the right product right, discovering and delivering high-value, high-quality products.
Also, before we go on, let’s take a minute and define what we mean by lean/agile. As defined in Discover to Deliver, lean/agile (or sometimes just agile) is “an umbrella term describing the family of practices for building software and systems using iterative and incremental development and delivery, with a focus on maximizing customer value while minimizing waste.”
The Business Analyst Role in Agile
Laura: You have been vocal for a number of years, in both the traditional and the agile communities, about distinguishing the agile BA role from agile business analysis work. Why?
Ellen and Mary: Yes. We prefer to focus less on roles and turn the focus to goals. To that end, we published a widely referenced article, “It’s the Goal, Not the Role: The Value of Business Analysis in Scrum,” to jump-start this conversation.
Here’s why. As we observed agile teams, we saw many of them ignoring or avoiding requirements analysis, and they ended up delivering buggy software, fragile architectures, or products that had little value to users or buyers. In addition, we continued to hear a hue and cry from analysts who were confounded or worried about whether and how they fit into agile projects.
Before we talk about how business analysis skills fit, let’s clarify the work that needs to get done.
The entire product community—from the customer, business, and technology realms—shares responsibility for discovering the highest-value product to deliver at any given time. To continually make smart decisions, these people need to act as partners to explore product options, evaluate them to identify those that have high value, and define confirmation criteria to verify and validate the delivered product. This is the work of knowledge discovery—in other words, analysis. Furthermore, it’s not a one-shot deal. It’s ongoing. And it requires discipline.
This knowledge discovery work requires people who have interconnected skills such as strategic thinking, evaluating, and envisioning; elicitation, analysis modeling, and efficient specification; user experience and design thinking; user acceptance testing; and facilitation. Talented business analysts have all or most of these skills.
Laura: Given that distinction, and to use the language of “role” applied to agile teams, what business analysis skills and knowledge are applicable to which agile roles?
Ellen and Mary: Here are a few examples.
- A person (possibly a business analyst) who has skills in testing; defining lean, testable requirements; and turning examples into acceptance tests may serve as a tester.
- A person (possibly a business analyst) who has good analysis modeling skills, knowledge of user experience design and architecture, design skills, and a bent toward empathy for users may serve as a user experience designer.
- A person (possibly a business analyst) who has excellent facilitation, communication, coaching, and leadership skills may serve as a project manager, release manager, scrum master, coach, or software manager.
- A person (possibly a business analyst) who has rich domain expertise, especially in large organizations, may serve as a tactical product owner—assuming that the product champion gives the analyst decision-making authority.
- A person (possibly a business analyst) who is a domain expert, has strategic planning and thinking skills, and has a background in product management may serve as a product champion (also called a product owner or business owner).
How to Expand Your Agile Analysis Skill Set
Laura: I know many of our readers realize that Agile and Lean are significant industry trends, but are not yet employed in Agile software development environments. What concrete steps can they take to make their business analysis experience more relevant to an Agile environment so that they can remain competitive in the job marketplace?
Ellen and Mary: Indeed, we see agile less as hype and more as mainstream, commonsense practice. Agile has crossed the chasm of software practices. In other words, just as object oriented development went from hype to trend to common practice in software development, so too is agile becoming the standard product planning and analysis.
Business analysts need to take note: most organizations—especially the ones business analysts want to work for—are integrating, hybridizing, and synthesizing agile practices into the way they do business.
Here are specific recommendations for business analysts:
1. Learn the foundational principles and practices of lean, agile, and organizational change.
2. Become fluent in a variety of ways to elicit and specify product needs driven by value. This includes product visioning, goal and objective specification, risk assessment, and exploration and evaluation of options to fulfill product needs (product options) at any planning horizon.
3. Build mastery in analysis modeling. Learn how to use a variety of analysis models; how to select models based on the problem domain; how to calibrate models’ breadth, depth, and formality; and how to interweave them to yield clear and precise requirements quickly.
4. Learn how to think with, and specify with, a testing mind-set to verify and validate requirements concurrently. Find out how to devise acceptance tests from concrete examples and use them to both elicit and test requirements. Understand how to validate requirements by using measurable outcomes expected with each delivery. Learn how to help your technology, business, and customer partners by insisting on clear validation criteria.
5. Become a skilled facilitator, with the ability to design and lead collaborative work sessions for a variety of stakeholders, whether scopes are wide or narrow and time horizons are near term or long term.
We think these five steps not only will make you relevant and also will demonstrate the kind of business analysis leadership that makes you indispensable.
About Discover to Deliver
Laura: I couldn’t agree more. Tell us a bit about Discover to Deliver and how it will help new and aspiring business analysts apply Agile analysis techniques on their software development projects.
Ellen and Mary: By working with numerous agile teams—and non-Agile teams as well— we’ve learned, over many years, that great products are the result of stakeholders having a product focus, staying value-driven, and continually collaborating and conversing as partners. More and more, we’ve found ourselves homing in to help agile teams set context, be explicit about value, and learn from each other by having succinct, rich conversations about the product they’re working on.
We wanted to codify this know-how in Discover to Deliver in a way that would be useful and practical and would stand the test of time. After all, requirements are the basis for planning, architecture, development, testing, and, ultimately, product value. So we wanted to describe ways to do that well, honoring Lean/Agile principles.
Among other things, Discover to Deliver explains how to:
- Engage stakeholders as product partners.
- Identify value considerations in order to focus on high-value product needs.
- Clarify planning by recognizing multiple time horizons (we call them the Big-View, Pre-View, and Now-View).
- Plan and analyze product needs with increasing specificity according to planning horizon.
- Hold structured conversations to explore product options across the 7 Product Dimensions. The 7 Product Dimensions encapsulate what is classically referred to as functional and nonfunctional requirements. The structured conversation is a metaphor for the ongoing collaborative practice of exploring, evaluating, and confirming product needs
- Use the 7 Product Dimensions as an efficient way to holistically explore product options.
We took special care to make the book usable and practical for a variety of readers and learning styles. The book uses a straightforward visual language as well as text. In addition to a comprehensive glossary, the book offers a rich narrative case study that allows readers to “listen” as a team plans and analyzes requirements. And detailed case study examples are woven throughout the book. Readers can also refer to a suite of tools and techniques (with examples) that are mapped to the book’s key concepts and practices. A graphical navigation mechanism lets you see at a glance where you are in the book.
Laura: I know many of our readers already own and frequently reference Ellen’s Software Requirements Memory Jogger. How would you bridge their experience with that book to what they will gain from Discover to Deliver?
Ellen: I continue to be gratified when I learn of the value the Jogger book has provided to many people in our community—as well as many others in the software development community. Since I wrote the Jogger, Mary and I have adapted and extended traditional requirements practices as a result of our direct agile experience.
Discover to Deliver helps readers apply the foundational knowledge and skills described in the Jogger. The Jogger’s model essentials supplement Discover to Deliver, and vice versa. (We have crossed referenced the techniques in the two books, as well as mapped Discover to Deliver to the PMI-ACP® Handbook, PMBoK®Guide, IIBA BABOK® Guide and Agile Extension to the BABoK®; you’ll find these mappings on our book’s website, on the Resources page). While it’s certainly helpful for Discover to Deliver readers to read the Jogger, it’s not necessary.
The same is true for my first book, Requirements by Collaboration. The essence of collaborative practices is as true today as when I first wrote the book. Many agile leaders and coaches are returning to Requirements by Collaboration to sharpen their skills in facilitating successful team collaboration.
>>Read More About Agile Analysis
Here are some additional Bridging the Gap articles about being an analyst in an agile environment:
