Erin McManus and Ryan McKergow presented is there a future for business analysis? at 1st Conference (a conference for those new to agile) in which they talked about the role of business analysis when organizations adopt agile. InfoQ interviewed them about the need for business analysis, how agile impacts the role of the business analyst, the changes that they have seen in business analysis when agile is being adopted, and asked them for specific business analysis practices that that they can recommend for agile teams.
InfoQ: Do you think that there’s still a need for business analysis when organizations adopt agile?
McKergow: I do. I believe that business analysis is still really important for agile software development. Business analysis means critically thinking and challenging what value that we are delivering. What problem are we trying to solve? Why are we developing software as the solution?
It also includes understanding complexities of organizations like government regulatory changes, company policies, industry standards, business processes, the list keeps going. Just because we approach our work differently in agile compared to more traditional methods, doesn’t mean we forget about these questions and areas of consideration.
McManus: Absolutely, I think what Ryan and I are saying is that the way we think about software has evolved over time, therefore the roles within software development teams also need to evolve. Especially with the adoption of agile, we really need to think about what the roles can do in the future. So I definitely think there is a need for business analysis in organizations adopting agile.
InfoQ: How does agile impact the role of the business analyst?
McKergow: Like every other role in software development, agile has challenged the value that the role delivers and asks: "Do we need a specialist for this role?" This is why agile encourages cross-functional teams. We have all the skillsets within the team that are needed to develop software, but we don’t necessarily need specific people being a pure specialist (and nothing else) within a team. So it challenges do we need a pure business analyst? Do we need a pure tester? These are two examples. There are many more.
InfoQ: Can you give some examples of the changes that you have seen in business analysis when agile is being adopted
McManus: Agile has increased the collaboration within teams and one example of where business analysis has changed due to the adoption of agile, is having the tools to create a shared language. We’ve seen this in the adoption of Behaviour Driven Development (BDD). Business analysts are writing their acceptance criteria using the BDD format of Given, When, Then. Writing out scenarios like this, can take complex functionality and clearly communicate how it’s meant to work in language that non-technical people can understand.
We’ve also seen a change in the timing and amount of analysis being completed. There is more of a lean manufacturing "just in time" approach to analysis. Only doing what is needed, when it’s needed. This ensures there is no waste in the analysis process.
McKergow: From my perspective, I think there’s been a shift from the traditional business analyst to moving towards a T-shaped analyst. You may have a specialisation in analysis, but your skillset should be broadening in agile.
McManus: I agree! There’s a LOT more collaboration all the way through the development process. I’ve seen business analyst’s playing the role of tester, so they can ensure that the development team has taken into account all the requirements the feature needed, or as a proxy product owner to sign-off the feature as a business representative. There’s more scope to take on different responsibilities in an agile team. It’s no longer "that’s not my job", we’re challenging that, if you can do it, why not just do it? We shouldn’t need specialist roles for tasks that don’t require a special knowledge.
McKergow: I’ve been playing the role of a tester quite a bit recently. Predominately doing manual exploratory testing, but it’s been an interesting learning experience to consider the flow of data between systems. This involved ensuring that if you’re updating data in system, it is updated in the corresponding system! It’s also been good to refresh my SQL skills. I find that the ability to query databases is a useful skill for analysis too. Particularly with quantitative analysis about how many users are using specific functionality.
McManus: Which leads me into some of the other T-shaped skills. Great business analysts are now more aware of the customer and their journey with the software. They’re interested in understanding not only why the business want the product built, but what the problem is that the product is trying to solve and how their customers will use it.
The business analyst is also in a fantastic position to influence team dynamics. They’re working closely with the product owner, working closely with the development team, being able to drive consensus on decisions that are being made is a great way to ensure that the whole team feels they have ownership of the product. This also helps establish a shared goal that the whole team can work towards.
So you can see, there’s heaps of different paths a business analyst can take to be T-shaped and provide further value to their teams.
InfoQ: What if an agile team wants to do analysis themselves, instead of having it done by a business analyst?
McKergow: If a team wants to do analysis by themselves, then that’s great. There shouldn’t be anything stopping them. There can be some really exciting things that business analysts do that they can try. But they also need to remember that the absence of a Business Analyst is not an excuse for avoiding the more detailed analysis work. Examples could be researching a regulation or policy if required, or understanding some of the complex business processes. Someone has to pick up these responsibilities too.
McManus: I’ve worked in a couple innovation teams where we had no specific business analyst. At the time it didn’t feel unnatural at all, it was very much a collaboration over documentation type scenario. The developers would interview the customers themselves and develop the solutions. In that kind of fast-tracked - build, measure, learn - innovation environment, a specialist business analyst was just not needed.
InfoQ: Any specific business analysis practices that that you can recommend for agile teams?
McKergow: There are a number of techniques that anyone within the team can use. Here are some of my favourites:
- 3 Amigos from ATDD - Instead of a business analyst include the product owner. Have a conversation between your developers, testers, and product owner about what you plan to develop. Even get into the nitty, gritty detail about the acceptance criteria of each Story. It’s about increasing collaboration between the three different perspectives. You can refer to another InfoQ interview with originator of 3 Amigos: George Dinwiddie on the three amigos.
- Story kickoffs - Similar to the 3 Amigos above, but specifically when starting development on a Story, get everyone together to discuss what this story is going to deliver, think about how to technically implement it, and anything to watch out for. I wrote about this technique on our company site: How to introduce Story Kickoffs to your team.
- Design studio - This is a technique that I’ve been using recently to get the team to collaboratively design the product together. The team can literally draw wireframes of how they understand the problem, and bounce different ideas off each other from the different designs, and converge on a finalised design. Jason Furnell has a really comprehensive on this process: Facilitating Collaborative Design Workshops.
If you’re in this situation, why not give these techniques a go? You too can broaden your skillset and deliver even more value to your team.