Where is My Job Title in Scrum?

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:

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.