How Agile is Influencing the Traditional Business Analyst Role Part 2

March 2nd, 2010 By Ellen Gottesdiener

In my earlier post, How Agile is Influencing the Traditional Business Analyst Role: Part 1, I provided the first set of answers to questions posed to me by a Modern Analyst writer preparing a article on how Agile is impacting the traditional business analyst (BA) role.

Here I continue with the questions and my responses.

What are your thoughts? Do you agree?

In Scrum, do you think a Business Analyst could (or should) be the Product Owner, ScrumMaster, or a regular team member?

Yes, maybe, yes, maybe, yes maybe.

In Scrum, we have the product owner “role.” The PO is perhaps the most important (and burdened) role. The PO must conduct a mix of strategic and tactical activities.

Strategic activities are business or market facing—for example, analyzing the market and business case, defining the product vision and roadmap, developing requirements, adjusting the product backlog, and determining delivery plans.

Tactical activities are delivery team facing—for example, specifying the items to be delivered in each iteration, determining acceptance criteria for them, analyzing dependencies between items, and making tough decisions about what will be built to satisfy a given business need, technical risk, and requirements dependencies. Some great business analysts I’ve worked with pitch in to build and run user acceptance tests.

All this takes a lot of knowledge and many skills, and it consumes a lot of time.

On top of that, to fulfill both strategic and tactical activities on an agile project, the business customer needs experience in product development, along with deep domain and product knowledge.

I’ve coached (and trained) teams working on large, complex products, and I’ve seldom known a single business customer who can do these strategic and tactical activities.

That’s why many organizations turn to talented business analysts for help with the day-to-day, tactical decision making on their agile projects. In other cases, someone who was formerly a traditional business analyst will work out the backlog items, suggest the priorities, and then obtain validation from the business PO.

In an ideal Agile setting, is there even a need for someone with Business Analyst skills, or would the team simply talk to the customers directly? If a Business Analyst would still be useful, what tasks do you think they would be valuable in performing within an Agile team? If not, is the Business Analyst role threatened by Agile?

If the team has people with analysis skills, those people are talking with the customer directly. Some teams have one such person, and others have those skills embodied in more than one person.

To learn more about tasks that are valuable within an agile team, please refer to my list of specific activities, mapped to activities on traditional projects, here.

You have to be at the top of your game to be a contributing agile team member. It is not an “either-or” situation. All the business analysts I know who transition from traditional to agile can’t imagine going back to traditional waterfall practices after being on an agile team.

As Agile/Scrum principles and practices transition beyond software development and into the organization’s general operations, do you believe Business Analysts who have been involved in Agile projects can assist the organization in its transformation? If so, how?

Often business analysts have excellent facilitation skills, along with experience in organizational transformation from their project work. After all, when we implement software or complex systems, we are changing what people do. people who deeply understand organizational change, business analysts are important for successful business transformation.

For a team transforming to agile, the most sensible approach is to use agile practices while also honoring well-established and validated organizational change models.

I have specific suggestions for easing the transition to agile. Business analysts offer important skills in this process. In the end, however, it is the responsibility of the entire team and the management to make the transformation successful.

What should a “traditional” BA do to prepare to join an Agile team/project?

Well, certainly reading this article helps! 😉

Open your mind. Be ready to relinquish control of the requirements. Relax the need to be a “template zombie.” Learn more about user acceptance testing and user experience and interaction design. Sharpen your facilitation skills. Learn how to do agile estimating and planning. Find out why requirements-driven planning is necessary for product roadmapping and release planning. Learn how to question, lighten, and refactor documentation. Become a reviewer for the soon-to-launch effort to add an agile addendum to the BABOK. Ask to be on an agile team, and observe (with permission) stand-ups and retrospectives. Read a lot. Attend agile conferences. Begin to adapt agile requirements practices, in small ways, on your current projects.

Do you have any other thoughts on Business Analysts and Agile and/or Scrum?

I might say a few words about the attitudes and outlook that business analysts are smart to bring to an agile project. Agile analysts need to be dedicated to delivering business value and building the customer’s desired product as quickly as possible. As members of an agile team, analysts need to be less focused on roles and job boundaries, and more focused on delivering customer value as a team. They need to thrive on criticism and appreciate the importance of small, continual improvements. They’ll be happiest if they have a strong need to expand their skills and abilities, operate in a transparent way, reflect on their process, and serve the team and customer.

Resources

Product Agility

A blog about agile product discovery and delivery,
collaboration, and continual improvement