As more and more organizations transition to an agile mindset, new roles get added to the mix, causing even more confusion. When I work with emerging agile teams, common title and role-related questions include:
- Do agile projects & teams have BAs?
- Do PMs become Scrum Masters?
- What is the BA’s role on an agile project?
- Is the Scrum Master the same as a PM?
- Do BAs become Product Owners?
- Is the Product Owner a SME or a sponsor?
- Is QA part of the agile team or are they separate?
We really need to stop asking these questions! When organizations all define these titles differently to begin with, how can the industry answer this for everyone? We need to stop trying to draw lines from traditional titles to agile titles. It doesn’t work—there is no direct translation—no 1:1 conversion. We get frustrated because this is the mess going on in our minds:
Real people work on agile teams, not titles. What strikes me when I hear the role confusion questions about agile is: Did we have hiring managers searching for Scrum Masters and Product Owners before? No, these are simply new titles that have been popularized by the common agile team member roles.
These may be newer roles or titles for organizations implementing agile, but that does not mean that they are completely new people. So, where have we been getting the real people for these roles? From PMs, BAs, Tech Leads, Solution Architects, Business Managers and Product Managers—people with experience in traditional roles. Many times, their titles are not changing! So, by formal title I can be a Business Manager and play the role of a Product Owner on an agile team. I can be a BA by title and be part of an agile team, where my role depends on what the team needs and what talents I bring to the team.
The same tasks need to be completed on agile and traditional projects, but the timing, format, and accountability changes as well as the definition of “done.” The agile team determines these aspects by applying agile principles to determine what will add the most value to the process and the customer.
As BAs and PMs we always ask our stakeholders “why is something done” and we dread the common “we have always done it that way” response. We need to ask ourselves the same question about our work. Why do we do what we do? Can it or should it be done at a different time, in a different format, at a different level of detail, as a team instead of as individuals, to get even better results?
If we can let go of titles and focus on skills, techniques, and continuous improvement, we can minimize the confusion involved in the transition to agility. Let’s stop asking where the BA or PM fits into agile and start looking at real people who have a mindset needed to collaborate and successfully deliver value to our organizations!
Our mindset needs to shift to something like this:
The same basic skills are required for every software development effort—it’s how and when you apply them that varies. How can you apply agile principles to your organization to inspire innovation and maximize value?
Review the agile manifesto and the agile principles. Don’t ask where the BA fits or how the PM role changes. Focus on building a team with skills that align with agile principles and question how your approach to work aligns with the principles:
- How do we promote consistent and continuous teamwork and collaboration?
- Are we constantly focusing on value in everything we do?
- Are we focusing on dialog and discovery over process and documentation?
- How do we encourage people to let go of job descriptions and empower them to jump in and help as needed with a variety of roles and responsibilities?
- Do we have team members with facilitation skills that create a sense of shared understanding and make stakeholders feel safe, knowing prototyping, iterations, and collaboration often can replace reams of paper?
- Do we have team members who can elicit, identify and communicate requirements?
- How do we manage and adapt to change? Do we have team members who are rigid or flexible?
- Who are the people in our organization with strong vision?
- Which people in our organization can help groups simplify, prioritize and make progress?
- Do our team members have the leadership skills needed to self-organize?
This transition to an agile mindset can be difficult for traditional organizations.
Why? Organizations, especially large ones, are defined by their structure. Titles and processes provide the foundation for accountability (job descriptions, hiring, performance evaluation, termination, etc.). So, the real driver of difference here is that agile commands us to think differently about accountability and structure, and how we deliver value. The agile mindset demands:
- Flexibility: With a focus on continuous improvement, the roles and responsibilities of agile team members need to change with the needs of the customer, the team, and the business environment.
- Equality: Agile principles limit hierarchy and job descriptions. The team rolls up their sleeves and works together providing whatever skills are needed to bring value to the customer.
- Continuous Collaboration: To consistently deliver working software in short timeframes, agile team members need to stay focused. Job titles and responsibilities outside of this focus might need to be restructured if they divide the attention of a team member.
- Customer Satisfaction: Customers need to be available to consistently collaborate, preferably face-to-face, with the agile team and to review regular releases of working software/products.
The more we try to place accountability on individuals/roles/titles the less agile we really are. This does not mean there is not a role for BAs and PMs on agile teams. Instead, it means we need to rethink how we define role or title. We need to define them by focus, mindset, and objectives, not by documents and individual accountability. Agile is a transformation, at an organizational level, that challenges teams and organizations to think, act, behave and lead differently.
We also need to understand what tasks and processes should remain outside of the core team. Too many organizations try to fit every project task into an agile framework, which often limits their agility. Supporting and overhead tasks like audit, governance, documentation, training, etc … if needed, can be done by a supporting or partner team. This allows the core team to remain focused on product value and delivery.
What do you think? Are titles getting in the way of your organization’s transition to agile? How do you find the right people/skills for your agile teams? Please leave your comments below.
Don't forget to leave your comments below.