How to Stay Relevant as a BA in Agile: The Agile Business Analyst Dance

As the agile software development wave breaks over the IT and business worlds, business analysts may find themselves drowning.  The agilists decry the need for the business analyst as a “middleman” between the customer and the team opting to meet directly with the customer or product owner or even users. As business analysts in light of this agile hue and cry, it feels like we are facing extinction.  It doesn’t have to be that way. There are alternatives. You can execute the agile business analyst’s dance: step in, step out, step around, step over, step into. 

Step in

Become a member of the team, not as a business analyst but as a developer. I don’t mean giving up the business analyst role, but rather assuming a team role. In Scrum, for example, everyone is a developer or team member with no explicit roles. Instead of spending your time apart from the team, going out each day to attend meetings with the stakeholders and users and business, hunting and gathering the wild requirements and bringing them back to the tribe at the end of the day, the business analyst on the Scrum team works within the team. The business analyst may lead the team in working with the product owner or the customer to refine the user stories into manageable pieces that can fit within the time box during the early backlog meetings, and then spend the rest of the sprint helping develop test cases or modeling with the team or even, <shudder> doing some coding.

Step out

You may opt to step out of the middle and move to the business side of the equation, even if you work for IT. You may be the product owner’s representative to the team and to other business areas where you will play mediator and negotiator. As such you might help the product owner define the items on the product backlog and assist the team by detailing those items. You work with the neighboring constituencies to make sure there is no adverse impact on their business processes. You will essentially become the Subject Matter Expert in all things pertaining to the business side of the project on behalf of the product owner.

Step around

Some agile teams adopt an overlapping approach as defined by the originators of the approach on which Scrum is based, Takeuchi and Nonaka, as Type B.  The business analyst performs the business analyst activities during one sprint in advance of the developers working on the results during the next sprint. In other words, the sprints run in parallel.  Be cautious when executing this step. Even though it is a valid approach endorsed by Jeff Sutherland, one of the founders of Scrum, many agilists reject the practice as being too “waterfall-ish.”

Step over

While the team and product owner are focused on the next sprint, you are looking at the bigger picture, keeping your eye on the final target, the original vision, the problem that the organization needs to have solved.  It is quite easy working on one piece at a time for the team and product owner to diverge from the original path and end up afar from the original intention. The business analyst helps to keep the product owner and team on track by keeping the problem and vision alive and maintaining a systems view of the project and where it fits in the scheme of things.

In other words, regardless of how extreme the agile approach may be to software or product development, there is still a need for the role of business analyst.  And if there is political or other resistance to keeping a business analyst around, the business analyst can always step into.

Step into

The business analyst might step into the role of either the product owner or the Scrum master. The product owner is the most likely transition, although Ken Schwaber (the other founder of Scrum) admonishes that the product owner not be a business analyst.  The product owner has other duties than to analyze the business or the requirements. However, the alignment of skills is fairly close between the business analyst and the Scrum master, so the transition may be easier. Moving to Scrum master might also be a road to follow if you are particularly good at facilitation, mediation and coaching. When you step into the Scrum master’s shoes, you basically give up your analysis tendencies and fully adopt the facilitating aspects of the business analyst. In other words, in either case you are no longer truly a business analyst, but you are still employed.

>>Learn More About Being an Effective Business Analyst

