7 Things Business Analysts Need to Know About Agile

1. Agile is Not a Methodology. It is a mindset.

Agile has reached and frankly blazed past buzzword stage. It is also no longer new (the term being applied to software development over 16 years ago). As people become familiar with it for the first time, it is frequently referred to as a software development methodology or a project management methodology.

It is neither of those things or anything. It is a way of looking at and thinking about how to approach knowledge work. Instead of a noun, it is an adjective.

Alistair Cockburn described it best on his blog. The essential part of his argument is that methodology is a set of conventions the team agrees to follow. Scrum, Kanban, XP, SAFe, etc. are frameworks that teams use as a starting point for creating their methodology to fit their context. (Some people in the Scrum and SAFe worlds forget that).

The agile mindset provides some guidance that teams can follow when creating their methodology, including the idea that teams should create their methodology in the first place. I have my own way of viewing the agile mindset, and I like the description that Joshua Kerievsky has championed recently:

• Make people awesome
• Make safety a prerequisite
• Experiment and learn rapidly
• Deliver value continuously

2. There’s More to Agile Than Just Scrum

The Scrum framework has won the market share wars as the most commonly used framework when organizations adopt agile. That leads many people to conclude that agile = scrum. In reality, Scrum is only one of many frameworks that you can use as a starting point to approach work in an agile fashion. I like to use an analogy here: Scrum is to agile as Kleenex is to facial tissue.

Why is that important? Because Scrum is only one way to approach living agile values and principles, it is not appropriate in every situation, and it is not a complete solution. If people think that they have to do scrum to be agile, they also conclude they have to have sprints, even when the nature of work lends itself to reprioritizing and deploying much more frequently than once every two weeks. It also leads them to ignore the excellent technical practices found in extreme programming.

Corollary: Scrum is not an acronym. It is a term borrowed from rugby.

3. Analysis is Still Relevant

Just because most of the frameworks do not mention business analysts does not mean that business analysis is still not necessary. The frameworks are not intended to be all-encompassing.

The agile frameworks were created by software developers to solve problems that software developers face. They all have a role that is responsible for determining the right thing for the team to work on. In Scrum, that is the product owner. In XP, that is the onsite customer. Most of those frameworks do not say how that is done.

That is where analysis comes in. Analysis techniques are still useful, but you will find that how and when you use them changes. You perform small amounts of analysis more frequently to aid communication and build a shared understanding rather than do all of your analysis at once to produce the only means of communicating.

4) Agile Alone Will Not Get You Better, Faster, Cheaper

Teams and organizations can also use analysis to determine the right things to deliver, and the things not to deliver. Because most of the agile frameworks do not mention this, they defer that responsibility to a specific role, without much insight into how to do it.

When organizations adopt agile in their IT and development organizations and do not make corresponding changes in how they manage their portfolio of work, they soon find that they have become more efficient at producing the wrong things.

When organizations combine proper decision making and a focus on outcomes with well-functioning development teams that build quality into what they build do they truly realize the benefits of an agile mindset.

5) Writing and Slicing User Stories Is Not The Whole Story

Business analysis does not exist to elicit, document, and manage requirements. It exists to “enable change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders.” Requirements are only a means to those ends.

Along those same lines, there’s much more to analysis with an agile mindset than writing user stories and slicing them down to a certain size. Those are just a couple of mechanisms that you can use to help build a shared understanding with your team about the problem and the solution. Many other techniques are helpful to have in your toolkit such as job stories, specification by example, story mapping, context diagrams, process decomposition, mockups, wireframes, and a host of others.

The next time you get obsessed with how you write user stories, remember what Jeff Patton says “Stories get their name from how they should be used, not what should be written.”

6. Business Analysts Can Be Product Owners

Product ownership boils down to three things:

• Focus everyone on outcome over output.
• Build and maintain shared understanding
• Make decisions.

As I describe in a series of posts on product ownership models, there are several circumstances where business analysts perform product ownership and do those three things. To make that happen a business analyst needs to be able to make decisions. Good BA’s should already do the other two things as a matter of course.

In some cases business analysts do not make the decisions themselves. This occurs when they are dealing with several stakeholders who do not own the internal product but have a considerable say in what it looks like. In those situations, the business analyst may still be a product owner, but the third item is more appropriately worded “Make sure decisions get made.” If the business analyst does her job right, the development team will not experience a difference. They will not experience interruptions due to delays in decision making. They just may not have insight into how those decisions got made.

7. Business Analysis Does Not Have to Be Product Owners

If a business analyst is not a product owner that does not mean there is no place for them in an agile setting. A common model is where there is both a product owner and business analyst work on the same team. This model often occurs where the product owner makes decisions, and the business analyst focuses on building and maintaining shared understanding. This model is also prevalent when there are multiple teams working on a complicated product.

I have also seen business analysts slide into the role of coach (scrum master) because they have excellent facilitation skills and can work through team dynamics issues. This situation is a good indication that people should fill the roles that their experiences and expertise prepare them for, not solely based on their job title.

Did I Miss Anything?

I would like to hear your thoughts. Is there something I missed that business analysts need to know about agile? Do you have questions about anything I listed?

Let me know in the comments.