More than a decade ago, when I started as a Business Analyst on my first agile project, I was not sure of what is expected from me. I had done analysis in a waterfall setup but I had no clue of analysis in an agile setup. One of my mentors, at that time, offered a definition of the role of business analyst and I am still exploring the depth of that definition. He said, "In an Agile setup, there is tremendous amount of churn between the customer, developers and quality analysts. The role of a Business Analyst is to manage the churn". Even today, whenever I get into analysis and story writing, I still think about this definition and learn few more things.
Over the last decade or so I had opportunities to interact and work with a number of clients who had embarked on the agile journey but the project(s) were not delivering the desired results. Some of the common complaints were
- We have completed development and are having some last minute testing
- Even though the developers complete the iteration's development in time, the customer takes a long time to accept the stories
- The developers are not able to keep pace with the changes that customer needs
In almost all these projects, analysis has been one of the weak links. The problems with analysis seldom show up within the analysis process. In most of the cases the symptoms of the problem are visible much later in the cycle, sometimes even post production.
I have had multiple attempts at generalising the solutions that have worked for me as a business analyst in the above mentioned scenarios but every such attempt of mine has failed. Hence, I believe that there are no rules for getting the analysis right esp. in an agile setup. It is an art that the practitioner needs to master. Thinking about analysis in terms of steps, rules, check lists etc, the takes us farther from getting better at analysis.
Having said that, based on my experience, I believe that the following set of behaviours can help in mastering the art of analysis and more so in an agile setup
1. Customer's best friend: The first and the most talked about responsibility of a business analyst is to be the proxy for the customer. In order to achieve this, the business analyst needs to be the best friend of the customer and understand the customer well. The business analyst should see his/her success and failure to be same as customer's success and failure. With this deep understanding and empathy with the customer, analysis and writing stories is simpler.
An example that definitely comes to my mind is when we were building a CRM solution for an investment bank. We were not only able to course correct some of the features but were also able to add new features and drop existing ones because we were focused on helping the business achieve its goal. It was not as easy because every time we wanted to drop a feature, there were emotional reactions from the users/sponsors who had proposed the feature.
This also goes a long way in earning the respect and trust of the team as the business analyst becomes the real proxy and can make decisions rather than acting as a conduit between the team and the customer.
Something that a business analyst should always remember "A true friend is not the one who is always in agreement".
2. Story Teller: The skill of writing stories is much talked about. In my opinion, a business analyst need to be a good story teller. It is not from the perspective of writing stories, but it is the ability to create appropriate interesting stories and narrate it to both the customer and the team. These stories help achieve two goals. First, collate your past experience and apply it to present customer's business context to evolve the best possible solution. Such stories go a long way in creating positivity around the proposed changes. Second, to help the team understand the business and its goals. A session to talk about business may not interest the team and there will be limited retention of the information shared during the session. Story telling is much more effective method of dissipating the business knowledge in the team.
When I was part of a team building an online store, I used to tell a lot of stories to the customer extracting my experience of being part of teams creating digital jukeboxes, trading solution for stock exchanges and financial systems. It was very easy for the customer to relate to these stories and appreciate the alternate point of view.
Similarly, as part of the team that was creating digital jukeboxes, we used to narrate a lot of stories around jukebox industry and the music industry and how the customer is trying to differentiate. These stories were narrated on a continuous basis resulting in the team gaining a much deeper understanding of the business and finally, simplifying the complex parts of the system.
3. Gate Keeper for the team: The first reaction of most people to this term is "Project Manager". While project manager may be expected to be the overall gate keeper for the team, it is the business analyst is better equipped to be the first gate keeper. Most of the scope changes are known to the business analyst much before those get bubbled up to the project manager. The business analyst need to own the overall scope and changes/negotiations on the same.
4. Delivery owner: This is not about doing away with the Delivery Manager role but the business analyst need to have the delivery owner mindset. The business analyst's role starts at the conception of a feature and ends at successful delivery to production. Only analysis of requirements or writing stories and then throwing them over the wall to the development team invariably results in a product that does not meet the vision and has too many defects/changes. As the requirements progress through various stages, there is a tremendous amount of feedback that comes from various team members. For a business analyst, listening and acting on that feedback is one of the keys to success.
5. Complement the development team: Last but not the least, the business analyst complements the team by bringing in the business understanding and helping the team at every step. The business analyst is part of the team and not an external entity. In my experience a very close alignment between the business analyst and the technical lead is a must have for the success of the project. Any mis-alignment between these two leads to a solution that is not true representation of business needs and goals.
Unfortunately, analysis continues to be not seen as an art and there is continuous creation of checklists, steps etc. For business analysis to be successful, it needs to be thought of as an art that needs to be practiced to get better at.
