Month: March 2019

Basics of Agile part 3 – The Principles of Agile Business Analysis

Basics of Agile part 3 – The Principles of Agile Business Analysis

Welcome back to part 3 of the Basics of Agile series, where I focus on Agile from a Business Analysis perspective. This article introduces the Principles of Agile Business Analysis.

These principles are detailed in the Agile Extension to the BABOK® Guide (Agile Extension) from IIBA. This book, as the title suggests, is an addition to the BABOK®, also known as the Business Analysis Body of Knowledge®. Recognizing that there are special considerations for projects utilizing Agile methodologies beyond those presented in BABOK®, IIBA teamed up with The Agile Alliance to produce the Agile Extension.

The Principles of Agile Business Analysis are:

Agile Extension to the BABOK®  Guide – section 2.6

In the first article of this series, I talked about basic things being profound. Each of these principles may seem very simple on the surface. Yet, when they are understood thoroughly and combined, they are potent declarations that guide our work as Agile Business Analysts.

Here is why.

See the Whole

There are multiple ways this phrase can be applied, depending on the context. For example, on a Strategy Horizon level, it could imply seeing all of the capabilities of an organization, and how those capabilities fit together. On an Initiative Horizon, See the Whole could mean looking at all of the processes involved for a feature. And on a Delivery Horizon, it could mean having complete requirements with an understanding of how that requirement meets the broader goal.

Or, you could take another view. See the Whole could imply completeness of involvement from all stakeholders, ensuring no one has been left out. Or, have all environmental factors have been explored.

No matter how you look at it, the concept of See the Whole boils down to two things – Scope and Completeness. Do we cover the entire range of impact for the initiative or piece of work? Does it represent that range fully?

Think as a Customer

Aside from the concept of iteration, there probably has not been a concept more talked about in Agile than “Think as a Customer.” As Agile Business Analysts, doing that requires much interaction. Your guesses about what is wanted must become hypotheses to be questioned, and eventually confirmed or adjusted through your communications.

It is OK to make an initial guess and allow yourself to be wrong because the goal is to eliminate what is wrong. Eventually, this will enable you to understand what is needed and, more importantly, why it is so important.

Then, when relaying the information gathered, your voice through verbal, models, text, or any other communication, having developed that knowledge from the customer of their needs, becomes the Voice of the Customer.

Analyze to Determine What is Valuable

Value is the primary tool for prioritization. However, “value” can mean many different things depending on context and who perceives it, i.e., “Beauty is in the eye of the beholder.”

It can also depend on timing. In markets during a boom period, value can be seen everywhere. If a market busts, however, value can be challenging to find.

Value can be fleeting. That is why we analyze and why the analysis repeats over time. Especially at the Strategy and Initiative Horizons, the analysis will be repeated to confirm the necessity and priority of initiatives. Similarly, the value analysis occurs at the Delivery Horizon for the priority of work to be done for an initiative.

Get Real Using Examples

In Real Estate, often listing agents will insist that the seller stage the house so potential buyers can better visualize how the home functions. In essence, that is an example of Getting Real Using Examples.

Examples do several things. Primarily, they confirm understanding with the customer. If the example is not correct, the customer helps inform the analyst to change it. More than that, examples can be viewed in an A vs. B comparison, allowing a decision on alternatives. The examples can be of a design, process flow, calculations, or function. The beauty of examples is that once they are accepted, the example can easily be communicated to the development and testing teams as part of the requirements. In that way, examples are an essential element of a shared understanding.

Understand What Is Doable

To start, the word Doable is a relative term. Many factors can determine the feasibility of work.

That said, one of the critical elements of Agile initiatives is visibility. With visibility, all involved can see how the initiative is coming along and what is coming next. Yet if something is difficult, perhaps no one wants to admit something is too difficult for the value gained. Developers often think they can solve any problem. That is human nature for problem solvers.

Agile has a way to handle the problem. The short version is – knowing about added time or costs before performing work allows the customer to decide whether a feature is developed, altered, delayed, or removed.

A typical scenario for how that works follows this path.

