Are Business Analysts Obsolete in an Agile World?
Since the Business Analyst title (like many others) does not exist in most Agile or Scrum teams, does that mean that the Business Analysis skills are not needed? Our experts all indicated that having people with strong Business Analysts skills is still extremely essential to the success of a team or project. The removal of titles isn’t meant to indicate the devaluation those individuals, but rather to have people see beyond designations, credentials and classifications and focus on utilizing each person’s unique abilities and qualities to reach the goals of the team.
As Gottesdiener notes, “in some teams, analysis skills are shared among team members. That is more common in small teams working on small projects, when team members have rich business domain expertise or when there is an ‘uber’ Product Owner who has loads of skills to do the business analysis, and requirements skills for connecting multiple teams together to deliver the product.”
Most Agile teams are grateful to have people with deep business analysis talent, particularly those with fine-tuned facilitation skills, agile modeling skills, the drive to reduce waste (including unneeded documentation), and the ability to get requirements ready for upcoming iterations. Gottesdiener states that “Agile teams definitely need the skills and disciplines of business analysis. It varies from team to team whether those skills are embodied in a delivery team member, the customer, or a combination of people.
As a result you may find ‘Developers’ who help with writing user stories or interacting with customers, ‘Business Analysts’ who assist with designing a great user interface, or ‘Project Managers’ who will come up with acceptance criteria for test cases.
Cockburn notes that “the early attempts at Agile development tried to do away with the Business Analyst” because of the potential distortion of communication with a go-between. However, given the complexity of organizations, the disparate business languages that various units may use and the time constraints of subject matter experts, “more recent variations are finding good use for someone with deep business knowledge, who has time to spend talking with the programmers.”
Ambler states “it's still critical that analysis occur on an agile project, in fact it's so important we do it every single day of the project. BUT, that doesn't imply that agile teams need someone in the specific role of Business Analysis solely doing that sort of work.”
Schwaber believes that “every Scrum team needs people who understand the business domain. I would expect them to help everyone understand what is needed from a business point of view, to document these requirements as acceptance tests, to help the Product Owner groom and maintain the product backlog, and to work with the whole team all of the time.” Business Analysts with a deep knowledge of the business or market that the team is serving become essential to a team’s success.
Furthermore, the actual management of artifacts and requirements is still extremely important. Nee indicates that “an Agile setting does not eliminate the need for good quality requirements development. There is still a need for facilitation of requirements gathering sessions, analysis of requirements, elicitation of requirements, and the applicability of those requirements to the solution.”
While an Agile environment may introduce different tools, processes and even principles to a Business Analyst, the individual skills of that person can help them succeed in this new environment. Kohl mentions how a master welder can do anything with a gas welder. If the welder moves to a different shop in a different industry using different processes and a different tool, they can still provide value to the organization once he or she “learns how to use a new tool, and learn the new processes and procedures.”
While a Business Analyst may not carry a title in an Agile setting, they are still a valuable contributor to the team’s success. Ambler notes that “anyone transitioning from traditional to Agile must expect to make some changes. Whether they're threatened by that is up to the individual.”
Preparing to Join an Agile Team
Business Analysts who are about to embark on their first Agile experience may feel a little trepidation. Our experts indicated that the best way someone can prepare for it is to view the chance as an opportunity to learn. Ambler indicates that Business Analysts need “an open mind, be willing to learn new skills and to transfer your existing skills.”
Cockburn has 3 tricks for Business Analysts to get started on an Agile team:
-
“Learn to slice business requests into smaller requests that can be developed and delivered in smaller time units, and built up to create fully interesting business initiatives.
-
Learn to connect the development team more closely to the ultimate sources of business needs (often the business executives, the clients, or the system users on the client premises); and learn to connect the non-programmer people inside the business more closely to the clients of the business.
-
Learn to involve the clients directly in the development of the business itself, helping to frame the initiatives of the business so that the clients eventually co-steer those initiatives, even though those initiatives would look, in old parlance, as "internal" initiatives.”
Gottesdiener also has some helpful suggestions: “Open your mind. Be ready to relinquish control of the requirements. Relax the need to be a 'template zombie'. ”Analysts who are “less focused on roles and job boundaries, and more focused on delivering customer value as a team” will thrive in an Agile environment.
Schwaber believes that the best way to get started in Agile is simple: “join”. Kohl also encourages on the job training. Once someone has learned the basics you should “take on a Scrum Master role and see what you think. I encourage experimentation. I work with a lot of teams, and they all look different, yet they are able to create value.”
Taking Agile out into the Organization
Business Analysts who become adept at Agile techniques and methods can help those inside and outside the organization understand how Agile can be leveraged. People who are only indirectly involved in Agile project may not understand the benefits of an Agile process. In particular, highly structured organizations with rigorous Project Management processes people may find an Agile approach haphazard and risky.
Schwaber indicates that “by joining Product Marketing and the customer organization, or by being a Scrum Master, the [Business Analyst can be a] pivot point for change.” Business Analysts can become a spokesperson and educate others in the goals, processes and benefits of Agile.
Pichler indicates that it is “the ScrumMaster’s job is to help Scrum be established in the organization, together with management.” However, at times the ScrumMaster’s ‘official’ title may not be considered ‘high level’ and as a result a Business Analyst may have more opportunities to communicate Agile within the organization.
Kohl cautions taking Agile beyond its aims within software development. Agile principles have been around in some shape or form for several decades and Managers may take issue with this ‘revolutionary’ concept. “There have been many similar movements in the business world that have had varying levels of success. Agile management sounds suspiciously like Total Quality Management repackaged.” Gottesdiener also notes how Agile is becoming part of the mainstream and a standard for software development. She notes that “people aren’t arguing very much about Agile. Most of the theoretical issues are settled. Now we’re focused on how to implement agile practices.”