How Agile is Influencing the Traditional Business Analyst Role: Part 1

How is Agile influencing the traditional role of the Business Analyst? What will the future hold for people with business analysis skills? A Modern Analyst writer for an upcoming article posed these and other questions to me.

Because the final article will be an amalgamation of responses and not contain my full set of responses, I’m sharing them here with you, in two parts.

Let me know what your reactions are!

Question posed to me: Since the term “Agile” is used in so many contexts, what does “Agile” mean to you?

I assume in this article you are focusing on agile practices for product development (and not “agile” as a marketing term—e.g., “we’re an agile business”). Recognizing that a product can be software, hardware, a complex hardware and software system, or business process change, I would turn to the Agile Manifesto and its underlying principles.

Agile is Humanistic and Pragmatic

It is striking how humanistic and pragmatic the manifesto and its principles are: “individuals and interactions” and “customer collaboration” are valued along with “working software”; the twelve principles include responding the “changing requirements” and frequent delivery along with simplicity, technical excellence, self-organization, and reflection.

When you study the history of software engineering and software methods, you discover that many of the practices that fall under the “agile” umbrella are not new. We stand on the shoulders of those who have written, researched, and experimented with good practices.

We should not forget our history.

Studying those practices and history is informative. The agile “movement” will fade, and the most useful agile practices will become mainstream. I think Alistair Cockburn was spot-on at the Agile 2009 conference, when he said his keynote was about “burying agile, not praising it”; that is, people aren’t arguing very much about agile. Most of the theoretical issues are settled. Now we’re focused on how to implement agile practices.

Remember when structured development methods, and then information engineering, and then object orientation were the hot topics and next silver bullet? Take object orientation: object technology is a common lingua franca for developers. It’s been assimilated.

The same thing will happen with agile. Iterative development, timeboxing, or kanban-like flow models for development (continuous integration, test-driven development, user-acceptance-driven development, or BDD, behavior-driven development)—all this will become common practice.

Classic Agile

Even “classic” agile is changing. Some people are adapting lean practices, others are figuring out how to address agile/adaptive architecture, and the software craftsmanship movement is pushing for attention.

So, to sum up with the keywords that inform my work—the ones that pop into my head when I think about agile—I would name these:

• customer collaborative
• business value
• adaptive
• self-reflection
• incremental
• iterative.

Question posed to me: What role do you think a traditional Business Analyst should play in an Agile team?

I am more concerned with the work that needs to be done to deliver value, rather than focusing on roles per se.

Regardless of the product, whether you buy or build, or what century you are in, you still need to elicit and understand the product’s requirements.

Agile teams definitely need the skills and disciplines of business analysis. It varies from team to team whether those skills are embodied in a delivery team member, the customer (or product owner—PO—in Scrum terminology), or a combination of people.

To define what value is, what to deliver, and when, the customer and team need skills in requirements development and management. The team needs knowledge of enterprise and project-level analysis, elicitation, validation, planning, and management.

An agile team and customer/PO need to conduct

• business modeling
• product roadmapping
• requirements-driven release planning
• prioritization
• backlog population and grooming/pruning
• user experience design
• user acceptance testing
• ROI and cost-benefit analysis
• product requirements dependency analysis
• quality attribute specification
• estimating
• facilitated techniques
• and more!

Along the way, the agile team needs to be transparent about when and if to incur analysis debt.

Take a look at the 49 techniques (and their associated tasks) in the current BABOK® and you will see that many of them are needed on agile projects.

A “designated” business analyst

Some agile teams may not contain a designated “business analyst” whose work is limited to user stories, or even requirements (which to me includes defining acceptance criteria).

In those teams, analysis skills are shared among team members. That is more common in small teams working on small projects, when team members have rich business domain expertise—along with close, trusting relationships with their business customers—or when there is an “uber” Product Owner who has loads of skills to do the business analysis, and requirements skills for connecting multiple teams together to deliver the product.

Most agile teams are grateful to have people with deep business analysis talent, particularly those with fine-tuned facilitation skills, agile modeling skills, the drive to reduce waste (including unneeded documentation), and the ability to get requirements ready for upcoming iterations.

Agile presents special requirements challenges.

Current lore about representing requirements as user stories does not directly address nonfunctional requirements (e.g., quality attributes and design and implementation constraints). Sharp business analysts can provide crucial help in eliciting and analyzing those important requirements.

Furthermore, agile projects need folks with the ability to, as F Scott Fitzgerald said, “hold two opposed ideas in mind at the same time and still retain the ability to function.” While the delivery team is doing heads-down, short-term development (focusing on what I refer to as  the “now-view”), other team members need to help them drive the project community toward what I call the “big-view” and “pre-view.”

Resources

• Agile Business Analysis in Flow – The Work of the Agile Analyst (Part 1)
• Agile Business Analysis in Flow –The Work of the Agile Analyst (Part 2)
• The Agile Business Analyst: Eyes for Waste
• More articles on agile analysis and agile requirements