“Quite often, getting lost in administrative tasks can take our focus off what should really be our primary driver, which is delivering working software.”
The role of a Business Analyst in software development is a topic often ignored in Agile projects. While I fully support iterative development and embracing change in regard to creating specifications, I acknowledge that the need for business analysis skills is as great as it’s ever been.
I thought I’d share some of my thoughts on the changing role of the business analyst in an Agile environment. Let’s begin with some brief points around what Agile is…
Agile is….
The Agile Manifesto includes the following:
“Working software over comprehensive documentation.”
Agile allows us to question what value the various documentation needs bring to a project. Quite often, getting lost in administrative tasks can take our focus off what should really be our primary driver, which is delivering working software.
Agile is more focused on working software and the business value that it can bring, than on documentation per se. This does not mean that documentation is unimportant or should be ignored in an Agile environment. So while creating large upfront Project Initiation Documents (PID’s) for example might keep you busy, if no-one actually reads them then it’s simply wastage.
Being Agile though is not an excuse to be lazy, but rather a reason to be efficient.
We see requirements in 2 dimensions. Upfront we’ll specify the breadth of the project, enough for us to get an idea of the high level scope. Detailed specifications are not necessary at this point as this will most certainly change. Then, before we start an iteration, we’ll start drilling down into the detail for the current prioritised work.
As you can see, the analysis work will need to align with these iterations, making sure the requirement details are ready just in time for the development team to begin.
Focus on the Agile Principles
Organisations are finding that they need to rapidly respond to changing business needs and at the same time reduce their delivery cycles. As a Business Analyst on an Agile project you need to embrace this.
I’ve seen statistics that state 60% of requirements change in the course of a project. In my experience it’s probably more than this. There is an inherent uncertainty in software development and Agile embraces this.
“You NEVER end with the same specifications as when you started”
We begin to realize that change really is good as it helps us deliver greater value to our customers.
As you can see this is in contrast against typical detailed requirements gathering upfront, which invariably results in wastage, and creates arduous change control processes.
Our goal is to always look for opportunities to remove additional loops in the communication chain; we certainly do not want to add to them.
An example of this is the need for developers to talk directly to Product Owners and the Business Analyst. Not only is there a cost involved in waiting for answers, but more a likelihood for the “broken telephone” experience instead when it comes to what the business actually needs.
We don’t want to see requirements simply being handed over from B.A’s to developers. Agile teams emphasize collaboration and on-going engagements whereas more traditional projects are focused on “phases” that can lead the team to segregate itself along job descriptions.
In an Agile team the B.A. will still be gathering requirements but in iterations. No longer will they have a phase in which they do most of their analysis work, but rather with the team throughout the project. By ensuring on-going collaboration we start removing those single points of failure.
Product Owner vs. Business Analyst
Conflict or Complimentary?
It’s clear that Agile projects still need analysis. The question is do Agile projects need a Business Analyst? Well this depends… A dedicated Product Owner working directly with the development team could be able to fulfill an analysis role. However, in my experience, due to capacity constraints and actual analysis skills this is often not the case. We often need a Business Analyst to directly address this gap and ensure that an iterative Agile process does not have any bottle necks.
The Product Owner must have the authority and responsibility for the development priorities and be accountable to the business for the R.O.I. The Business Analyst would focus on the business process ensuring that prioritised features along with their requirements and dependencies are understood and communicated to all concerned.
In my opinion the B.A. role is less about the title and more about what the project needs. If a dedicated B.A. is able to address existing gaps and assist in getting working software out, then their role on the team is more than justified.
Tasks an Agile BA might do as part of the delivery team:
- Identifying scope
- Detailing the functional design
- Prototyping the user interface
- Creating other artifacts. I.e. Input into value stream maps
- Incorporating user feedback into product evolution
- Facilitate business and developer requirement sessions
- Writing stories, scenarios and acceptance tests
- Getting requirements ready for upcoming iterations
- Learning from the retrospectives along with continuous improvement
The Evolving BA
The BA role is evolving. Traditionally this could be perceived as translating business needs into various requirements and passing it down the pipeline to the development team.
In an Agile world however this could be considered as helping facilitate understanding, whether this generates documentation or not.
Be aware that the B.A. should not become the go-between or “Proxy” Product Owner for the developers. This is regarded as an anti-pattern and goes against face-to-face conversation subsequently introducing yet another communication loop.
The need for business analysis is not going anywhere and therefore important for it to be a part of the delivery team and fully focused on the final goal. B.A.’s who are able to embrace Agile, coupled with their analysis skills are going to be extremely valuable to the team and organisation.
About the Author:
Brent Blake is Projects Director at KRS. As a Scrum Master and driver of Agile at KRS, Brent is the man doing the gemba walk on our software “factory” floor. With 11 years in the software field, he’s seen the direct benefit of agile development. His talents include playing the drums, and delivering software projects on time.