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.

• We're Agile now; we don't do requirements
• Agile teams don't need documentation
• There are only 2 roles on Agile teams: Customer and Developer
• Right-sized teams don't have space for Business Analysts

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.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

The reaction: Wait... changing requirements is a change request, and that's bad.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

The reaction: It takes weeks or months to get on the stakeholder's calendar.

• Business people and developers must work together daily throughout the project.

The reaction: They don't speak the same language. That is what a business analyst is for!

• Working software is the primary measure of progress.

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:

• Relationships (often the ownership of the relationship "with the business")
• Subject Matter Expertise (both business and functional)
• Facilitation skills
• Communication and Presentation skills

Figure 1 ties the culture of business analysts to the four aspects of social capital.

This emotional resistance leaves analysts with 3 key concerns:

1. Job Security - Do I still have a job?
2. Documentation - That is how I produce my work; we need this. What will we do?
3. Time - How will it be possible to get all this analysis done so fast?

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.

1. Analysis versus Analysts - The difference in the 'discipline' of Business Analysis versus the 'role' of Business Analysts.
2. Adopting Analysis - Key techniques and mental models for how the discipline is leveraged within Agile teams.
3. Analyst Actions - Specific recommendations for the way the role functions within an Agile team.
4. Appreciation & Acknowledgement - A tip of the hat to key thought leaders that are leading the way in the application of analysis in Agile.

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.

1. Maintain a State of 'Ready'
2. Establish a Cadence for Refinement
3. Proactively Engage Stakeholders
4. Delineate between Work Products and Deliverables

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:

• Shared Understanding - Everyone on the team can paraphrase the intent and approach for the backlog item. (Be sure to include both development and testing aspects of the work.)
• Know Enough - Team members have enough knowledge about the story to plan tasks. (i.e. If they took the item to Sprint Planning tomorrow, they already have a solid idea of what those tasks should be).
• Sized Appropriately - The team has triangulated the story's size with known factors, and verified the accuracy of the points assigned.
• Dependencies Fulfilled - Required incoming dependencies associated with the backlog item are complete.

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.

1. Story Review Sessions. These are brief 15-30 minutes sessions held during the first half of the iteration (perhaps on day 4 of 10). The intent of the session is to look at backlog items planned for the next iteration to ensure they are 'ready'. Holding this session early in the iteration allows the team time to resolve any open issues and proactively manage expectations.
2. Story Refinement Sessions. These are 2-4 hours sessions held once (maybe twice) during each sprint. If these sessions run shorter than 2 hours, the team barely get started before it is time to finish; longer than 4 hours, the team can run into analysis paralysis. During this time, the team collaborates on the detailed approach for delivery.

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:

• Step 1: Analyze Stakeholders - Who are they, and how close are they to the work?
• Step 2: Define the Cadence - How often should you meet?
• Step 3: Follow-Through - Keep the discipline for the sessions [4]

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:

• Week 1 - Advisors
• Week 2 - Advisors & Supporters
• Week 3 - Advisors
• Week 4 - Advisors, Supporters & Sponsors

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:

• Act as a proxy Product Owner
• Engage stakeholders, aggregate opinions, present options
• Collaborate on authoring acceptance & functional tests
• Execute tests
• Facilitate refinement and story review sessions
• Assess backlog depth
• Conduct impact analysis
• Experiment with different analysis techniques to find those that resonate with the team
• Embrace the role of "Team Member" and take on any tasks necessary for the team to be successful

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:

• Book: Discover to Deliver by Ellen Gottesdiener & Mary Gorman
• Book: Impact Mapping by Gojko Adzic
• PDF: Agile Extension to the BABOK® Guide from IIBA®
• YouTube Video: Unleashing the Power of Behavior Driven Development (BDD) by Jeffrey Davidson: https://www.youtube.com/watch?v=FL9OhjO9U2k
• Blog: The IT Risk Manager (https://theitriskmanager.com/) by Chris Matts

A final recommendation for applying analysis techniques to Agile: consider leveraging user stories to determine what deliverables a team should produce. Examples include:

• As a new team member, I need a guide that summarizes how our systems work, so that I can get up to speed and start adding value quickly.
• As a support analyst, I need an operations guide, so that I can triage defects and determine the severity of incidents.

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

Agile Requirements

---

Click here to view the complete list of archived articles

This article was originally published in the Winter 2014 issue of Methods & Tools