At some point during what some methodologies call “grooming,” the Agile Business Analyst or Product Owner has given estimates on the work items. Those values are communicated to the customer. Then the development team has the opportunity to place their revised estimates on the work. If the estimates are significantly higher than expected, the customer would receive feedback about that feature and make a decision. This creates an opportunity to perform a cost-benefit analysis. If that assessment shows the function costs more than the customer values, then it either receives a lower priority, a revision, or it is canceled.

Alternatively, doable can be a firm constraint. The Agile Business Analyst must understand the capabilities available to the team. Perhaps a technology is not as stable as thought. Maybe we do not have a critical resource. In those cases, no matter what the value is, that feature is not doable until the constraint is removed, if removal is possible.

Whether “doable” means additional time or resources, or technical limitations, in either case, these items may generate a change request to account for the extra time or resource requirements.

Stimulate Collaboration and Continuous Improvement

I think this is two different items, but there are more areas where they overlap than where they do not. There are some areas, such as manufacturing, where improvement can come from process observation and adaptation based on empirical data. The counter-argument is you could acknowledge that the Agile Business Analyst would not know about those empirical computations unless told in some way.

Given that these are not synonymous (but mostly overlap), the point of collaboration is to bring about improvement. Every interaction with a customer, subject matter expert, or development team has the potential to make the result better. All collaboration, therefore, contributes to Continuous Improvement. This principle is a reminder to take advantage of that opportunity.

The Agile Analyst does need to stimulate collaboration. Customers are busy, and it will take an effort to convince them of the need to engage. Yet with Agile, gone are the days when the responsibility for the result is wholly handed off to design and development. Now, to some extent, everyone is responsible for outcomes. Often a reminder that unclear or incomplete requirements are an unacceptable risk can help a customer understand just how important collaboration is to the effort.

Avoid Waste

When I said everyone is responsible for outcomes, that holds for successes and failures. Avoiding Waste means avoiding failures such as rework, missed requirements, or features not directly traceable to Customer priorities. Waste could be not seizing the opportunity to change – an opportunity cost. It could be that the team did not work efficiently. Or the work did not function properly. All of these require revisiting what has been done and creates churn.

The point of the previous six principles culminates in avoiding waste. That means no waste in the final deliverable. It also means no waste in any step along the way. Waste can also be seen in cycling through discussions about the same feature due to indecision during the requirements gathering sessions. Waste can be seen where communication is either not clear, or not received clearly, requiring repeated attempts to clarify. In those cases, again, it comes back to feedback and experimentation, so that the need is observed, an improvement attempted and results confirmed.

So waste can take many different forms. But does that mean any repeated effort is waste?


Perhaps at this point, it would do well to define waste, or at least describe it as associated with different roles or initiative phases.

What is Waste?

I’m not opposed to asking what seem like obvious questions. In practice, if the problem of waste were simple, then we would have a lot less of it.

Keep in mind that Agile is iterative, so there are some elements of repetition. Repetitive tasks may or may not be wasteful. It depends on the purpose of those tasks.

Next, remember that decisions may differ once a hypothesis is confirmed or refuted, and often the experiment is repeated to show results over time. This is especially true in the Strategy or Initiative Horizon. So the work of analysis is often repeated. Yet, the goal is not to have wasted effort. The effort of analysis must have a purpose toward helping make the best decisions.

Alternatively, there is waste associated with the deliverable. There are a few sources for these kinds of waste. First, if the requirements are not complete and correct, then the deliverable will be wrong. If you use the wrong map, you will not get anywhere. Likewise, incomplete and incorrect requirements will leave the team going in circles instead of making progress.

If the team does work that is off the script, that is another form of waste. On my first Agile assignment, a developer reported that he was being pulled away by other responsibilities. That was an issue that affected the capacity of the entire team. After recognizing the problem, we had the developer refer any outside request for his time to me. Technically, in that organization, the Scrum Master should have handled that, but that role had gone through some change in personnel (3 in 6 months).

If the team does something that should have been at a lower priority, again, that is a form of waste. Work should be done with the most valuable item first, so long as those requirements are complete and correct. Agile addresses this through collaboratively reviewing the requirements, features, and functions with the customer to determine what is most valuable.

