When development organizations start to adopt agile practices, all of the roles in the organization need to change. In this post I want to focus on the dramatically changing roles of senior developers and team leads. In future posts, I will discuss how some other roles in the organization change as well. It is very common for organizations to hold on to their current conceptions of these roles and responsibilities. Trying to transform a development team into an agile team and not changing these roles accordingly will have a negative effect on the team by undermining the agile principles. In doing so, these teams will not realize their full potential, become less effective and less efficient than they could be.
Prior to an organization adopting agile practices developers tend to have individual work assignments. It is easy to see how much work one developer is working on versus another. I don’t necessarily believe this is a good metric for comparison, I’m just stating that when there are individual work assignments, the person doing the work is visible outside of the development team. Because of this, the developers who are perceived as getting the most work done tend to be the ones rewarded and the ones who are viewed as the senior developers in the organization.
Once an organization adopts agile development practices getting the most “work” done is NOT the most important quality of a senior developer. The senior developers should be spending a significant part of their day on coaching and mentoring activities in addition to software development. Listed below are responsibilities I would expect of senior developers on agile teams. The list is a combination of some of my own thoughts and some responsibilities that Esther Derby describes in her post, But are they Working Hard?
When you're the senior in junior/senior pair programming, the measure of your success is how much the junior learns
— Kent Beck (@KentBeck) May 25, 2015I’d like to call special attention to the second to last bullet point. One of the most effective things you can do as a coach is to allow the junior developers to do a lot of what you would consider “lead” work. Some senior developers struggle with this worrying that they have to be the ones doing the “lead” work since they are considered the senior folks on the team. However, one of the best ways to mentor junior developers is by giving them a safe environment to take on responsibilities that may seem like a stretch, and providing support and feedback along the way.
In some cases, you may find the current senior developers are also the ones best suited for coaching and mentoring. However, in a lot of situations this is not the case. While not always mutually exclusive, the skills that make a developer good at working alone and getting a lot of work done are not the same people skills that a developer is going to need to be a great coach and mentor. In these instances, the organization is in a challenging position where it has to start rewarding a totally different set of behaviors than it has previously.
Your senior people - not always the ones you thought were the senior people - now have an additional responsibility: bringing the less experienced people up to full speed. A highly paid expert shouldn’t be highly paid just because she’s an expert. She should be highly paid because she is helping other people become experts.
— Ron Jeffries, The Nature of Software Development, page 30
Once an organization has adopted agile practices, making a single person the “lead” of the group undermines a lot of the benefits that agile practices can provide. That is not to say that leaders don’t exist. Some folks are natural leaders and people will rally around them. The team will respect and trust these employees, and the employee will serve as a great example for the rest of the team. These are the people who will be coaching and taking on a lot of the responsibilities discussed previously. However, it is important to know that this leadership is totally independent of a title and on the best teams this leadership is spread throughout the team and not consolidated in a single person.
There are two agile practices in particular that I want to discuss that are at risk. These are self organizing teams and retrospectives.
XP relies on self-organizing teams. This kind of team doesn’t have a predefined hierarchy; instead, the team decides for itself who is in charge of what. These roles are usually informal. In fact, in a mature XP team, there is no one leader. Team members seamlessly defer leadership responsibilities from one person to the next, moment to moment, depending on the task at hand and the expertise of those involved.
— James Shore, The Art of Agile Development, page 52
Appointing a single lead on a team, whether it be a developer who is the technical lead, a business analyst or project manager who is considered the team lead, results in teams that can no longer self organize. Once a lead is given a title there is the expectation that they are doing more than others on the team to justify this position. If the lead is making most of the decisions this is robbing the rest of the team of these opportunities. The self organizing team becomes a “lead organized” team. Again quoting Esther Derby from her article, But Are They Working Hard?:
If only senior level developers initiate good practices, I worry that they’ve created a pecking order on the team, and junior people with good ideas don’t get a chance to contribute. (It’s a variation on the HiPPO problem–deferring to the Highest Paid Person’s Opinion).
— Esther Derby
Teams are motivated by their autonomy, mastery, and a sense of purpose. Often a lead being put on one of these teams “coming from above” or rather coming from management, will reduce the team’s feeling of autonomy, mastery and purpose.
Retrospectives are an invaluable tool in every software organization. They provide regular opportunities for improvement as well as a framework for surfacing and solving problems as a team. This allows a team time to reflect on the work being done and building trust in one another by solving problems together.
Once a team has an individual lead, retrospectives can easily become ineffective if the team cannot work together to solve their problems. When the lead needs to agree to or, worse yet, be the source of all improvements on the team, the retrospective is just going through the motions and is a wasted effort.
One of the biggest challenges with adopting agile processes is the amount of organizational change that is required to really do it properly and make it successful. The vast majority of organizations are not prepared to make all of the necessary changes. The result is a focus on their own customized / modified versions of agile practices that are devoid of the agile principles that the practices are designed to support. If you have a development hierarchy in your organization, invest in helping your senior developers mature as coaches and help them shed any “lead-only” tasks that can’t be shared with their team.