Inventory Your Agile Analysis Skills Toolbox-EN
Jacqueline Sanders-Blackman
- Business Agility
- Article
First thing first, let’s establish two truths to analysis in agile:
One: we all know that some level of analysis happens on agile projects and that your team needs a well-developed agile analysis skills toolbox. It starts at the Product Visioning phase and continues throughout Iteration 0, Road Mapping, Release Mapping, Iteration Planning, during User Story elaboration, and throughout the design/build and test. (For more on this truth of the role analysis plays in an agile environment, see our instructor Ali’s blog post: Just Enough Doesn’t Mean None! The Agile Business Analyst Role.)
Two: we also know that there are different ways to assign who does the analysis. The analysis responsibilities could be:
- Spread among all or some of the team members
- Assigned to a dedicated and experienced analyst that is part of the team
- Performed by an adviser or coach in the analysis role, as needed
If you choose to have team members involved in analysis, the individuals without strong analysis skills will need to be cross-trained. Deciding whether or not analysis is a team effort should be based on the complexity, uncertainty, risk and impact of the project and solution. Spreading responsibilities, requires team members to clearly establishing accountability and to be open with each other regarding their aptitude as it relates to analysis. Even with a dedicated analyst, some portion of the analysis effort will ultimately be shared by the team.
So how do we inventory whether or not our teams have an adequate agile analysis skills toolbox and are prepared to perform analysis at the appropriate level?
At first, many teams believe they have these analysis skills covered and don’t realize their mistake until problems begin to surface. It’s hard to be prepared for analysis if you don’t really understanding the breadth of analytical activities needed for project success; such as elicitation, research, deep dive, dissecting, reconciling, cross-referencing, and many others.
Agile teams need to take a proactive approach to evaluate their members from an analytical perspective. The first step is to look at the range of skills and determine levels of proficiency. We’ve compiled a list of analytical tasks and techniques to evaluate your team’s agile analysis skills toolbox. Check out our Business Analysis Proficiency Assessment. Whether you’re at the beginning of your agile implementation or well into it, take this quick assessment to see if your agile teams have covered the key areas of analysis proficiency. The results will help you easily identify an analysis red flag.
The agile environment embraces a concept of failing fast, but there are red flags that keep you from failing often, failing unnecessarily, failing to the point of not being able to recover, and/or not knowing how to recover when you fail. A team member that has a wide range of analytical experience help you foresee impacts and repercussions to avoid when declaring a story ready or done prematurely, an action which can repeatedly impact the sprint and the team velocity negatively. What you DON’T want to do is WAIT until the impact of your failing fast accumulates to the point of jeopardy for the project.
Let me share a prime example of how engaging a business analyst on my agile team kept our project from failing:
Take product owner Shelly, a veteran claims agent for an insurance company, who was assigned to be the SME/Business Representative on our Agile project team. She had 20 years of experience, as far as knowing the business. She was perfect for her role. She was priceless as we defined the problems and issues, she knew the As-Is process, roles, policies and pain points.
However, as the team started to define the new user interface, she started to get stumped. She wasn’t all that familiar with the greatest and latest options in software solutions. She often was stuck in As-Is thinking and was justifying doing things the same because that’s the way they’ve always done things. On the other hand the designers/developers were great at giving her options, lots of options. She was getting overwhelmed. At this point, the project was stalled, decisions were not being made, and the current and future sprints were at risk.
A Business Analyst who was trained at facilitation, negotiation and decision making techniques, was brought in to help expedite and avoid the bottleneck as tensions started to rise. Through the use of some quick analysis techniques, decisions were made and the sprints moved forward.
Shelly welcomed suggestions, coaching and guidance from the seasoned Business Analyst on the project. Together they determined additional stakeholders and when to engage them. They used a few techniques know well to the Business Analyst, which kept the elicitation, the analysis and the documentation very informal and lightweight. With the Business Analyst on board, Shelly was able to focus on content.
She welcome the insight of the BA as he utilized different elicitation and analysis techniques based on each unique situation. Shelly and the BA sometimes worked on the same user stories. Some stories Shelly was able to address in conversations directly with the designers and development, which freed up the BA to do a deep dive on big stories such as epics or stories that required some research. Every story and every day was different so the BA had to be nimble and quick to facilitate and advise on matters related to the requirements or the big picture.
As a second benefit, the whole team was crossed trained (in the spirit of Scrum). As a result, the Developer/Designers became better at elicitation as well. In this instance, a seasoned Business Analyst was very much needed for some of the complexities. And even with failing fast, the BA was able to recover and salvage any negative impact to the sprint or velocity. The project was successful.
With an analyst on the team, product owners are able to contribute and focus on their project contribution based on their expertise while the analyst augments and reinforces the reconciliation of data, information, requirements, features and functions based on tried and true practices in the business analysis profession. For more on the role of the product owner and the business analyst on an agile team, check out The Yin and Yang of the Business Analyst and Product Owner Roles.
Being proactive in assessing the strength of your team’s agile analysis skills toolbox will highlight the gaps so you can have a plan to address. Take our Business Analysis Proficiency Assessment to your next retrospect. Using the list of analysis skills in our worksheet, have your team members rank themselves on a scale of 1-5. If you have gaps, discuss how to address those gaps as a team. Determine the most appropriate solution for your team: training, coaching, or mentoring. Talk about how to assess and recognize when a team approach is good practice and when a project might warrant a seasoned analyst to help augment the team. Whatever you decide, decide as a team.
If your team struggles with this assessment exercise, we’d be happy to help. Netmind can provide a recommendation and/or can perform an independent review of your team’s gaps and pain points to be addressed by training or coaching.
Someone that has specialized in business analysis as a profession will surely bring certain guidance, direction, strategic oversight to the agile team as to how, when and what techniques to rely on in the various scenarios that arise during the SDLC. In fact, having a team member with sharp business analysis skills will only solidify a high performing agile team due to the accelerated tempo of work on an agile project.
Thank you,
Jacqueline
Sobre el autor