Finally, there is waste due to error. If everything were perfect as envisioned during design, there would be no reason to test. However, we need to realize that testing is the last line of defense against a problem going into production. This is why there are multiple layers of testing, by members of the development team, by specialized test engineers and as part of User Acceptance Testing.

I have spent much time on Avoid Waste. Yet, as you can see, the prior six principles all play a part in Avoid Waste.

When you think of it that way, perhaps this entire article can be re-purposed as a primer on how Agile attempts to avoid waste.

The Basics of Agile part 2 – The Waterfall Watering Pool vs The Agile Aquifer

The Basics of Agile part 2 – The Waterfall Watering Pool vs The Agile Aquifer

Welcome back to Part 2 of the Basics of Agile series.

Going back to Part 1, we talked about the motivations for Agile, and how change is an important part of those motivations. The standard for Waterfall required planning the end-to-end solution well in advance of the beginning of development, and any changes to that plan were difficult to apply once development started. Over time, this created an environment where the gap between the need vs. the met needs never narrowed. In other words, because of the rigidity of adherence to the plan, the results left the customer further behind.

Then Agile comes along and does away with planning. Problem solved, right?

Wrong. That is not what happened. However, it is a false perception.

Planning in Agile is more of a fluid process.

Water Pools for the Waterfall

I will illustrate the need for fluidity with this little story I call “The Waterfall Watering Hole.”

Imagine that a village Chief has contacted a designer to come up with a way to provide water for the village. After meeting with the Chief and other village leaders, the Designer begins his work coming up with a plan. After years of research, the Designer comes out of his hut and contacts the Chief. “I have a great design for the village water needs. It is timeless and has worked in villages for millennia.”

The design called for a large water storage pool. All the water would be stored there. According to Waterfall Designs Inc., an internationally recognized water supply thought leadership group, a single large pool is the proven method for holding water. The village water supply designer adds, “No one ever died of thirst when living near a large pool.” The design was presented to the village Chief and other leaders.

The Chief is impressed but notices the cost. Still, trusting the Designer and seeing how he had not emerged from his hut for so long, the Chief believes the Designer and approves the work. Besides, he learned a new word, “reservoir.” Without knowing what it meant, the Chief thought it had to be very impressive.

Because of the costs, he also stops eating meat to save money for the project, and to lose weight. But mainly it’s the money. The butcher is not pleased with losing his job.

The work commenced. For project integrity, access to the project was denied until the water pool was finished. No alternative sources of water and no changes to size or design would be allowed because the Chief is already on a diet.

Construction took a very long time. As the saying goes, “the natives were restless” with anticipation of finally seeing the results.

When construction ended, everyone was excited to see the water pool.

Yet over time, the water began to taste strange. Someone said, “This water is stagnant. Algae is forming on the surface.” But having the water pool was so much better, no one said anything until more problems arose.

Then the water began attracting wild animals, and what everyone expected to meet the village’s needs now was being drained. At current rates, the water would only last through half of the dry season. A concerned citizen group formed for Water Pool Reforms and asked me to be a spokesman. I ask the Designer if the pool could be bigger since the animals are drinking it all. The Designer says, “The storage pools were designed to the specifications given when this project began. These concerns should have been raised back in the design phase.”

Because these are thirsty wild animals, getting water has now become dangerous. The Water Pool Reforms group sees the need to get further away where it is safer. However, no one can carry the water from the pool around, since there are no containers. So everyone has to stay within range of the pool, and the wild and dangerous animals. You begin thinking, how can we make this portable. I ask the Designer, “Can I have some kind of container so I don’t have to stay where these dangerous animals can eat me or my family?”

“No, storage pools is the approved design,” the Designer says. “The village Chief has approved it. I do not want to have to face him again. He is always in a bad mood on his diet and does not have time to address all the needs. You are lucky to have gotten this much.”

Then there came the mosquito problem since there is a large body of standing water. Eventually, villagers begin to catch malaria. My whole family has gotten sick with the virus. I ask the Designer, “Can I have mosquito nets added to my home?”

