One of the many facets of the Agile team is that they are in large part self-managed. Coming from a traditional project management world, this may seem to be a foreign concept as every team needs some sort of leadership, right? In fact, these teams have proven successes behind them. After becoming more informed on the Agile process, I became more aware of how this can become a reality. Here is why.
- Ownership
Self-managed teams will create their own work assignments, and thus have more ownership over them. When you encourage your team to bring everything to the table, you may see them take ownership in new and better ways. I’ve made this point before in other Agile blogs. This is not only true with development teams but teams in general.
- Team Development
Teams have phases of development. There is so much research on this. The stages follow the path of Forming -> Storming ->Norming -> Performing*. This model was proposed as early as 1965 and is one of the fundamentals in team building for Project Management. The reason this ties into self-managed teams is that if a new manager is introduced into the team, the typical response would be for the entire team to go back to the forming stage. To prevent this, a good PM will remain hands off, observing the team’s skills, and only providing direction where needed.
- Downward directed schedules don’t always work
Schedules need to be developed with the team, not for the team. Obviously, client deadlines and requirements need to be factored, but team members know their strengths when it comes to the work effort. The role of the PM is to monitor the schedule, not always direct it.
- Remember to use “We” not “I”
The PM in conjunction with the customer and stakeholders may lay out the strategy, but it’s the developers that will implement it. This is why it is important to remember that project personnel is a team. The strategy may have set up the project, but in the end, the actual success was brought about by the team.
- Keep the tasks, assign responsibility
This is one of the harder items for the traditional PM to let go. We tend to build our tools and schedules around the tracking of tasks. This doesn’t have to take on a dramatic change; you just have to adjust from individualizing the items within the project to assigning the systems of it. Even though Agile has us build our Sprint board with the ever present post-it notes, you don’t have to be the one creating those. Let the team approach this from the big picture and let them go at it. You will find not only do they understand it better, but they will also design it better.
*Taken from research conducted by Bruce Tuckman in the model “Tuckman’s stages of group development.”
