Friday 12 February 2016

How To Fit BA’S & PM’S On Agile Projects?

It seems like there has been a discussion about this for 10+ years and we will probably continue the discussion for another 10!

Titles do cause confusion. In general, there has always been a confusion regarding the roles of PM (Project Manager) and BA (Business Analyst). The role of a BA and PM are not divided into undisputed territories. The industry works hard to clearly draw a line between the roles of a BA and PM, but the real-life challenges of organizations and projects make perfect alignment to textbook role definitions impossible. With the advent of Agile, roles related to Agile have been added to the mix. This makes it even more difficult do actually decide how to fit BA and PM on an Agile project.

In today's business environment which are fast paced, companies are constantly under pressure to adapt to the changing market conditions. Companies that are into software development increasingly incline towards agile development practices to help them stay ahead in the market. Agile processes are iterative, highly collaborative and all focused on the rapid and incremental delivery of software.

More and more organizations are transitioning to an agile mindset which creates more confusion pertaining to roles of BA and PM. Common title and role-related questions include:
  • Is a BA involved in an agile project?
  • What would be a BA’s role on an agile project?
  • Is the role of a Scrum Master the same as that of a PM?
  • Does the PM become Scrum Master?
  • Does the BA become Product Owners?
  • Is QA a part of the agile team or are they separate?

Do we really need to ask these questions? Or instead just adapt to the changing needs of the market. Many organizations have started to adapt but by modifying the roles as per their convenience and that makes it even more difficult for the industry to answer these questions? There is a need to stop finding links between traditional titles to agile titles. That’s not how it works. There is no direct translation or 1:1 conversion. And when we try finding that relation, it is no more agile and becomes hybrid agile. 


No doubt that skills of the people involved defines an agile team and not titles but that doesn’t mean we should neglect the core concept of agile. At times it becomes so difficult and confusing when BA, PM, Scrum Master, Product owner, all are involved in a single project and they call it an agile project. Nobody talked about roles like Scrum Masters and Product Owners before the birth of agile. That clearly explains that these are agile roles popularized and defined by the agile methodology.

It rarely happens when HR managers are looking forward to hire resources for the new agile roles. These roles are new for organizations implementing agile, but that doesn’t mean that there is a need to hire new resources. So, how do we get people for these new roles? The answer and the people are in the same organization i.e. people who have experience in traditional roles. PMs, BAs, Tech Leads, Solution Architects, Business Managers and Product Managers with little bit of research and training can take up these new agile roles.

There are times when titles don’t change. So, by title one can be a Business Manager but play the role of a Product Owner when working with an agile team. One can be a BA by title but my role would depend on what the team needs and what talent I bring to the team when it is agile.

Basic skills required for every software development project remains same. The only difference is in the application of those skills in accordance with the project requirements. The ultimate goal is to successfully complete the project, be it in the traditional way or the agile way. The agile team determines in achieving this goal by applying agile principles to determine what will add the more value to the business process and the customer.

There is a mad rush in the market and everyone wants to be agile. Transitioning from traditional to agile can be frustrating given that at times agile roles seem to be a bit blurry at times. Every organization tackle this challenge differently. If we just forget about the titles and focus more on techniques, skills, incremental improvement, we can minimize the confusion involved in transition to agility. Let the focus be on successfully delivering value to our organizations instead of pondering over how to fit BA’s and PM’s on agile projects.

Every organization has their own terminology and have different names for different roles. It does matter what you name it, rather what really matters is the team dynamics needed to succeed in agile projects. Try and identify people who excel in their current job title in traditional projects, it should not be hard for them to work on agile projects. Ultimately you need to successfully complete the job at hand, with or without agile.

About Author:
Sachin Poojary is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: sachin.poojary@spluspl.com 

14 comments:

  1. Faster execution is why we go for agile methodology .... Hence the entities involved are few which naturally reduces overheads... Hence wen author says its important to know wat entity bring to the table rather than his nomenclature... Totally agree wid u Sachin poojary

    ReplyDelete
  2. Faster execution is why we go for agile methodology .... Hence the entities involved are few which naturally reduces overheads... Hence wen author says its important to know wat entity bring to the table rather than his nomenclature... Totally agree wid u Sachin poojary

    ReplyDelete
  3. Wow what an blog this helped me a lot....!!!

    ReplyDelete
  4. THANK YOU FOR THE INFORMATION
    PLEASE VISIT US
    custom erp solutions











    ReplyDelete