Agile Business Analyst – An Oxymoron?

This post is inspired by an article by Ellen Gottensteiner. Is an “Agile Business Analyst” an oxymoron. Before we answer this question, we first need to understand what “Agile” and “Business Analyst” mean.

“What is Agile?”

Anyone involved in Agile will know that no two people have the same understanding of Agile. Some feel it is defined by the Agile Manifesto. Others feel the Agile Manifesto was simply a “Call to Arms”. Some feel Agile should be solely focused on software development. Others feel it’s principles and practices extend beyond software into business, the home and even apply to law. You can read the manifesto at www.agilemanifesto.com. My personal view is that the first line is the manifesto. “We continue to learn how to do software by DOING it, and helping others do it”. It goes on to give a status report… So far, we have come to value the items on the left more than those on the right. The principle that seems to indicate “The Agile Business Analyst is an Oxymoron” is the “Working Software over Extensive Documentation”. After all, writing extensive documentation is all that a business analyst does. Right?

“What is a business analyst?”

The IIBA defines a business analyst as someone who practices business analysis techniques. The business analyst may have the job title “Project Manager”, “Developer”, “Tea Boy” or even “Business Analyst”. So what are the skills of a business analyst? I’ve interviewed about two hundred business analysts over the past few years. At the start of each interview I tell the candidate my view on the role of a business analyst… “Someone who knows the business well enough to argue with them. Someone who understands technology well enough to know what the developers need, and finally someone will need to be skilled in the business analysis tools to take the ‘vague and fluffy’ statements of the business, and turn them into the precision needed by the developer.” This is not a simple role. You need to be an SME, have a strong knowledge of technology, and have business analysis skills. Some business domains are less demanding and it is possible to learn the domain “on the job”. Other domains demand you know your business knowledge before you start.
When I think of business analysis tools, I mean business modelling (Entity Relationship Modelling, Object Modelling), Use Cases, Storyboards (Screen and Report Mock Ups), and State Transition Diagrams… And the rest.

The value of a Business Analyst.

Originally I was going to write “A good business analyst…”. But that is wrong. Its confusing the job title with the skill set. Its like saying a “good John Smith” or a “bad John Smith”. A business analyst is someone who uses business analysis tools. So, second attempt. A good business analyst adds value in a number of ways.
• Ensure that the project is developing those items of most value to the business.
• Asks the business detailed questions so that they have time to find an answer. These questions will naturally occur during the development. However, waiting for the answer can block development or result in incorrect assumptions. This will allow development “Flow”.
• Help the development team articulate a business case for paying down technical debt.

“What is an Agile Business Analyst – Whence The Business Coach?”

Agile changed the rules. In 2003, Andy Pols (a developer and many other things) and I (a business analyst and a couple of other things) re-evaluated the business analyst role in light of Agile. We started from the assumption that we did not need a business analyst. From there we identified the value they added that we needed to put back into the project. After many cups of coffee, and a few pints of beer, we came up with the “Business Coach” role.
We identified the following significant differences in Agile compared to traditional approaches.
• People no longer operate in silos with clearly defined responsibilities. The project took collective responsibility rather than individuals. The business analyst needed to extract knowledge from the whole project rather than be the “Truth” or an SME.
• Traditional analysis tools like UML produce models which are of little value to the Agile developers. Agile developers wanted to work with tests/examples rather than models.
• Agile developers want to work more closely with the business. It became obvious that the business analyst could no longer act as a gate keeper to the business. The developers needed to speak directly to the business, and to do that they needed detailed business knowledge. The business needed a better understanding on how to work with the development team.
• Knowledge needs to be in the heads of project members rather than in documents. (If you think it’s painful to read thirty nine versions of a forty page functional specification, how painful do you think it is for the person writing it? Ditching extensive documentation to focus on more valuable activities is one of the most liberating experiences in my career as a business analyst.)
In order to address these issues, the Agile Business Analyst needs skills to facilitate collaboration (Collaborative Requirements by Ellen Gottensteiner). They need to know how to generate examples rather than models (Feature Injection by Chris Matts <- Me ). They need knowledge transfer skills so that they can help the business and developers learn the skills they require. (Accelerated Learning by David Meier, Situated Learning by Lave & Wenger, David A. Kolb’s Circle of Learning, Visual-Audio-Kinestetics, Neuro Linguistic Programming).
Given the shift to a more facilitative role focused on team learning, we decided to name the role “Business Coach”.

The Agile Business Analyst is an Oxymoron!

If your view of the Agile Business Analyst is an “order taker”. Someone who simply writes down what the business sponsor/user wants. If you see the business analyst as someone who creates extensive documentation, then an “Agile Business Analyst” is an oxymoron. After all, Agile values “working software over extensive documentation”.

The Agile Business Analyst is NOT an Oxymoron!

I believe the Agile Manifesto is out of date. Many people agree with me. I believe in the principle “Delivering business value OVER Working Software OVER Extensive Documentation”. The Agile Business Analysts can add value so it is not an oxymoron.
The Agile Business Analyst role is evolving. It is responding to the challenges of Agile. Pioneers in Agile Business Analysis like Kent McDonald, Greg Goodman, Ellen Gottensteiner, Joe Little and Ryan Shriver have been developing practices for many years. Agile Business Analysts are adding value on many projects. David Morris is currently leading an initiative to write an Agile extension to the IIBA Business Analysis Body of Knowledge. If you have experience as an Agile Business Analyst, please add your story to the Body of Knowledge.

In the end, it’s all about our definitions. As we cannot agree on a definition of Agile, it’s hard to determine whether the business analyst has a place in it or not. That said, many projects find business analysts to be very valuable. Perhaps practice shows us the theory is flawed?

Sadly there are those involved in the Agile movement whose view of the business analyst has not moved on. They are selling a view that is many years old. They talk about “Bad Business Analysts” not realising that a “Bad Business Analyst” IS an Oxymoron.