What do I mean to share across Agile roles? A team possessing the ability to use an overlap across team members in their job functions and responsibilities. As part of Agile development work, sharing roles and responsibilities between the members of the team. The best Agile teams have this overlap. Allowing more of a team approach to doing the work. Also, allowing team members to learn by sharing expertise with other team members. Blur the lines between these more traditional Agile team roles, to really take the team to the next level.
The best teams have overlap in their roles!
Additionally, this covers how the job roles are organized and shared on the team. Allowing more work to be done at the same time by the team. This doesn’t have to be a formal sharing of roles. Teams can take this upon themselves, to distribute the work. It is more effective and better results are possible that way. As a point, this sharing should not be formalized. The time it takes to formalize and organize the role sharing takes away from the self-organization of the team. It also slows them down.
- Restricted roles restrict the team
- Blurring roles enables swarming and swarming enables Agile delivery
- Share across Agile roles to gain flexibility for the team
- A contrasting example is the assembly line
- When said and done, it’s about delivering value
- Additional content and eBooks helping share across Agile roles
Restricted roles restrict the team
Restricted roles on the Agile team hold back the team. Team members don’t get to branch out. They are unable to try and learn new things, as they are stuck in their defined role. Some of this comes from the traditional Waterfall SDLC. Where the traditional idea of what roles are is held onto. Let the roles expand and expand the capabilities of the team. Sharing roles beats the Waterfall model of development.
Certain jobs and organizations do a great job of sharing an understanding of job roles, from one role to the next. Allowing for, and encouraging, a blurring of the lines between job roles. Ensuring that job functions don’t strictly stay with a role or person on the team. Such that others outside of that role have a greater understanding of the job responsibilities it entails. The benefit to the organization is tremendous!
I see some carry over to Agile software development concepts. One item, in particular, is the swarming by a team, around work, to help get that work done. In this, team members work together to break apart work tasks, to enable faster work completion. While doing so, some team members may be called on to do work differently than they are used to. All to enable the work and meet team goals.
Blurring roles enables swarming and swarming enables Agile delivery
This aligns with the versatility of sharing or distributing team roles across the breadth of the team. Versatility within the team to help with varying tasks, not just tasks associated with your role, is a great way to help complete work faster. Team members grab tasks needing to be done, regardless of what it is. Everyone chips in to help and the work is completed that much faster.
I understand the blending or blurring of lines, between certain job roles and specialities isn’t always possible. But for examples where it can’t be done, I challenge the team to think on it and I would bet there are examples where it can be done. That attitude will help the team to be more successful.
Share across Agile roles to gain flexibility for the team
Blurring the lines between job roles gives the team flexibility. Flexibility helps enable the team to deliver value. The team is more able to respond to change. If you remember the Agile Manifesto, responding to change is a core value.
Blurring the lines between roles on the team helps build a truly cross functional team. A team that doesn’t have varying knowledge set to just certain people and roles on the team. The knowledge is shared, and you help build up the entire team.
A contrasting example is the assembly line
Work that has a single task with a single person. The work does not move to the next person until the first has finished its task. This is generally associated with an assembly line type process. Not to say this is a bad way of doing things, in some aspects it does work best. However, in software development, it has its drawbacks. The SDLC that most closely matches the assembly line is Waterfall. Waterfall is very much an assembly line type of activity. This is to mean that person A does their task, then it can move to person B, who completes their task. It’s specific and ordered, and you cannot progress until each portion is completed.
Of course, the assembly line is not sharing across Agile roles. They are very specialized in each task. Leading to efficiency in the individual tasks, but not a knowledgeable and effective team.
Agile SDLC is more of team swarm activity on the work, where you collaborate to get the job done. Multiple people are performing different types of work, all to work towards the goal and often overlapping with other team members work. Where, coming back to the blending of roles, when all are working together there can’t be all kinds of work for all people. There will be some work that falls outside of the norms for some team members, and if they can help with it, it helps the team be successful.
When said and done, it’s about delivering value
At the end of the day, the team wants to deliver valuable work to their stakeholder. One of the best ways to do that is to collaboratively work their tasks, to speed up delivery. A key enabler of collaborative work is the blurring of job roles. Sharing across roles helps with continuous improvement of all, instead of putting knowledge gained in a silo.
Make sure to share across Agile roles to empower the team!
Teams that share across Agile roles and responsibilities have an easier time breaking down blockers and removing bottlenecks. So share across these team roles to really grow the team.
Additional content and eBooks helping share across Agile roles
A fresher on Agile values and concepts is always beneficial. So don’t forget the Agile Manifesto.