I love Agile and Scrum. Several years ago when I was introduced the concept as a project manager and lead analyst, I was intrigued and thought to myself, "There really is a better way!" Now, having had the chance to set up a team, and demonstrate those principals and learn from that experience, I've also swapped notes with other colleagues regarding their experiences. There are so many varieties of how we are able to establish an Agile/Scrum team. Why? Because we are trying to make these concepts work as best we can within the constraints of a specific organization. How that organization operates and establishes the foundation for an Agile culture really drives how true we are to the textbook approach. I believe these variations are approaching a valid instantiation of Agile/Scrum because the organization is deriving value by subscribing to the mindset. Below I share my thoughts on comparisons of these different variations and specifically how the Analyst role takes shape within these teams.
We all know that not all implementations of Agile/Scrum happen the same way. Call it "Iterative Development using Scrum", or maybe "ScrumFall" or even "Agyle with a Y", each organization will adapt the concepts of this methodology and mindset to their own culture. My observations lead me to categorize the three major trends in the way the Analyst role manifests itself on these types of projects. This expression of the Analyst role has to do with the organization's support not just of Agile/Scrum but also the value it places on the Analyst role within any software development process.
1) The Business Analyst role does not exist.
The hardest scenario for me to accept is where the Analyst role doesn't exist. There is specifically a Product Owner, and maybe loosely defined at best. The development team really performs the analysis as they look at each story given to them. This set-up works when the development team is very strong and understands a lot about the business and the objectives of each story. It easily fails when the product owner is detached and provides little to no feedback on what functionality is being implemented. The developers determine their own acceptance criteria for each story in order to drive the work to completion. They also have to be courageous enough to ask all the right questions in order to be successful. Too many assumptions and not enough questions can lead to a team's repeat failure. A reoccurring problem with this setup may also include repeat defects that evolve and never seem to go away.
2) The Business Analyst is the Product Owner.
When a Product Owner is incredibly committed to the success of the product itself, they are also performing some analysis on the needs and demands of how that product should adapt and where the most value will be delivered with new functionality. In this case, the Product Owner may have gone through Certified Scrum Product Owner (CSPO) training and is aware of software development practices overall. Primarily, these folks are true business people and really understand the dynamics of their industry. They are constantly writing the stories the team will work on and are dedicated to the development team's success. Some teams may have problems where the Product Owner's lack of bandwidth starts to limit how many stories can be prepared in time for a sprint. This issue is solved by producing those stories about two sprints in advance, which also allows them to prioritize the stories they are writing separately from what is prioritized for the development team's next sprint. With the Product Owner acting as the single analyst for the team, the problems may take form in the place of not having enough testing take place before demonstration. If there are QA resources on the team, the difficulty of communicating and transferring the knowledge to fully test a story before the demonstration to the Product Owner may also show up from time to time. Some stories may go into a second sprint or be put back on the shelf because some of the nuances of the functionality may not have been specifically detailed in the acceptance criteria. This is where the QA role (and communication between QA and PO) becomes critical since the development staff isn't usually thinking about different ways to break their code.
3) The Business Analyst is also the Quality Analyst.
I think this is my favorite Agile/Scrum team set-up for an Analyst that I've found thus far. In this third scenario, Analysts are able to focus on three tasks. Analysts will work on the stories for upcoming sprints, based on the priorities set by the Product Owner. Analysts should assist the development team by asking and answering questions and being the liaison role between the development team and Product Owner. Finally, the Analyst tests the functionality built in the current sprint and helps drive the development resources to being done in time by the end of the sprint.
The Product Owner and Scrum Master are providing support to the team overall. The development resources have the support of the Analysts that are specifically working with the Product Owner to develop the story and all the acceptance criteria. They are the gatekeepers of the minimal yet valuable documentation. Analysts are also able to perform more ad-hoc testing outside of the documented acceptance criteria and help deliver a more robust piece of functionality. Teams will see greater success in this set-up when demonstration day comes and the Product Owner reviews what is delivered for the sprint. The unique thing about this set up is that it also caters to a very busy Product Owner. The Analyst role can be the eyes and ears for the Product Owner and will work closely with them. There is a concern here that the Product Owner may see this as a reduced commitment to the team. This shouldn't be the case! With the time available, the Product Owner can work with those in the organization, and outside of the Agile/Scrum team to shape the vision of the product itself. The Product Owner should have an equal amount of commitment to the team and should still be available to team on an everyday basis. The Product Owner must provide enough time to the team to answer the questions, but more focused time may be spent with the Analyst to convey direction and vision on the stories in development and confirm the acceptance criteria without having to spend the time to create that valuable documentation. That's the Analyst's job.
All of these scenarios can work to take advantage of Agile/Scrum development, but I think there are different issues and varying degrees of success that come about with each. Hopefully one day, I can collect data and run a more scientific analysis of how these different variants of Agile/Scrum are really working.