The Designer said, “No. That would be outside of the scope of the original project, and the added expense will not be approved. Besides, we have just entered the maintenance support phase, so no changes can take place on this project. If it is broken, then you can create a trouble ticket. But it is working as designed, so we will not do anything about it. I’ve been contracted for the next village water project.”

As the Designer walks off toward the next village, he turns and says, “You complain a lot. Good luck getting any changes with that attitude.”

Fed up and trying to hide a snarky tone, I respond, “Thank you for your time.” But as the sting of the Designer’s rebuke wears off, I cannot help but think, “Was there ever a time when changes could have been made?”

That is an excellent question.

The storage pool ends up causing several problems while inadequately addressing one.

How would Agile approach this problem?

The Agile Aquifer

If Waterfall provided the Watering Hole, then the Agile response would be the Aquafer. That story goes something like this.

The village leaders ask a designer to help them have a source of water. The Designer spends a little time researching what thought-leaders propose, just to get some ideas. “Water Pools are a great answer,” she thinks. But she also had read about other methods that are far less glamorous, and wonders if that would be a better option. So, having that as a base of information, the Designer compares the various hypotheses by talking to the villagers. She begins to understand their needs and how to determine the best answer.

To her surprise, the global thought-leader’s ideas were soundly rejected by everyone in the village. People from other villages mentioned that storage pools are expensive, take a long time to build, turn green with algae, tie you down to gathering food close to the water pool, attract mosquitoes, brings in malaria and attract dangerous animals.

“Wow, the eggheads missed that one,” she thinks.

The Designer asked if the people wanted running water into their homes. She got an estimate of the cost of that proposal. Although everyone liked the idea, the Chief decided to leave that for future generations because of the cost. As he sits down for dinner (on a stool that barely supports his weight), the Chief says “Ms. Designer, please find a way that does not cost so much, but is still safer than the water pools. Perhaps when the village grows, we can address that option. We just do not have the tax base for it.”

The Designer took all of this information into consideration and came up with a less expensive and safer proposal – a water spicket located in the center of the village.

She showed her proposal. It was not very flashy. No big construction would need to be involved because the minimum viable product simply required to provide safe water. It did not need to store water, just provide it. The key was, the water was already there, only underground. The Designer began her presentation, “I have a proposal that has worked for millennia, and I’m sure it will meet your needs.”

The Chief was surprised that he had such a great water resource available and claimed great personal wisdom to access it. Plus, he had looked up the word millennia, having heard it used on neighboring water projects. Additionally, he had heard about neighboring Chiefs losing weight after expensive water projects. So if it provided for his people, maintained his lifestyle, and plausibly made him look good politically without going on a diet, then he was agreeable. “But I want to see how this project progresses,” he said. “We need to verify this will meet the people’s needs.”

A drill began digging the route through the surface for the pipe to go down into the aquifer. Everyone came to see as a water pipe was installed. The villagers review safety standards and approve each segment of the pipeline.

However, while the spicket is being built, the villagers ask the Designer if they could carry water with them as they gather food. A change request is made and sent to the Chief for approval. With the cost of the original estimate for the water spicket being so much less, the Chief was able to fit this into the village budget (along with an increase to his hefty meal plan). He was in a very generous mood these days since he was getting such a favorable result in local polling. So the additional work is authorized to supply bottles and other containers of various sizes. A family can store water in containers or bottles, with just enough to meet each family’s needs. Because the water bottles are lightweight, families could bring water with them and gather food much further away.

The village became a trendy destination for immigration in the region, which added to the Chief’s voting base. With the economic growth, a study is being done for the Shake Shack and other businesses to have running water installed. The Designer of the spicket project has been retained to assist in that effort.

So summarizing the results, with the spicket design there are no standing pools. That had benefits missed by the Watering Hole, such as no stagnation, no algae, no wild animals, no mosquitos, and no malaria. If you need more water for a period, you could always fill up more bottles. If you need to go extra far to gather food, you can carry them with you on a journey.


I know these little stories are a bit ridiculous. But they do illustrate several aspects of Agile, as well as it’s advantages over Waterfall. The second story illustrates the Seven Principles of Agile Business Analysis, as taken from IIBA’s The Agile Extension to the BABOK Guide v. 2. These principles are:

