A lot has been written about roles and responsibilities in Scrum but the topic is still ambiguous. The Scrum Guide is saying that there is Product Owner, Scrum Master, and The Team. But what is The Team? Developers and testers only? What about business analysts? What about Product Managers on the business side who make prioritization decisions? What about Development Managers? QA Managers? Dev Leads? Operations? There is no stated role for them in Scrum.
This ambiguity is sometimes a reason for people in the roles listed above to fear and resists Agile. However, they are the ones who should embrace it because they will benefit significantly and will get seats at the table with Agile transformation, just not at the implementation team level.
Let's address the three primary roles first. According to the Scrum Guide, "The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity." This does not mean that everyone on the team should be fully cross-functional, but it does mean that team as a whole should be able to provide end-to-end functionality, i.e. if you have web services team and UI team separately, they are not cross-functional.
"The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. " Check out this brilliant video by Henrik Kniberg on the Product Owner role.
"The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team." Check out this article on the details of the Scrum Master role.
What about Product Managers? All of them are definitely stakeholders so Product Owner will take their opinion into account while prioritizing, and will communicate back to them. According to a well-known Scrum metaphor, they are "chickens" but not "pigs".
What about Business Analysts? Many of those are very successful in their transition to Product Owner, but for the time being they are working as Product Owner proxies collecting information and populating the product backlog.
Now, dev leads are a tricky situation. Make an effort to remove them from a planning session where they estimate for everyone and start discussion from their own opinion. Dev leads are a great asset to a team as a team member not a manager or a decision maker for others. They will take over technical user stories or be a stakeholder in those and become a crucial team member with the same decision power as anyone else on the team.
Managers sometimes want to control their employees, so we have to be mindful about any signs of command and control. In Scrum managers have a distinct role to support roll out of best practices in their area of expertise across the organization, whether it is testing or development. In many organizations though I saw successful managers becoming members of their cross-functional Agile teams and doing hands on work along with everyone else on the team. Either way, there is always a role for those who want to contribute and who are interested in bringing value in their area of expertise.
But most importantly, Scrum team members irrespective of their role on the team are decision makers on topics within their domains and active participants in any analysis and brainstorming session on their Agile implementation. No Agile Coach or Scrum professional can decide it for them. Bring them to the table, and you will be positively surprised by their thoughtfulness, creativity, and subject matter expertise!
When a team is formed, each team member has a specific area of expertise. In software teams, we have developers, testers, analysts. In meta-teams, we have a group of specialists, each of them being a subject matter expert in their respective area. This is normal for a team as their stepping stone to starting collaborating and delivering products. However, no team can achieve hyper-productivity until it is cross-functional.
Cross-functionality is part of the Scrum definition and is listed as a pre-requisite for Scrum success in Jeff Sutherland book "Scrum: The Art of Doing Twice the Work in Half the Time". Why is it so important? Imagine a software team where all coding for the sprint is complete but the testers are just getting busy with the test cases while thousands of tests are run as part of their regression test. You need developers to be ready to write test cases, automate regression testing suite, and run those cases. You need testers who understanding basic development work, and analysts who understanding both competencies and speak their language.
So how do you turn your team of narrow specialists into a truly cross-functional team? Let us first review the definition: "... interdisciplinary Teams are also referred to as „cross-functional teams. Each team member brings different skills to the table, all of which complement the skills of the others, making it possible to cope with a variety of tasks and find innovative solutions." This definition is fully applicable. In this case, team members "swarm" in supporting each other in accomplishing their sprint objectives so that user stories move through the workflow without obstacles. This approach increases productivity, supports innovation, and creates truly collaborative environment.
As always, the best answer is in identifying the right balance between team members having deep knowledge in each of their areas while having working understanding on adding tasks to other team members' stories. How do you identify the best way to accomplish this? As always, by experimenting, by trying the best ways to increase cross-functionality and collaboration on your teams, and thoughtfully learning from your mistakes. You can try pairing, cross-training, creating mini-teams, and other ways to build Communities of Practice while promoting collaboration and team support. This is a pre-requisite for a healthy Agile environment.
While Agile works well at team level, it is portfolio level and higher where things get difficult. There are multiple things that get in the way:
How do you address these challenges? The best way is to build a solid portfolio of your features and expose a roadmap based on your release planning. What are the primary milestones you are planning to deliver at high level? What are the timelines associated with key functionality delivered? There are multiple templates available but my preference is either portfolio template if we are delivering a product line within one program, or a feature roadmap if the team is delivering against specific product objectives. Good samples of these templates are available here. Many agile management tools such as Jira and Rally provide portfolio functionality based on the epics and user stories planned within your product backlog and generate roadmaps automatically or using plugins.
Once you create such a draft, the next step us to get input from the stakeholders based on shared priorities. Let them have focused conversations so that everyone understands dependencies and priority of one feature over another. Once the decision is made by the Product Owner based on this input, there is time to socialize your portfolio roadmap and the product features that are going to be delivered. It is important to build shared understanding that the roadmap is aspirational and changes will happen, which will be immediately communicated to the stakeholders.
Core stakeholders and anyone who is interested (dependent or contributing) in the outcome are invited (and expected) to visit demo's every sprint. It is advisable to send summaries (what was delivered, which stories were missed, major impediments and how they are going to be addressed, summary of questions and suggestions from the stakeholders, etc.) to all key stakeholders after each demo because some of them may not be able to join. Normally these summaries are send by the Product Owner or uber Product Owner within the portfolio, but sometimes Scrum Masters are better positioned to send it out every sprint as a summary.
In sum, there are two secrets to a successful portfolio management:
- involved the right group of portfolio stakeholders in providing input into prioritization decisions;
- once the roadmaps are created by the Product Owner and the team based on this input and the team's release planning, they need to be broadly communicated with the understanding that these goals and milestones are aspirational in nature and will be changing as delivery is progressing (progressive elaboration).
It is important to promote this atmosphere of co-creation with your key stakeholders in building portfolio and feature roadmaps for your products and to ensure that the roadmaps are updated as soon as there is a change. This is one of the reasons to keep these artifacts high-level so that a printed version fits one page, and to keep these files in a shared repository or on the Intranet, so that the changes are immediately available to all stakeholders.
Your roadmaps are both your strategy and execution tools that you use for communication and alignment, which makes them important artefacts relevant for product owners and agile teams as well as a broad group of stakeholders. You cannot overcommunicate these artefacts.
The essence of my advice is: do not treat your portfolio prioritization and release planning as a responsibility, treat these efforts and related artefacts as a vehicle to communicate your product vision and strategy, and align on dependencies and expectations with other teams and business groups.