Analysis on Analysts in Agile
Leslie J. Morse, @lesliejdotnet
Antagonizing Analysts
The story is common: the insecurities should be unwarranted, but the agony is reality.
It is easy to make poor assumptions about how to involve business analysts in Agile practices. The Agile Manifesto [1] opens the door for frustration and confusion.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
Phrases like "processes and tools," "comprehensive documentation," and "customer collaboration" are often tightly coupled with the idea of business analysis. As a result, analysts derive much of their professional value from being involved in those activities.
A few of the Principles [2] behind the Agile Manifesto further the debate.
The reaction: Wait... changing requirements is a change request, and that's bad.
The reaction: It takes weeks or months to get on the stakeholder's calendar.
The reaction: They don't speak the same language. That is what a business analyst is for!
The reaction: The 274 pages requirements document is a whole heck of a lot of progress!
Agile reframes the way individuals add value, and the new construct for collaboration creates emotional resistance. Emotional resistance occurs when change disrupts how one derives his/her social capital. Performance systems that reward and incent attributes of a group's social capital exacerbate the magnitude of the resistance.
The Business Analyst culture values:
Figure 1 ties the culture of business analysts to the four aspects of social capital.
This emotional resistance leaves analysts with 3 key concerns:
The good news is that these should not be worries. In fact, the role of a business analyst on an Agile team can be critical to the team's success. This article will explore four topics that shed light on how business analysts fit into Agile teams.
Analysis versus Analysts
It is critical to distinguish between the discipline of Business Analysis versus the role of Business Analyst.
Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies and operations of an organization, and recommend solutions that enable the organization to achieve its goals. [3]
According to that definition, many software development practitioners could acknowledge involvement in business analysis. The International Institute of Business Analysis's definition of business analyst explicitly acknowledges that idea.
A business analyst is any person who performs business analysis activities, no matter what their job title or organizational role may be. Business analysis practitioners include not only people with the job title of business analyst, but may also include business systems analysts, systems analysts, requirements engineers, process analysts, product managers, product owners, enterprise analysts, business architects, management consultants, or any other person who performs the tasks described in the BABOK® Guide, including those who also perform related disciplines such as project management, software development, quality assurance, and interaction design. [3]
The rapid delivery of value requires Agile teams to perform analysis tasks and activities. In a perfect world, the individual playing the role of Product Owner will be deep in business analysis expertise. If that is not reality then the other team members must be competent in business analysis.
Agile is not an excuse to skip over traditional software development activities that figure 2 shows below. Instead, Agile approaches package those activities in a different way.
Adopting Analysis
Making a case for why Agile teams need to employ business analysis techniques is a topic in and of itself. Four approaches prove to be successful for teams that realize the need for business analysis.
Adopting any of these approaches will utilize a plethora of business analysis techniques.
Maintain a State of 'Ready'
Teams with unstable velocity and erratic Complete vs. Commit (CvC) rates may be suffering from a lack of runway or depth within the backlog. Maintaining a set of 'ready' stories in the backlog will decrease swirl within any given sprint. It should also help increase predictability and make prioritization easier. An extra sprint of 'ready' stories will allow the Product Owner to tweak order without disturbing flow.
What does 'ready' mean? It likely includes the following 4 elements:
Encourage teams to build their own Definition of Ready (DoR). Organizations with significant complexity and team interdependency may need to maintain 2 sprint's worth of stories in a 'ready' state.
Establish a Cadence for Refinement
There is a touch of "robbing Peter to pay Paul" that goes into the balance of an Agile team's productivity. Every moment the team spends looking ahead, they have less time to devote to building the working software. However, without doing so the team will never maintain a state of 'ready.'
Building 2 sessions into a team's schedule can establish a cadence for refinement.
Figure 3 suggests a focus for these sessions: using it can help teams maintain a healthy runway within their product backlog.
Proactively Engage Stakeholders
Product Owners act as the single source of truth about what the team should deliver, which means they need to be available, knowledgeable, and empowered. It is a huge morale hit when teams demo working software and the feedback from stakeholders is essentially, "No way - that's not what we wanted."
Such stakeholder feedback leaves the team in a situation where the Product Owner asked for the wrong thing. The inaccuracy could be within the content of the story or the acceptance criteria. You can prevent this situation by developing a strategy for engaging stakeholders to get their input in advance of the sprint.
There are three steps to building a proactive stakeholder engagement strategy:
Grouping stakeholders into 2-3 categories (e.g. Advisors, Supporters, Sponsors [4]), allows the team to establish a patterns for meetings. For example, teams may define a weekly meeting cadence (e.g. Mondays from 10:00 - 11:30am) and rotate which group(s) attend the meeting. A four-week rotation pattern could be:
Discussions should focus on work the team is about to do. The goal is final validation that the intent and acceptance criteria are truly accurate. It is important to include both business and IT stakeholders in these discussions.
Delineate between Work Products and Deliverables
Working software is the primary measure of progress. . That means that all artifacts produced in advance of the working software have the potential to add bloat to the process. Agile teams know that simplicity - the art of maximizing the amount of work not done - is essential. Finding ways to lean the process and documentation is key.
Think of "deliverables" as the final artifacts the team produces, the highest priority of them being the actual working software. Rarely are teams afforded the luxury of only needing to produce working software: training, production support, and governance groups typically need more than the software alone. Consider any supplemental documents a "deliverable" or long-term artifact.
Organizations try to use requirements documents, specifications, and technical design documents as long-lasting artifacts. The challenge is that those documents are always produced before writing the software. This results in situation where the software works in a different way; hence, why people often look at the code to know how something is supposed to work.
Think of traditional artifacts (requirements, specs, designs) as "work products". These short-term artifacts only exist for the purpose of building the right deliverables. In an Agile world work products should capture the bare minimum the team needs and should exist as a result of collaboration (not a replacement for collaboration). User stories, scenarios, acceptance tests, diagrams, prototypes and models are the techniques often used.
In most cases, "deliverables" should be standard from team-to-team. (Hint: Capture the need for deliverables as part of a team's Definition of Done.) "Work products", on the other hand, should be flexible and as simple as the teams choose. The goal is to clearly delineate between work products and deliverables. Allowing flexibility around the detail captured in "work products" enables teams to be creative and apply a wide variety of analysis approaches. Delineating work products and deliverables also opens the door for redefining what deliverables should look like: if traditional work-products don't meet the needs of down-stream constituents, then what will?
Analyst Actions
There are countless ways for someone with a title like 'Business Analyst' to engage with Agile teams. Individuals with jobs focused on analysis are often rich with facilitation and negotiation skills, which are critical to navigating through naturally occurring team conflicts. They are also quite often adept at systems thinking and problem solving. What Agile team doesn't need that expertise? Finally, BAs often have a wide network of relationships within the organization, and they may hold the key to resolving an impediment or getting clarity on a situation. It's important to play to these strengths when guiding Analysts to operate within an Agile environment.
Analysts may engage in the following ways:
Analysts are often the knowledge and glue that can make a set of disparate team members gel. Think of all of the knowledge and information about a product the team is building as the crystals at the end of a kaleidoscope: analysts are the ones equipped to turn the kaleidoscope just the right way (by using the right analysis technique). The right techniques at the right time can reveal the piece of information needed to make the right decision and move forward.
Appreciation and Approach
Fantastic thought leaders and subject matter experts are defining Agile analysis approaches. These approaches are paving the way for analysts in organizations adopting Agile practices. If you're looking to learn more turn to the following references and resources:
A final recommendation for applying analysis techniques to Agile: consider leveraging user stories to determine what deliverables a team should produce. Examples include:
These stories, partnered with acceptance criteria, will ensure deliverables are tailored to meet the need of the groups requesting them.
Business Analysts have much to offer in Agile environments. Honor the value they add to Agile teams.
|
Build Useful Solutions that Inherently address the Needs of users... By Embracing the Spirit of Agile's Simplicity and being... |
Awesome at Nailing it down All while Looking for ways to increase Your productivity and Still maintain True balance [5] |
References
[1] http://www.agilemanifesto.org/
[2] http://www.agilemanifesto.org/principles.html
[3] A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0
[4] http://www.davisbase.com/proactive-stakeholder-engagement (not available anymore)
[5] BA/SA/BSA: What do you call yourself? Technology-Enabled Business Solutions 4/3/2013 blog.fusionalliance.com (Attribution only applicable to the "ANALYST" portion of the mental model)
More articles on software requirements and specifications
Non-Functional Requirements: Do User Stories Really Help?
Something Old, Something New: Requirements and Specifications
Click here to view the complete list of archived articles
This article was originally published in the Winter 2014 issue of Methods & Tools