• See the Whole – Get a big-picture view of things. Researching options.

• Think as a Customer – Capturing various opinions and values of everyone involved. Talking with the villagers.

• Analyze to Determine What is Valuable – Determining tradeoffs between opposing options. Determining health and safety is a concern.

• Get Real Using Examples – showing various alternatives. Asking about Water Pool models.

• Understand What is Doable – adhering to budget constraints. Rejection of the running water to everyone’s homes.

• Stimulate Collaboration and Continuous Improvement – Adapting to new improvements as more information surfaces. The villagers were coming up with additional ideas.

• Avoid Waste – The least-cost option that provides the desired result. Choosing the spicket model instead of the Water Pools or Running Water systems.

I will talk more about the Principles of Agile Business Analysis in my next post.

Basics of Agile part 1, What is Agile?

Basics of Agile part 1, What is Agile?

“Gentlemen, this is a football.”

Vince Lombardi

Welcome to the first of the Basics of Agile series.

Basics are profound things. The more elemental, the greater the impact.

Admittedly, if you are well experienced in Agile and see this article series, you might feel a bit like the Green Bay Packers when Coach Lombardi uttered the famous quote. “Gentlemen, this is a football.”

“Yeah, Captain Obvious.”

But knowing what it must be like in most locker rooms when a great team is underperforming, perhaps the team was instead thinking, “where can I hide?”

Many coaches are known to “peel the paint” at halftime. Instead, the Packers hear this most elemental instruction. They relax a bit and start to remember their training, what they have worked on all season. I can hear the team now, or at least their thoughts – “Yeah, Coach, we know what a football is.” In the second half, they acted like it and came back to win the game.

Sometimes even for those that are experienced, like the legendary Packers, the only way forward is backward. At least, it feels backward.

There are times when we catch ourselves going through the motions. We all need reminders.

When a college basketball player that could shoot the lights out in high school cannot get the shot off in college, what can he do to fix the problem? The answer is often fundamental mechanical changes – how the player shoots. The only way forward is often going over the basics again. The results can be, in a word, profound.

On the other hand, maybe you are new to Agile and need a primer. All of this is new to you, and you need Cliff’s Notes version to help you wrap your head around it all. Trust me, I have been there.

Why is this such a big deal?

It still boggles the mind that a statement that can fit on a napkin, The Agile Manifesto, has been expanded into endless 3 inches thick volumes by multiple authors. So, what is my answer to that? Well, I guess writing about it too, adding to the digital pages on the subject. However, I promise to get to the point in this series rather quickly. At least before page 500.


Instead of going into the history of Agile, I will talk about the motivations that brought it. Motives usually have more to do with origination anyway. Or putting it more familiarly, “Necessity is the mother of invention.” Perhaps that is why Simon Sinek’s message on “Find your why” resonates so well. So, why did Agile come to be?

In previous decades, the de facto standard for software development, Waterfall, was based on a project model primarily used for engineering projects. However, that model did not perform well for software development. The problem?


Unlike buildings or cars, external and internal environmental factors caused the requirements for software to change faster than the software requirements could go through the processes of planning to development. Waterfall proponents thought that planning heavily before a project began would lower the number of problems. There is a logic to that, but the logic did not match the anticipated results. Planning too far in advance, without the flexibility to adapt, caused more problems than it solved because the environment changed before the product delivery. The gap between need and met need never closed. Actually, it widened.

A new methodology was needed in which change is embraced as part of the process, and that allowed changes to requirements to be performed as late as possible before it was developed. Several methodologies arose to fill that gap, including Scrum, XP, Rational, and others.

The thought-leaders of those methodologies came together a couple of times to discuss how best to proceed. Eventually, they agreed on a simple statement that highlighted what was in common. That statement is called The Agile Manifesto.

The Agile Manifesto

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.

There have been several different attempts to expand this manifesto into principles by organizations such as The Agile Alliance, PMI, IIBA, and others. Eventually, I will go into those proposed by the International Institute for Business Analysis (IIBA), since I am a Business Analyst. For now, I will offer my own take. This will be more exposition than a list of principles since I like to take things apart when writing about them.

First, the opening phrase hints at experimentation and empirical analysis. “We are uncovering better ways…” Agile is not a prescription, but a series of hypotheses. The intention is to find what works and do that. Whether you communicate this way or that, deploy in 2 weeks or 6 months, document through napkins or repositories – the Agile approach is to do what works for this endeavor. Those decisions might bomb on another project – even one involving the same people. However, Agile would observe and refine until it works.

“…by doing it and helping others do it.” Perform the experiment, observe the results, and share the findings with others. Feedback is built into any Agile environment from Strategy to Initiative to Delivery. Additionally, feedback is built into collaborative structures, research activities, and decision processes.

Then there are four value statements. These do not mean to focus on one to the exclusion of the other. Instead, the balance simply leans toward the left side instead of the right. The idea is to keep the focus on what is more important without neglecting those items that support the goal.

Individuals and interactions over processes and tools

The first value statement shows that it is more important to have the right people working collaboratively than have the right tools and processes. Give a team the authority to self-govern, and they will figure out what works. Expensive tools may not be necessary and can even distract.

The most efficient project I have worked on used the simplest of tools to manage the project. It was a travel and expense reporting project for an international consulting company built on a SAP HANA database to provide high performance. Team members were located in Florida, California, Kentucky, and Ukraine. This project managed quite well with the requirements captured in a spreadsheet. Each row was the equivalent of a User Story, with additional requirements that were recorded in a parallel spreadsheet for each story. There was no project management or requirements management tool. Nor was there a Kanban board to track story progress. All statuses were maintained on the appropriate row in that shared spreadsheet. Daily stand-ups were guided by a filtered list of active status rows. They splurged on getting the best development and database environment instead of high-cost project management tools that impose time and cost overhead.

As efficient as that was, it helped that the entire development team were very experienced developers, each having a master’s degree in computer science. Other teams might not have pulled it off.

Working software over comprehensive documentation

Next, the main thing is to have software that works. If it does not work, then the documentation does not matter. Keep focused on the desired result. One of the misconceptions is that Agile de-emphasizes documentation. Instead, it values timeliness of documentation that is verified by the customer just ahead of development. That means the product is based on the latest information possible. Even then, the point is not to have the newest documentation, but to have working software. Each iteration is a commitment to producing something that works. 

Customer collaboration over contract negotiation

Customer collaboration is more important than contract negotiation because customer satisfaction is not measured by a contract or statement of work. Agile understands the protective importance of a contract. They are defensive documents to describe the minimal working expectations. However, contracts are not intended as guides to product delivery. To know what is expected, you have to talk with the customer, not the lawyer. If you want repeat business, begin on friendly terms by collaborating, referring to the contract as an arbiter if the relationship is dysfunctional. Focus on building functional relationships, and you will not have to worry about dysfunction.

Responding to change over following a plan

Responding to change versus following a plan because the plan is not flexible enough to adjust to the current organizational needs.

Originally, Waterfall methods were intended to be iterative and allow change. In practice, gaining approval for change requests was difficult, and changes were viewed with much disfavor. Changes to the original plan were strongly discouraged. This effectively killed the change request processes. Opportunities to utilize the latest and best information were ignored so that the original plan would remain intact. There was a need for something different, both in the methodology and in the project output. Waterfall prevented both.

Change is built into any Agile environment. That does not mean there is no change request. After all, you do need to control cost, and CRs are how those costs are approved. In Agile, change requests may alter timelines and priorities, but they are included without sinking the project. The reason Agile approaches were envisioned was to handle change better.

The Agile Mindset

Looking at the implications of The Agile Manifesto, the importance of those four value statements is as profound as Lombardi’s football. They are a call to keep the focus on the basics of customer value, collaboration, feedback, and delivery of working results based on the most current information available. The Agile Manifesto codified a different way of thinking about initiatives and the relationships required to do the work.

Next, I will begin discussing Seven Principles of Agile Business Analysis, based on IIBA’s Agile Extension to the BABOK® Guide, which bring even more guidance to how Business Analysis works in an Agile framework.

How I Became an Agile Business Analyst

How I Became an Agile Business Analyst

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?


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.