A few years ago, I wrote an article about how Business Analysis found me. I cannot say that I found Business Analysis, since I was not looking for it. I did not even know what it was.
Well, how did I get into Agile as a Business Analyst?
Well, quite literally, I applied for a job and got it, then figured out what the job did. If you read my first article, that should sound familiar. Here is the story for my transition into Agile.
Lightning Strikes Twice
As a 2-year contract with a nationally known liberal arts college was ending, I was entering the job market again. I felt I had a significant impact on things while at the college. Among other things, I had begun a campus wide Project Office, helped negotiate some needed services when the college hosted the Vice Presidential debate, and lead an initiative to automate financial aid packages. Now I was looking for the next adventure. While looking at the job listings, I kept seeing this job title called a Product Owner.
In my first article, I admitted my confusion by the title “Business Analyst” because I did not connect IT projects to Business. I have learned a lot since then. Relevant to this story, I have learned that job titles do not always convey what job roles do, unless you know how those titles were derived.
I kept seeing this title “Product Owner.”
I did not know what that meant. Why is a “Product Owner” considered an IT role instead of Marketing? Having experienced that unknown in job titles before (when I became a BA), I did not let it stop me.
Reading the job description, I could tell it had something to do with requirements. I figured I could handle that and I had heard of Scrum. So I prayed and applied.
A few days later, I was surprised to hear of my selection for an interview. The client was one of the major health insurance providers, which happens to have its headquarters in the region.
I drove the 80 minutes to the location. Yes, that was a hike. The company has employees in several buildings in downtown Louisville. On my way in, I quickly discovered that I underestimated what happens when traffic stops on the interstate. Living in a small town, I had not seen that coming. As the traffic started moving again, my nervousness began to leave.
After finding a parking spot, it turns out I was only a few minutes later than I had planned, and the 15 minutes cushion I had given myself was just enough to help me find my way around the tower to the interview.
Just in time. Maybe that should be the basis for a delivery methodology.
Swing and a miss
Then my two interviewers presented a scenario on a whiteboard, and asked how I would communicate that scenario to a development team.
Simple enough. I squelched the thought that “You just answered the question you’re asking,” since they had conveyed the requirements to me. Then I gave my answer.
I thought I responded quite well, talking about the inputs, outputs and the processes of transformation along the way.
Strike 2
My interviewer prompted me saying, “Well, we don’t do it quite like that. Can you try again?”
Quizzically, I tried again, paying attention not just to content, but order, maybe they talk about the end result first. I might have added acceptance criteria from some previous experience dealing with User Acceptance Testing. I will not swear to that.
My questioner asked me to try again … again.
3-Pitch Strike Out
I know now this interview is toast. Giving up, I responded, “I know what the elements are, but obviously you’re looking for some magic formula. I don’t know it. But if you tell me, I’ll do it.”
That was the first time I had heard the phrase “User Story” or the format “As a ___ I need a ___ so that I can ___.”
Reached on a Passed Ball
On my way home, I called my recruiter to deliver the bad news, while simultaneously thinking what I would tell my family. Somewhere in the conversation he responded, “You got the job.”
To this day, I do not know how. Desperation I guess.
I started drinking from a fire-hose as soon as I got home and downloaded Mike Cohn’s book User Stories Applied to my Kindle App. Things moved fast, and it has not slowed down.
That was my introduction to Agile.
Transitioning into Agile Business Analysis
One of the recurring themes of my career is that titles do not really mean much. Each organization has a different lexicon for such things. Sometimes it is due to legacy overhead. Others times, internal creativity outside of the established norm. Whatever the reason does not really matter as much as what those roles actually do.
The same is true for Product Owners, Business Analyst, and Agile Business Analyst. I have held all three titles while doing the same kind of stuff for different organizations. So, in another parallel to my first “How I Became…” article, the Agile Business Analyst role itself is suffering from an identity crisis of sorts.
However, I do believe I should promote ideas and concepts in a consistent manner. So, in spite of what the broader market is, for the remainder of this article I will choose to go with titles established by IIBA.
So, what is Agile Business Analysis? This time, I will turn to the Agile Extension to the BABOK® Guide (Agile Extension v2, IIBA) for assistance.
“Agile business analysis is the practice of business analysis in an agile context with an agile mindset.” (Agile Extension, page 2)
That clears it up.
Maybe not.
I will have to break that down a bit. First, there are many ways to practice Business Analysis. To get a handle on the broader topic of Business Analysis, I would recommend the Business Analysis Body of Knowledge (BABOK® Guide v 3, IIBA).
Next, this is not saying that Business Analysis is Business Analysis whatever the Software Development Life Cycle (SDLC). Although there are commonalities, there are stark differences as well. For an Agile Business Analyst, the distinctiveness comes from applying the Agile Mindset.
So let’s go a little deeper to explore what that means.
Agile Mindset
The Agile Mindset is developed by applying The Agile Manifesto for Software Development to Business Analysis. If you’re reading this, you probably have at least heard of the Agile Manifesto. But for a reminder, here it is.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
So, these are the guiding principles of Agile. Any flavor of Agile.
Expanding on the Manifesto
It is interesting that the Agile Manifesto was signed in 2001 by 17 proponents of various software development life cycle methodologies such as Scrum, Adaptive and Rational, and it makes reference to software development in the first sentence – but the Agile Manifesto has much broader applications than software. In fact, the case can be made that these principles were first put to paper in 1943 by the manager of Lockheed’s skunk works to develop experimental jets and spy planes. A far cry from modern software development.
In fact, there are many examples of the Agile Mindset being applied to all kinds of industries and sectors outside of software.
Going back to the definition of Agile Business Analysis, that means that you utilize principles that can be traced to the Agile Manifesto (or Lockheed’s Skunk Works) to Business Analysis.
But, what does that mean? How does that affect deliverables?
Feedback
In Agile, whether you are working on Strategy, Initiative or Delivery Horizons, the key component boils down to a loop between Inspecting and Adapting. Inspecting and Adapting occurs on all 3 horizons, and is performed iteratively. This means that new findings can be added that alter the resulting priorities and the product.
The key is that these shifts occur based on feedback from all involved, as everyone discovers new insights into what can or cannot work and what is valued by the customer.
It is called Agile for a reason.
These feedback loops are built into the analysis at all levels to allow changes to occur up until just before the beginning of development of an item of work.
Contrast that to more traditional approaches where the plan is set in stone well before development begins. Changes are difficult and frowned upon. Rework is necessary after developing items who’s function should have been altered as more information was unearthed.
The benefit of continuous iterations and adaptive planning is that there is less rework due to changes that occur during the product. The change can be built into the end result.
This is not only for development, but for planning and initiative as well. On those levels, the analysis includes prioritizing organizational directions on a higher Business Architectural level. Areas of opportunity or risk mitigation can be iteratively and adaptively explored, with the resulting plans taking on more of the flavor of a hypothesis than a set path.
The results are that everyone knows what is expected, when it is expected and how it is supposed to work. With that knowledge, there is a drastic lessening of misunderstood requirements.
Well and Good But…
Now that we know what it means to be an Agile Business Analyst, how do you become one?
You could do like me and wiff on an interview. I would not recommend it. These days there’s more experienced talent out there who have worked with one of the Agile frameworks before. Although there is still much more demand than supply, I doubt you would find a company as … desperate. But still, the path isn’t that far off from what I experienced, though there is some newer developments that give structure to the way forward.
First, you need to be a Business Analyst. I’ve discussed that in my article on becoming a BA.
Next, study one or more of the Agile frameworks, or take a job in which Agile is utilized. This will give you familiarity with terminologies and techniques that apply to Agile frameworks, but not to traditional SDLCs.
Join organizations which promote one of the Agile variants such as The Scrum Alliance or IIBA. I like IIBA because it has a focus that prepares initiatives well prior to the delivery of the product. Their CBAP certification similarly expands the role of Business Analyst both before and after the project. I have found that broader perspective allows for a broader career path as well, such as into Business Architecture.
With a couple of years of experience, you will begin to see what it means when the manifesto says it values the items on the left more than those on the right. The thought process in that shift is profound.
Next, read the Agile Extension cover to cover, taking time to understand the implications of the Agile Mindset, and the 7 Principles of Agile. Learn what those mean to planning, communication, collaboration, value determination, prioritization and rapid delivery.
Now you’re ready to take the next step and get certified. IIBA introduced the IIBA-AAC exam about a year ago to certify Business Analysts that have demonstrated their understanding of how to apply Agile principles across the 3 Horizons.
And when you’re ready to prepare for the exam, please let me know. My local chapter of IIBA is preparing a study group for the IIBA-AAC exam this fall, and I am planning to lead it. I would love to see you there.