Skip to main content

Author: Steve Blais

IIBA Podcast Episode 2: The State of Agile

Episode 2: The State of Agile with Steve Blais

Key learning points:

  • Help listeners examine the current of agile and understand if agile is continuing to pick up steam and if it is here to stay.

Listen here:



Steve Blais
Steve Blais, PMP, has over 43 years’ experience in business analysis, project management, and software development. He provides consulting services to companies developing business analysis processes. He is on the committee for the IIBA’s BABOK Guide 3.0. He is the author of Business Analysis: Best Practices for Success.

IIBA Podcast Episode 2: The State of Agile

Episode 2: The State of Agile with Steve Blais

Key learning points:

  • Help listeners examine the current of agile and understand if agile is continuing to pick up steam and if it is here to stay.

Listen here:



Steve Blais
Steve Blais, PMP, has over 43 years’ experience in business analysis, project management, and software development. He provides consulting services to companies developing business analysis processes. He is on the committee for the IIBA’s BABOK Guide 3.0. He is the author of Business Analysis: Best Practices for Success.has spent the last decade transforming the profession of business analysis, leading the development of multiple editions of the BABOK® Guide and driving the adoption of agile and architecture practices. As a senior executive in the social enterprise space, he has managed a product portfolio through rapid growth and built fully digital and virtual organizations. Kevin is known for his ability to deliver practical, effective and focused solutions to complex strategic problems and lead teams through periods of significant organizational and market changes. He has been a keynote speaker at conferences around the world and frequent author on topics including digital transformation, strategy, and leadership.

We are So Over Scrum

The question goes on in the Scrum and Agile circles about how far a team can stray from the Rules of Scrum before becoming a “Scrum Outcast” and …

earning the derision and scorn of the “True Believers.” But there is something about the stasis of staying the same and always playing by those rules that might bother some people.

Here are some thoughts on the concept of keeping to the rules or improving out of them.

The Rules of Scrum

Scrum, despite its definition by Ken Schwaber and Jeff Sutherland as “a framework for developing and sustaining complex products” [1], has a distinct set of rules. Unbreakable rules. In fact, the subtitle of the Scrum Guide from which that definition is taken is “The Definitive Guide to Scrum: The Rules of the Game.

The rules are what make Scrum, Scrum. If you don’t follow the rules you are not doing Scrum.

Now this is not a consideration uniquely tied to Scrum. If you want to play chess, you follow the rules of the pieces (the way they move), the board (8 x 8), and the other rules of the game. If you want to do something else (say, introduce a new piece, for example, the “jester” (moves 2 up, 2 over, and the player has to tell a joke) then you are no longer playing chess. There are many variations of a game with balls, bats, bases, and players, but there is only one set of rules governing baseball. And so forth.

Each of the agile approaches has rules. Extreme Programming (XP) has its Twelve Principles which establish the rules for XP. If you do not follow all twelve of the Principles, you are not doing XP. Feature Driven Development (FDD) has its processes. And so on.

The concerns of the Scrum elite are valid. They are trying to make sure that teams that only follow some of the Scrum rules and not others, and fail, do not blame Scrum for the failure. In other words, the belief is that if you follow Scrum exactly as it is defined in the rules of Scrum, the software development (or the product development) effort will be successful. If not successful, the rules were not followed, in the form of software development called “Scrumbut” (“we are doing Scrum, but [specify some rule that is not followed. e.g. we still have a project manager] ).

When asked if Scrum can be performed without various of the defined components, such as having a Scrum Master, or daily stand-ups, or a retrospective, the Scrum community is fairly unanimous is saying, “no.”

Here are some random comments from the Yahoo Scrum Development Group and the LinkedIn Agile and Lean Software development Group over the past several years.

When asked if it were possible to “do Scrum” without Scrum Master (names withheld):

“No, it is not possible to have Scrum without Scrum Master. Have a great day.”

“You can still go and do the development work without a Scrum Master, but you can’t call that Scrum.”

“If you do not have a Scrum Master on your team, you are not doing Scrum. If you do not have two bishops at the start of a chess game, you are not playing chess.”

Similar responses applied to doing Scrum without a standup and without a formal end of sprint retrospective: “It’s not Scrum, it’s Scrumbut.” So changing the rules should be avoided since no one likes to be called a “but” especially a “Scrumbut.”

What if the Rules Stop Applying?

But what happens when the team or the players find the rules constraining or restricting or decidedly non-Agile?

Is that possible?


The team had been together over three years, using Scrum as their software development approach. They were by any measure a performing team under the Tuckman model. They regularly made all their sprint commitments and performed at a high velocity especially when compared to the other Scrum teams in the department.

Over the years, in their quest for continual process improvement, they made a number of changes which affected the basic tenets of Scrum.

Because they were co-located and talked among themselves continually, they decided that their Daily Stand Up was redundant. At the Stand Up, they retold what everyone already knew from the day before. Basically, they all knew what each other was doing. They said that they didn’t miss the Stand Ups and liked the extra fifteen minutes a day the got by not having it.

They also decided that waiting until the end of the Sprint to review what they were doing was too late, making the Retrospective also redundant. They were making changes during the Sprint and adjusting and having ad hoc meetings to address issues. The Retrospective had become a review of what already happened and a waste of time.

They eliminated it.

Finally, they realized they were able to deal with all the obstacles and impediments themselves. They didn’t need to go to a Scrum Master to act as an intermediary. They ran their own Sprint Planning Sessions, and Reviews with the Product owner and they certainly needed no further instruction on how Scrum works.

Since they were functioning as a high performing team, they also worked out all their issues among themselves. They suggested that the Scrum Master could better spend his time with other teams. The Scrum Master did. (I talked to the Scrum Master, who voiced no feeling of failure or resentment at being relieved of his duties. He had more of a sense of a parent watching the child graduate from college and enter the workforce on his own. He expressed that he hoped other teams would ask that he be removed.)

Their velocity and output continued to be high in terms of both quantity and quality. But they were not doing Scrum because they were not following the Rules of Scrum. And this is all right. Certainly, the team was not concerned about labels and in any case they still assumed they were doing Scrum. The Scrum Sheriff had not arrived in town as yet to tell them to cease and desist.

First Follow all the Rules

You have to follow the rules because you need a baseline from which to evolve. Otherwise, how would you know you have improved? To paraphrase the comment from Seneca, how are you going to know the direction you want to take if you don’t have a point to start from?

If you improve your process and change one of the rules of Scrum to make it better for you, then you are no longer doing Scrum. You can call it something else. Maybe Cricket or NuScrum or Murcs (Scrum spelled backward).

What do you call it?

So if it is not Scrum then what is it? We can probably call the process whatever we want. The team mentioned above had just such a discussion. One suggestion was to call it “Elvis” (from an Elvis fan) because “We’re fast and we rock.” Other suggestions included “Super Scrum” (with appropriate uniforms), “Uber Scrum,” “Scrumptious,” and, of course, “Over Scrum” which the team member highlighted the double entendre by stating, “We are so over Scrum.”

What was their final answer? What did they answer when other developers or management asked them what they were doing? What did they finally end up calling their approach?

Nothing. They decided that they didn’t need a name. Or a title. Or an “Agile approach.” They decided that they didn’t even need to call themselves “Agile.” They were simply developing software the best way they knew how. And that was enough for them.

Agile is not about developing software or product

Maybe we have it wrong. Maybe “Agile” is not about better ways to develop software. Maybe Scrum isn’t really a “product development framework.” Maybe Agile is a way to get a group of software developers together and work as a team and then as a high functioning team. Maybe software development is just what is done while the team is forming and performing. All of the practices and indications of Agile, from pair programming to the Scrum Master, to collective ownership of code, and so forth seem to be about improving the collaboration of the team as much as producing software.

Perhaps if we view “Agile” as a team development method rather than a software development approach, all the issues with being one approach or another start fading away. When the focus is on developing a high-performance team, backlogs, refactoring, having only three roles, Feature Lists, prototyping sessions, and all the rest become methods and techniques for developing the high-performance team.

Graduation Time

In the public school system in the US during the 1950s (I don’t know how long it continued) a graduation ceremony was held when the children moved from kindergarten to first grade of elementary school. I have an old photograph of myself graduating from kindergarten, passed on to my wife from my mother. In sepia tones, I am standing in front of a school wall replete with suspenders (the dress of the day), mortar board and some kind of certificate in my hand.

Am I suggesting that Scrum is like kindergarten? In a way.

Just as Robert Fulghum said, “All I really need to know (about life) I learned in kindergarten” so we might say about Scrum: “All we need to know to be a highly productive software development team we learn in Scrum.”

Just as in kindergarten and throughout all school, the ultimate goal is to learn something and to graduate. With Scrum (and with all Agile approaches) our goal is to learn something (especially about being in a team) and eventually to graduate from Scrum. And it doesn’t matter what we call the process we use after we “graduate” from Scrum. We can simply call it “Agile,”

Your goal should be to start with all the rules of Scrum so that you are doing Scrum and then improve to the point where you are not doing Scrum and graduate to something better: your team’s own software development process.

As Tobias Meyer once said,” the ultimate goal of Scrum is to eventually stop using Scrum.”

[1] Schwaber and Sutherland, The Scrum Guide, July 2016, Scrum.Org and Scrum Inc.

Executive Leadership – These 2 Characteristics Will Take You to the Top

Organizations are looking to fill the upper management positions that lead to the executive level to groom the leaders of tomorrow.

What are they looking for?

They are primarily looking for two characteristics in the people in their organization. The problem for those who wish to advance to the higher-paying higher responsibility positions in the organization is not in possessing these two characteristics, but in demonstrating them, in other words, letting senior management know that you possess them.

Over the past eight or 10 years in my travels and conversations with senior-level people in companies around the world, a common issue has been voiced. There seems to be a lack of senior mid-level managers in the organizations. This layer of top mid-level management is important to organizations because that layer is where the executives of the future will be drawn from, and where the CEOs of the organization will arise.

Related Article: Six Things You Can Do Today to Prepare for Leadership Tomorrow

What the executives pointed out is that that particular hierarchical level seems to be populated by employees who have reached that level based on seniority, and do not have the characteristics necessary to rise to the executive level. Many of these companies are forced to go outside the organization for their executive-level talent.

That the executives are looking for candidates with “excellent communication skills” practically goes without saying because those not possessing the ability to communicate well would never be considered in the first place.

There are actually two other characteristics which are critical to rising in the corporation. And it turns out that these two characteristics are also key ingredients to success in business analysis.

What are these two essential characteristics?

I will not keep you in suspense. This isn’t a mystery novel where the two characteristics will be exposed in the last sentence. The two characteristics that executives are looking for in the people that they would like to see as executives of the next generation are problem-solving and decision-making.

The successful business executive can handle challenges,
make decisions, and solve problems at a remarkable clip.
– Zig Ziglar

In a recent survey of 3169 hiring managers by CareerBuilder, the number one skill listed as needed for advancement was problem-solving and decision-making (they combined the two into one skill). 50% of the responders listed it as a mandatory skill. This is ahead of oral and written communications, performance improvement, leadership, team building and technology expertise. The survey covered all industries. As an article on the survey says, “it is not surprising to see problem-solving skills at the top of the list. The ability to find a problem, analyze it, create potential solutions, pick a solution and implement the solution is part of everyday life in IT.” [1] (and, I might add, part of everyday life for a business analyst)

That is easy enough said. We simply need to be decisive problem-solvers. But there are two aspects to this. First, we need to make sure we understand what a problem-solver is and what it means to be decisive. Secondly, we need to know how to make sure those making the decisions about who joins them in the ranks of upper management see the fact that we are clearly decisive and able to solve problems.

The definition of problem-solver and the definition of decisiveness, or decision-maker, may surprise you. Normally people think of problem solvers as those who come up with the solution to a problem, and the way to prove that you’re a problem-solver is to quickly come up with a solution that will work.

Similarly, the measure of decisiveness or a good decision-maker is usually based on whether the decisions made are right or not. Someone who makes more right decisions is considered to be a good decision-maker.

Actually, both of these mindsets are not accurate. Upper-level management is looking for something different.

Leaders are problem solvers by talent and temperament, and by choice.
Harlan Cleveland

The Office of Personnel Management (OPM) in the United States is an agency that provides the guidelines for hiring, promoting, staffing, and assessing the employees of the United States Federal Government. The OPM has published definitions of the characteristics and skills necessary for high-level management positions in the US Federal Government. The OPM has defined five Executive Core Qualifications of leadership competencies and characteristics needed to be successful, serve customers, and build successful teams and coalitions both within and outside an organization. While three of the core qualifications are focused on leadership (leading change, leading people, building coalitions and communications), and one is on business acumen, the center of the core qualifications is one called “results-driven.”

The results-driven executive core qualification consists of six skills: accountability, customer service, entrepreneurship, technical credibility, and the two we are focused on here, decisiveness and problem-solving.

This is the way the Office of Personnel Management defines decisiveness: “makes well-informed, effective, and timely decisions, even when the data is limited or solutions produce unpleasant consequences; perceives the impact and implications of decisions”.

This is the way the office of personnel management defines problem solving: “identifies and analyzes problems; weighs relevance and accuracy of information; generates and evaluates alternative solutions; it makes recommendations”.

What does that mean?

Leadership is all about problem-solving
– Colin Powell

In terms of problem solving, note that the definition does not mention actually solving the problem. A problem-solver is one who make sure that the real problem is being solved, that appropriate investigation and analysis has been done of the problem, and multiple potential solutions are identified (not just one), and recommendations are made, not solutions.

Does that mean you are a problem-solver if you don’t actually solve the problem?

Yes, that is what it means. Here is a scenario that illustrates this.

You are in a meeting with your peers and your boss. Your boss brings up a problem facing the organization. The boss is looking for a solution. In a few seconds, someone across the table offers a fairly decent solution to the problem. Then another person at the end of the table provides a solution. Someone else on your side of the table voices an agreement with one of those solutions. After a short discussion on the merits of each potential solution, you speak. You ask questions of the boss about the problem. You ask questions of the others in the meeting to make sure that the right problem is being discussed. You engender a short discussion on the cause of the problem. Then you suggest several solutions which include those already voiced. You do not state that any particular one is the solution, but accompany the alternatives with the benefits and risks of each solution. You leave it up to the boss to decide on the solution and “solve” the problem. Which of the three speakers does the boss consider a problem-solver? Cognitive studies have shown that the boss will leave the meeting thinking that you are the premier problem-solver of the group even though you didn’t actually present the solution.

The first step of solving any problem is trying to understand it by creating a mental model.
– Luke Hohman, [2]

Interestingly, if there were no need for an immediate response in this scenario, suppose you were to instigate the conversation about problem definition and root causes and prompt a discussion of alternative solutions, then suggest that time is necessary to consider the situation before coming up with a solution. Even if you did not spend the time thinking about the problem and potential solutions, the boss would consider that you were an excellent problem-solver.

That “pause” between the request for a solution and the response with multiple alternatives gives the impression that processing time has been taken to generate a better potential solution. Cognitive studies have shown that the act of taking time before answering a question or, in this case, producing a solution, elevates the quality of the response in the mind of the person with the problem or the one asking the question.

In any case, the person who focuses on defining what the real problem is, asking questions about the problem and the conditions that cause the problem, analyzing for root causes, and offering more than one alternative solution, is the one who is perceived to be the problem-solver. Again, it sounds like the typical business analyst response to being given a business problem to grapple with.

Again and again, the impossible decision is solved
when we see that the problem is only a tough decision
waiting to be made.
— Dr. Robert Schuller

Turning our attention to decisiveness, notice that nowhere in the definition of decisiveness is there any mention of whether a decision is right or wrong. There is a simple reason for this. You can never know whether a decision is right or wrong until after the decision has been made and actions have been taken to implement the decision. Sometimes you don’t know whether a decision is right or wrong for years afterward. How can an evaluator determine whether someone is a good decision-maker, someone is decisive, based on whether their decisions are right or wrong?

What is important in the evaluation of decisiveness is seeing that the decision-maker has a consistent and considered process when making a decision.

Informed decision-making comes from a long tradition of guessing and then blaming others for inadequate results.
Scott Adams

A study was done about 10 years ago of executives of US corporations, with a focus on chief executive officers. I don’t know how the study was done, but the results indicated that the typical CEO of an organization (the person making millions a year for their ability to lead, which includes making decisions) made the right decision only 33% of the time. I thought that was an interesting bit of trivia, but then another study was done just recently which produced the same results: executives of organizations make the right decisions only 33% of the time.

So why are they paid the big bucks? Of course, it’s their overall leadership abilities and business acumen, and so forth. In terms of their decision-making, they consistently follow a decision-making process.

Does this mean that you could be considered as decisive, a top-notch decision-maker, even if your decisions were right a small percentage of the time?

Well, in a word, yes.

And we have a cognitive basis for that conclusion. Human beings tend to try to justify their decisions and make them right once the decisions are made. If you have ever had a conversation with someone, a friend, relationship, team member or fellow employee about a decision that was made, and the conversation was all about why it was a great decision and the right decision for the situation, then you have participated in trying to make that decision right. For a number of psychological reasons – ego, pride, cognitive equilibrium – we have the need to try to make our decisions right – after they have been made.

Don’t worry about making the right decision;
worry about making the decision right.

So the key factor in being perceived as a decision-maker is to have a process for making decisions: ask questions about the alternatives, analyze to make sure that you understand the problem underlying the decision that needs to be made, ask for advice and counsel from those who are familiar with the conditions of the decision, review the impact of each alternative on those affected by the decision, and make the decision in a timely manner (not so quickly that it is a knee-jerk reaction, and not so long that the decision is not effective, or taken out of your hands).

Decision-making and problem-solving: two skills which, when mastered, will lead to the executive suite. Both skills can be learned, and both skills can be improved with practice. The important and necessary ingredient in the improvement of each of these two skills is to be aware of your decision-making and problem-solving processes. If you kept a daily list of the problems you solved or the decisions you made (business, personal, social, etc.), that alone would raise your awareness of how you solve problems and make decisions, and that alone will improve the skills.

And the really neat thing is that the OPM definitions of problem-solving and decisiveness sound like the US Office of Personnel Management was describing the actions of a business analyst. As I’ve said before, the CEOs and business leaders of tomorrow will come from the ranks of today’s business analysts.

[2] The Journey of the Software Professional, Prentice-Hall, 1997

From The Archives: What Is An AGILE Business Analyst?

There is a lot of talk among business analysts nowadays about something called an agile business analyst. This appellation is generally applied to business analysts who work in an agile software development environment. This is a topic of discussion among business analysts throughout the industry. Courses are being written and delivered about how to be an “agile business analyst.” There is a discussion group on LinkedIn, with the title “Agile Business Analyst”. One thread on that discussion group was started by Leslie Monday, August 29, 2011, titled “What Is An Agile Business Analyst” and it is still going strong. There are at least a dozen other threads in other business analysis oriented discussion groups on LinkedIn, attempting to answer the same question, and I’m sure there are similar discussions being carried on in other communities around the Internet, and most likely in local IIBA and other business analyst organization meetings.


In some cases the discussions have a certain desperation to them because the agile community itself has in the past, eliminated the business analyst role from the agile software development process. The anti-business business analyst vitriol has been quite strong over the years. The claim has been that the developers can do their own business analysis and an extra person in the position of business analyst simply gets in the way.

In these discussions, there are those, myself included, who claim that a business analyst is, and really always has been agile. (A discussion started by Louise McDonnell that lasted several months challenged discussion members to come up with a clear differentiation between a business analyst and an “agile” business analyst.) The profession of analyzing the business requires flexibility, responsiveness, creativity, innovative thinking, acceptance of change, and a dependence on individuals and interactions. Such qualities are desired, if not required, regardless of whether the business analyst is involved with agile software development, traditional software development, or no software development at all.

So are agile business analysts “agile” because they work on an agile software development team? And if so, does that imply that those not working on an agile software development team are not agile?  I contend that in business analysis, agility is a mindset having nothing to do with the framework in which the practitioner of business analysis works. In other words, an agile business analyst is agile whether he works on a scrum team, any other agile team, or no agile team.

Let me illustrate my point by differentiating between a business analyst working on an agile team, or a developer playing the role of the business analyst, on an agile team, and an agile business analyst. Before the agilists start screaming, I am not suggesting that this is a binary or exclusive differentiation. In the annals of agile, there is a constant reference to the difference between “doing agile” and “being agile”. I am trying to demonstrate the difference between “doing agile” and “being agile” as it relates to the business analyst.

Related Article: The Agile Business Analyst: For an Agile Team, You Complete Me

We can look at an agile business analyst manifesto of sorts to describe what an AGILE BA is. You may find that the tenets of this “manifesto” apply to you even if you are not associated with anything remotely resembling agile software development. If so then you can call yourself agile for no other reason than the acronym associated with AGILE BA.

The Characteristics Of An AGILE Business Analyst


Clearly everyone associated with agile must be adaptable, since that is the essence of agility, according to the manifesto and those who promote it. However, the adaptability inherent in the agile software development approaches is focused on the flexibility required as a natural part of software development. The AGILE BA is not solely focused on software development or defining requirements for development teams. The AGILE BA defines improvements to business processes, assists decision-makers in gathering information to make decisions, helps quality assurance test solutions and products, designs user interfaces and even steps in as a product owner, scrum master, or project manager as the occasion calls for. The AGILE BA may define a set of requirements as a standalone document to outline what must be done by the organization to move to new facilities and then prepare the user stories in a just in time approach for an agile development team. The AGILE BA is not committed or bound by any specific process (software development or other). The AGILE BA is committed to solving business problems wherever they occur in the business however they may be solved. Therefore, the AGILE BA must be able to adapt to the business process, the software development process, or even a lack of process, and to any and all management directives, and not be focused on a single process or framework.

Goal Orientation

The AGILE BA’s goal is to add value to the organization by solving business problems. While the developers are focusing on producing new pieces of working software every two weeks, the AGILE BA has a focus on the overall problem that will be solved when the entire project is completed. The AGILE BA is also the weathervane indicating when a project has outlived its usefulness and is becoming a zombie project. The AGILE BA, always having the goal or the solution in front of her, is able to determine whether the project is still on track, the problem can be solved, or the problem has already been solved. This goal orientation is the result of the AGILE BA’s system thinking capabilities and the business analyst’s ability to see the big picture in addition to the detailed tasks necessary to complete the next Sprint.


While the solution development team is focusing on completing the items on the backlog in a reactionary mode to be sure that software is developed every two weeks, the AGILE BA is looking for new approaches to solving the business problem and improvements to the business processes in which the problem exists. The solution development team must follow the dictates of the product owner as reflected by the prioritized product backlog. The AGILE BA challenges the business manager, sponsor, problem owner and users to define the real business problem behind the expressed “needs” to ensure that the solution team is solving the right problem, and not providing the right solution to the wrong problem. Innovation requires a modicum of critical thinking that may generate conflict and change, moving people out of comfort zones, and taking risks. Such risks are not commonly undertaken when the driving force is producing releasable software every two weeks and the whole idea of the fixed timebox approach to agile software development is to create a comfortable rhythm for the development team to produce software. Breaking out of this comfort zone is not a desirable activity.


The AGILE BA is a leader providing solutions to business problems and continuous improvement to the organization. This leadership factor is not achieved through authority, but through influence and through facilitation and communication. A recent book edited by Penny Pullan, titled “Business Analysis And Leadership: Influencing Change”, written for “all who practice business analysis, whatever their job title.” Suggests that “business analyst lead through their work with stakeholders as they build an understanding of what’s needed and look to the future.” The leadership of the business analyst on the agile team is usually focused on the team and the project and the emphasis in agile approaches is on teamwork rather than individual leadership. To again quote from Penny Pullan: “while many business analysts see no need to look beyond their immediate project, outstanding ones will always have one eye on the organization they work within. They realize that, in order to make change stick, they need to understand and engage widely across their whole organization. This requires an understanding of the entire system, the ability to deal with power and politics, skills and working across boundaries of culture, and an understanding of both strategy and commercial realities.” And this defines the AGILE BA.


Throughout all the AGILE BA dealings with the business sponsor, customers, process worker’s, users, solution team, technical personnel and upper-level management, the AGILE BA exhibits empathy and understanding and provides an intermediary who is a mediator, a calming center in the midst of the storm of controversy and confrontation that usually accompanies organizational change. A certain amount of empathy is needed on an agile team in order for it to function as a high-performing team. That empathy does not have to extend much beyond the team since, as defined by the agile frameworks, there is only one business person to talk to who represents the entire business organization. The AGILE BA is thinking relationship across organizational boundaries, and indeed outside the organization, empathizing with customers, both internal and external, which includes a wide range of personalities and attitudes.

Business Orientation

Let’s face it; the agile software development team is focused on the technological issues of producing working software every two weeks. Granted, this working software must be oriented toward the business because it must produce value to the business, but many agile teams depend on the Product Owner or similar role to provide the business justification so they can focus on the production of software. The AGILE BA is unashamedly business oriented, thinking continuously about what can be done to improve the business and the business processes which drive the business. The AGILE BA is thinking about what the business needs to do to solve the business problems in addition to what the solution team needs to do. The AGILE BA is as comfortable talking to senior executives about business matters, the marketplace, and competition, as to the development team about user stories.


In a timebox driven, delivery focused agile process, the general guideline is to not plan more than one or two iterations ahead. As Jim Highsmith advises,” The agile approach assumes that the project plan is fundamentally irresolvable past a very simple approximation. There is no amount of information that will provide the resolution to the project issues beyond that point”. And that point is generally two – four weeks and within the somewhat narrow focus of the project itself: the system and the features or functions being developed. The AGILE BA is completely familiar with the problem domain, the business area in which the problem exists and is able to anticipate positive and negative impacts to other areas of the organization. However, the solution should be the best for the whole organization, and not just a particular business area. Therefore, the AGILE BA has to retain enough independence to evaluate potential solutions based on the overall impact to the organization rather than the influence of the particular business area and its managers. Solving a business problem solely for the business unit might have immediate benefits; solving a business problem from the perspective of the whole organization brings much more lasting value.

So there you have it, a clever acronym to distinguish what an agile BA is. And, as mentioned earlier, to many business analysts following the tenets stated above, the words “AGILE BA” could be replaced by “business analyst” because the tenets define the job of analyzing the business, or being a business analyst, whether agile or not.

Don’t forget to leave your comments below.


Pullan, Penny and Archer, James, “Business Analysis and Leadership: Influencing Change”, Kogan-Page Limited, 2013

Highsmith, James, “Agile Software Development Ecosystems”, Addison-Wesley Publishers, 2002