Focus on roles, not job titles within a Scrum team.

Guest Commentary, Guest Commentary

August 8, 2018

4 Min Read

Every industry is increasingly threatened by software defined companies. Share prices drop when it is rumored that Amazon will get into healthcare; automotive manufacturers are competing with startups who lead with software. Even airlines are describing themselves as software companies with wings. In response, traditional companies are adopting agile practices and the Scrum framework. But what does that mean to existing job titles and structures?

Self-organized, empowered teams encourage the need for generalists

One of the key principles of agility is empowered, self-organized teams. By empowering teams to make decisions, much of the waste of hierarchical decision making and reporting is removed. This enables teams to respond quicker to the customer, the problem, and the market. The reality of self-organization is that individuals are more motivated because they feel accountable and connected to the outcomes. And to avoid complex communication chains and hierarchy teams have to be small, somewhere in the 3 to 12 number. Add to that the need to deliver value and agile teams tend to be "agile," not just in terms of the product they are building but also the work or job they do to deliver that product. Agile does not preclude specialists, but those specialists must be able to be flexible in response to the needs of the team. There is no room for a specialist saying "that is not my job" when looking to swarm on a user story or push the increment to Done.

For many situations Scrum teams need to balance having all the right skills within the team and looking for help from external people. A great Scrum development team is staffed by people who can get stuff done by either doing it themselves or working effectively with others to do it. That means they might not have all the skills, but they know how to work within the organization to get help from the people with the right skills. 

Roles not job titles

Scrum does not prescribe job titles for two reasons:

  • Scrum is a framework. Thus, you take the framework and install it in your organization, creating the process that is right for you. You add to Scrum the practices, techniques, people and tools necessary to deliver value.

  • Job titles have huge implications to both individuals and organizations associated with compensation and position. Those implications are very context specific and have many stakeholders. Prescribing a particular job title would require radical change, which most organizations would find difficult. Instead, Scrum describes the roles. The people playing those roles can have any job title. For example, Product Owner can be played by a Product Manager, a Business Analyst or a CEO. Scrum Master can be played by a Team Leader, or Project Manager. The job title is specific to the organization and their context not to Scrum. Organizations can decide on who is in which Scrum role based on works best for their organization.

Don't let titles destroy the value of roles

Though Scrum does not prescribe job titles, it does provide a clear definition of the role. That definition may clash with the responsibilities of a particular job title. For example, Project Managers who play Scrum Masters can find a challenge in responsibilities and accountability. The Scrum Master has a simple, yet difficult, responsibility to support and promote the use of Scrum. They are not accountable for ensuring time sheets are done, or project estimates are completed. If those things are important for delivering done value, then the team ensures they happen. The Scrum Master helps the team understand what is valuable and what is not and makes it transparent to allow Scrum to work. Traditional project management responsibilities can get in the way of empowering the team and ultimately can reduce the value of Scrum. Those responsibilities can reduce transparency and openness of the team, which in turn will reduce the ability for the team to inspect and adapt.

Empirical process is a fundamental part of Scrum and that requires trust and being open. The same historic job title orientation applies to other titles such as Business Analysts who now have to "own" the product, which traditionally they have managed for other owners; or testers who now have to help the team test rather than do all the testing themselves.

Dave West is CEO and Product Owner with Scrum.org. He is a frequent keynote at major industry conferences and is a widely published author of articles and research reports, along with his acclaimed book: Head First Object-Oriented Analysis and Design, that helped define new software modeling and application development processes. He led the development of the Rational Unified Process (RUP) for IBM/Rational. West managed Ivar Jacobson Consulting for North America. Then as VP, research director Forrester research. Prior to joining Scrum.org he was Chief Product Officer at Tasktop where he was responsible for product management, engineering and architecture.

About the Author(s)

Guest Commentary

Guest Commentary

The InformationWeek community brings together IT practitioners and industry experts with IT advice, education, and opinions. We strive to highlight technology executives and subject matter experts and use their knowledge and experiences to help our audience of IT professionals in a meaningful way. We publish Guest Commentaries from IT practitioners, industry analysts, technology evangelists, and researchers in the field. We are focusing on four main topics: cloud computing; DevOps; data and analytics; and IT leadership and career development. We aim to offer objective, practical advice to our audience on those topics from people who have deep experience in these topics and know the ropes. Guest Commentaries must be vendor neutral. We don't publish articles that promote the writer's company or product.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights