How agile is Important to Business Analysts

Jonathan Babcock | PracticalAnalyst.com |June 21, 2011

I used to think a lot about what type of methodology was best for software development. I wrote
a fair amount about it on this site as I reasoned out my position. I havent said much on the topic
for quite a while, though, as I think Ive made my peace with the whole methodology wars
debate.
Through all my study of waterfall vs. agile and throughout my ongoing evaluation of stories vs.
declarative requirements vs. use cases vs. the next big thing, Ive found that the one constant is
that every methodology requires a competency (notice that Im not even referring to a BA by title
or role) for eliciting requirements, then modeling and presenting them in a way that makes it as
easy as can be for stakeholders to reach a shared understanding of what needs to be designed and
built in order to meet the stated business objectives.
As a business analyst, I may not (typically dont) have a great deal of control over the development
methodology my company uses. Even less so if Im a contract business analyst. With that in mind, I
think there are a couple general agile questions that any business analyst could benefit from
asking him/herself:
Am I an agile business analyst?
Perhaps the most important agile consideration for business analysts has little to do with
delivery methodology. Instead of worrying so much about how to be a business analyst in an Agile
(big A) environment, my focus should be on becoming agile as a business analyst.
And when I use the word agile (little a), Im emphasizing the dictionary definition, not industry
jargon. To paraphrase and personalize the Dictionary.com definition, agile is (italicized text
mine):
1. quick and well-coordinated in movement ; able to bring that coordination to bear in
fostering a solid communication and collaboration around eliciting, analyzing and modeling
requirements in varying project circumstances and delivery environments
2. marked by an ability to think quickly and adapt to a given organizational culture or delivery
methodology; mentally acute or aware
Alistair Cockburn described agile as being effective and maneuverable. Dave West tells us that
Agile is the ability to respond to change in the most effective way, considering the restraints of
the environment in which youre working.
As a business analyst, those definitions of agility are the ones Im keying on.
Am I sufficiently competent and flexible in my craft to adapt to any delivery methodology
employed at my place of work and be effective?
If not, what is my plan for getting there?
Practical Analyst | How agile is Important to Business Analysts | June 21, 2011
Page 2
For a business analyst, to be agile means that youre able to be effective across any variety of
situations, including types of projects and delivery methodologies.
If I want to increase my chances for success and increase my marketability, I ought to learn how to
function competently in any type of delivery environment. This means learning about the benefits
and trade-offs of the various types of methodologies, and how requirements are typically modeled
and communicated in each.
The BABOK guide is a good reference for coming up with that inventory of techniques you think
youd need to master to be more flexible across organizations and methodologies. Now, Ive heard
colleagues comment that the BABOK guide was written with a waterfall methodology in mind, and
validate that notion with the fact that the IIBA is coming out with an agile extension. But Id argue
that the BABOK has always been about providing those general principles and techniques which, if
mastered, will serve the analyst in any type of delivery environment.
In what ways can I be agile even in a very non-Agile environment?
How can I work within the constraints of my delivery methodology, such as it is, to drive
improvement in the way requirements are communicated, and around the way stakeholders
interact about requirements?
In the end, success for a business analyst is all about driving success to our delivery counterparts
and, in turn, our business stakeholders. While we may have to work within the framework of a
methodology, we can still seek out opportunities to innovate and improve.
Even in a strict waterfall delivery shop there are opportunities to approach problems in different
ways. There are opportunities for minor tweaks and improvements to increase the quality of
communication and to render solution delivery more of a team sport than an assembly line. I
know this because Ive seen it myself a number of times.
Why is it important to be an agile business analyst?
Youll notice I referred to the need for a business analysis competency in any methodology, but not
necessarily for a business analyst in title or role. This is because I think were reaching a time
where what we value in a business analyst is in transition.
For example, I think the translator business analyst who has made a career primarily of taking
notes on what the business wants, formatting it for a spec doc, and passing it on is going to have a
harder and harder time being successful and, eventually, finding work. Ive alluded in the past to
the problem of the business analyst as waiter as opposed to communication specialist. The
waiter BA is slowly but surely going the way of the Dodo.
The emerging business analyst role as Ive witnessed it seems more to be more dynamic; its one
of versatility and flexibility, and steady involvement throughout the delivery life cycle instead of
the mostly static lather/rinse/repeat process that many analysts have been able to get by with in
the past.
Practical Analyst | How agile is Important to Business Analysts | June 21, 2011
Page 3
Bottom Line
Stability and success for a business analyst over the long term lies not in sparring over which
methodology is superior and tailoring your craft to suit, but in truly becoming an agile business
analyst; one that is valuable and marketable in any environment even when the next big thing
in delivery methodology comes along.
What are your thoughts on this notion of agility for business analysts? Im always grateful for
your thoughts and comments as they help broaden my perspective and refine my positions.
View or comment on the original post: http://practicalanalyst.com/2011/05/24/the-business-
analysts-other-customer/
About the Author
Jonathan Babcock is a management and IT consultant with a passion for business
analysis and solution delivery. Practical Analyst is his outlet for sharing what he
is thinking and reading about, and for interacting with other solution delivery
professionals.



Practical Analyst by Jonathan Babcock is licensed under a Creative Commons Attribution-
ShareAlike 4.0 International License.