Being effective as a business analyst means understanding what a business analyst does, and the essential steps that are relevant no matter what software development methodology your organization chooses. Learn more about being an effective business analyst by clicking through to these articles.

 

 

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Comments

  1. Great article on the concept of generalizing specialist on Scrum teams. I might also pass on a few observations along the same lines.
    A business analyst needs to have the capacity to think critically, that is, to not accept things at face value. For example, to question when a business stakeholder says “we need this…” and ask why the business stakeholder needs it. To question the developers until the Business Analyst is sure that both the business analyst and the developers understand the same thing. And certainly to question him or herself about whether they are making invalid assumptions or including biases in their analysis.
    Also a business analyst needs to be a system thinker. The business analyst needs to keep the whole organization in mind and the entire business process that is being changed in perspective. Product Owners and developers tend to be very focused, the one on the specific changes needed and the other on what is necessary for the next sprint. The BA needs to be able to link all the outcomes of all the sprints and all the backlog items to the overall product being developed and the impact that product has on the entire organization. In systems thinking the accepted rule is that any change anywhere, no matter how seemingly small, has an impact (positive or negative) on some other aspect of the overall system, or the organization.
    These two traits or skills are also necessary for the tester. The tester, especially at the acceptance level is questioning the process and the outcome and the procedures to make sure that they have the requisite quality for the community of people who are going to be using the change. The tester also must evaluate impacts of every change to other systems and processes.
    There is a natural synergy between the business analyst and tester, so natural that many organizations have the business analyst perform testing, or at least write the test cases, at acceptance testing.
    The business analyst must define the real problem the organization needs to have solved. The business analyst is then responsible to make sure that the real problem is solved when the project draws to a close, regardless of how the problem is solved (whether by a Scrum approach, a linear development method, or without the use of software at all). Similarly a tester ultimately wants to make sure that the problem is solved for the organization as well. If there is not a clearly stated problem by the time the product is being tested (the entire product or the outcome of a sprint) the tester should be asking the question, why does the business want this? Then the tester can legitimately perform the tests to ensure the problem is solved in a quality manner.
    In other words there is great similarity between the overall goals of the business analyst and tester. They simply sit on either side of the project – at the beginning and end of software development.
    You can pass on to Sally that I was also a tester back in the day and spent several years on different occasions as a tester only, as well as performing testing as part of my job of developer, and I am basically a business analyst now. Spending time in testing does not dampen or diminish your business analyst skills, but in fact helps them since you tend to write the requirements better – with an eye toward the end game when the requirements need to be tested.

  2. Hi there, I enjoyed your post.

    I have been trying to help a BA who’s on a team figure out where they fit in. They’ve adopted SCRUM at her organization.

    ……….
    In the book “Agile Testing, A Practical Guide for Testers on Agile Teams”, Lisa Crispin and Janet Gregory have the following to say about Agile Testers;

    “Agile testers see each story or theme from the customer’s point of view but also understand technical aspects and limitations related to implementing features. They can help customers and developers achieve a common language.”

    Hmm.. Sounds like how BA’s think to me.
    ……..

    Agile Methodologies employ cross-functional teams, not just developers, though a desire to participate and learn are definitely needed and encouraged.

    The differences between team members’ skills and backgrounds are part of what make these teams so effective. The goal is not to have EXACTLY the same background in the team.

    If you’re interested, here’s a link to my post to try and help this BA out…
    http://mike-caspar.blogspot.com/2012/03/i-am-business-analyst-where-do-i-fit-on.html

    Someone also posted a comment about an Agile Extension to the BABOK. Here is that link…

    http://www.iiba.org/imis15/IIBA/Professional_Development/The_Agile_Extension_of_the_BABOK/IIBA_Website/Professional_Development/Agile_Extension.aspx?hkey=c7942e53-b6fa-479e-a057-03a820596f02

    Perhaps considering Agile Testing as your path might work for some of you. As professional BA’s, you already possess much of the needed mindset and could fit well into an Agile Team.

    Mike Caspar
    CSP, CSM, OA2

  3. Using process of elimination you might be able to determine which step to take. The current general consensus seems to be that the business analyst should move over to Product Owner. Many assume that the Product Owner is just a business analyst with some authority. However, Ken Schwaber, among others, cautions that the Product Owner should not be a business analyst. That is to say that when a business analysts move to Product Owner, they should be prepared to give up their business analyst role. Since that it very hard to do, it might not be a good step.
    The Scrum Master step is a good one for those business analysts who are particularly adept at facilitation and coaching. They will, however, have to leave their analyst skills and tendencies off the dance floor.
    Following the Type B approach can be successful. The business analyst retains her role and contributes to the solution. The problem is that many agile gurus argue against this approach because it segments the team and breaks up the sprint, so a business analyst wishing to dance that step may not find a partner.
    Overall I’d say that the business analyst who wants to retain his business analyst prowess should start stepping over and look around the project and focus on the product being created by the project. Focusing on the product or solution moves the business analyst more to the business side and the business side can use all the business analysis it can get.

    • Your comment was as important as the whole text. Actually, I like most of your comment. Because I found the text somewhat desperate for our area. I agree that the BA should have a broader view and make the intermediate between the sponsor and the development team, because if you just leave them, usually the result is not as positive by many factors. The spread of the BA is to feel the essence of the client, their business and features. Another professional does not have that.

  4. Curtis Michelson says

    Nice article Steve. You lay out the meta-options for BA involvement in agile developments well and you present them pretty equilaterally. I’d be curious to know though which you think hold the most promise going forward. For example, though I’ve done “Step In” many times, I realize now that Stepping Over and Around wins the attention and respect of, let’s face it, those who write the checks. I love having developers as friends and allies, but I need business folks to know my worth, especially as ply the BA trade as a consultant these days.

    So, I wonder what you think the big future trends are going to be in this regard. I sometimes think the highest value of ‘stepping over’ is doing exactly what you did in this article – tell a story and use strong memorable metaphor. Perhaps the answer to complexity and bloat is, simply, good storytelling. To go back to your tribal metaphor, back in the day, there were some folks who could spin a memorable tale around the fire, and there were others who enjoyed those stories. Perhaps if we dig deep into our archetypal BA psyches, we’ll rediscover who we really are. Or maybe I’m full of BS and not BA! Would love to hear your thoughts. Thanks again for the article

  5. Dave Schrenk says

    Great article Steve!

    We have several BAs working on Agile teams although I have yet to experience it myself. I think you’ve hit the nail on the head as far as potential approaches. Initially, several BAs were trained to be Scrum masters for a large project consisting of multiple teams. However, the Scrum approach for that project was scrapped as we struggled to scale Scrum to handle such a large effort. The “Scrum of Scrum” concept was new to us and the communication issues between multiple dependent teams proved overwhelming.

    Anyway, other projects decided to adopt Agile and our BA resources did exactly what you suggest. For the most part, we have used a combination of stepping in (the more technically inclined BAs who, while not actually writing code, have adapted to writing automated testing scripts), stepping around, and stepping into. I think that stepping over component is extremely important regardless of the project methodology. And, for those who might dismiss the stepping into approach, keep in mind that it is valuable when you have a product owner that has other responsibilities and cannot be with the team every minute of the day. In most cases, the product owner might spend 3 to 5 hours per week with the team to identify and prioritize high-level user stories but it is the BA that develops the detailed acceptance criteria for them (with input from the product owner if needed).