Discover the different roles in an agile team. These include the developers, the product owners, the scrum master, and the project managers.
- A lot of the ideas behind scrum were adopted from a Harvard Business Review article written in 1986. The paper described building a self-empowered team where everyone had a daily, global view of the product. The paper used rugby as an analogy and cited scrum as an example of a holistic or all-at-once team. A rugby scrum tried to push to a destination without discreet roles but as a self-organized group. The paper also introduced the idea of cross-functional teams. They described a cross-functional team as a group of organizational slices, different groups in the organization layered into one team. That means you could have teams that had customer representatives, testers, graphic designers, all working as one team. Because scrum was one of the earliest frameworks, many Agile teams still use the scrum language to the describe the team roles. This is true even if the Agile teams decides not to adopt all of scrums processes. In a scrum team there are three formal roles: The product owner, the developers, and the scrum master. The role that usually gets the most attention is the scrum master. This role is often mistaken for a traditional manager who masters the team. The role is really intended to be a combination of an Agile administrator, coach, and trainer. The Master in the title is intended to show that this person masters the scrum framework. The impressive-sounding scrum master has been a boom for scrum certifications. No one wants to be a certified Agile facilitator, certified scrum master sounds like a role filled with power, it has heft like a Jedi Master. In reality the scrum master's role is much more practical. They will spend most of their time removing obstacles for the team, and ensuring they have a great work environment. It's important to remember that the scrum master works for the team. This could be a significant change if the person comes from a management background. A scrum master who's large and in charge will only cause confusion for the team, the team needs to self-organize. If you're the scrum master for the team, they key thing to remember is restraint. Try to remember that any time you manage the team you're actually pulling them further away from true self-organization. One of the most important roles on the Agile team is the product owner. The product owner is the true seat of power for the team. The product owner should have a direct line of communication with the customer. They'll work closely with the final users of the product, and determine the work for the rest of the team. The product owner will primarily work to maintain the product backlog. The backlog is a ranked list of all the functions and features that the customer would like to see in the final product. The key challenge for the product owner is ranking the list. As you can manage, not all customer agree on the highest priority work. The product owner has the final say in what gets done first. The final roles for the team are the developers. The developers are anyone who's working on delivering the product. If you come from a software development background, then you might be tempted to think of developers as just software coders. Then you also have software testers, graphic designers, and database specialists. Agile tries to have a cross-functional team, so coders should be able to test, and database engineers should be able to code. That's why Agile doesn't distinguish between these roles, all of them are lumped together under the role developer. In Agile, the developers are the true knowledge pool for the team. A key part of self-organization is that the developers estimate their own work, then they commit to delivery. The developer should have a good mix of skills. There's a shared responsibility for the team to produce; no single team member should wait for others if they have the ability to help.
- Starting agile in your organization
- Defining team roles and responsibilities
- Letting the team self-organize
- Training the team
- Thinking and delivering like an agile team
- Avoiding pitfalls