BigAgile

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 haven’t said much on the topic for quite a while, though, as I think I’ve 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, I’ve found that the one constant is that every methodology requires a competency (notice that I’m 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 don’t) have a great deal of control over the development methodology my company uses. Even less so if I’m 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”), I’m 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 you’re working.”

As a business analyst, those definitions of agility are the ones I’m 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?

For a business analyst, to be agile means that you’re 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 you’d need to master to be more flexible across organizations and methodologies. Now, I’ve 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 I’d 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 I’ve seen it myself a number of times.

Why is it important to be an “agile” business analyst?

You’ll 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 we’re 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. I’ve 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 I’ve witnessed it seems more to be more dynamic; it’s 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.

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? I’m always grateful for your thoughts and comments as they help broaden my perspective and refine my positions.