Leaders of agile teams often see some common issues crop up on teams. Very often, the issues faced by a team are particular to the situations the team finds itself in. The same applies to the leaders of these teams. They face unique obstacles depending on the teams they are on. Being a team lead is about adopting new practices, modifying existing processes and removing unnecessary clutter from the team's systems. I asked four team leads about the obstacles they face and the changes they have made on the teams to make the team more agile and/or productive. These are the same folks that participated in the last post. Below are the responses.
What have been the biggest obstacles that you have faced as a lead?
"Acting as a manager, without being a manager.", according to Mariana has been one of the biggest obstacles for her. She does feel that she has been "Lucky to have been on the team for a long time". This has helped her garner the respect of her teammates and which in turn has helped her fill the "manager" role. There are other little things that she feels hold her back - Not having "admin rights" in issue tracking tools, having to keep track of PTO for team members and other small added on responsibilities.
Mariana sees the ambiguity of an agile team lead's responsibilities as an issue. Is she a manager? If so, should she be given rights to perform other managerial functions? Is she a project manager? If so, should she have full admin access to project management tools? The ambiguity in role definition leads to the ambiguity in rights(admin or managerial) provided. This is not necessarily a negative though. The ambiguity leaves space for Team Leads to better define their own roles according to the needs of the team.
"Keeping the team motivated" for our anonymous participant is one of the bigger challenges. Another major challenge for him is to "distribute workload within the team evenly" and "balance capabilities within the team". He feels that "high, mid and low level performers" should be teamed up with each other on projects to promote knowledge transfer and help low performers improve.
Keeping a large team motivated can be a tough ask for any leader. It is rightly pointed out as an obstacles as the variety of personalities on agile teams is often large and what helps them get motivated is different in case of every person. Agile throws a bunch of individuals into a team room and they have to sink or swim together. The desire to help them work together in the best possible scenarios is another challenge that is well noted here.
"Recognizing that I am the leader, not the secretary" for the team was Mike's biggest obstacle that he feels he has overcome. He says that Team Leads need to "understand that the team needs your direction". The have "to be the de-facto leaders of the team."
Mike is an experienced LPE and understands his role well. He seems to understand the value of a strong leader on the team and the importance of the direction that leader provides. Agile leads are 'servant leaders', but if you let the former part of the phrase dominate, the role becomes more secretarial rather than one in a well balanced leadership capacity. Since the Agile leads usually emerge from within the team, it is a tough concept to grab at the onset. Emerging as a leader of your peers, who you are technically on par with is a skill that every agile lead has to slowly develop.
Mariana sees the ambiguity of an agile team lead's responsibilities as an issue. Is she a manager? If so, should she be given rights to perform other managerial functions? Is she a project manager? If so, should she have full admin access to project management tools? The ambiguity in role definition leads to the ambiguity in rights(admin or managerial) provided. This is not necessarily a negative though. The ambiguity leaves space for Team Leads to better define their own roles according to the needs of the team.
"Keeping the team motivated" for our anonymous participant is one of the bigger challenges. Another major challenge for him is to "distribute workload within the team evenly" and "balance capabilities within the team". He feels that "high, mid and low level performers" should be teamed up with each other on projects to promote knowledge transfer and help low performers improve.
Keeping a large team motivated can be a tough ask for any leader. It is rightly pointed out as an obstacles as the variety of personalities on agile teams is often large and what helps them get motivated is different in case of every person. Agile throws a bunch of individuals into a team room and they have to sink or swim together. The desire to help them work together in the best possible scenarios is another challenge that is well noted here.
"Recognizing that I am the leader, not the secretary" for the team was Mike's biggest obstacle that he feels he has overcome. He says that Team Leads need to "understand that the team needs your direction". The have "to be the de-facto leaders of the team."
Mike is an experienced LPE and understands his role well. He seems to understand the value of a strong leader on the team and the importance of the direction that leader provides. Agile leads are 'servant leaders', but if you let the former part of the phrase dominate, the role becomes more secretarial rather than one in a well balanced leadership capacity. Since the Agile leads usually emerge from within the team, it is a tough concept to grab at the onset. Emerging as a leader of your peers, who you are technically on par with is a skill that every agile lead has to slowly develop.
"Resistance to change within and with-out the team" has been one of the greatest challenges for Yvette. "Effective communication of constraints to other teams" that her team supports especially in terms of "being recognized as a part of development rather than support for deadlines".
Yvette's team is client facing and any process changes proposed are often heavily scrutinized because they can have deep impacts. As a true lead though, she has not been afraid to propose and make these changes. Although the team can be an entity onto itself, it often, especially in Yvette's team's case, has direct upstream dependencies on other teams. These teams all have the same deadlines and while other teams are working towards their deadlines, Yvette's team is coming up with ways to avoid a time crunch due to the dependencies.
What would be one thing you would change in order to improve your team?
"Get the team more exposure to the customers", says Mariana is the primary change that she would make to help the team. She says "it adds meaning to the team's work".
Mariana touches upon an aspect of agile that has not been as broadly explored at many organizations. Getting every member of the team to understand the customer's needs and pain points gives the team a stronger connection to what they are building. This in turn helps them make better decisions regarding design, prioritization and even to some extent implementation.
Shortening "the time it takes from a story to move from code complete to close" is the critical change that the anonymous participant would like to see on his team.
Projects where there is a direct imbalance between how long a story spends in engineering vs testing can see the backlog getting stuck in one stage of the development cycle. There are multiple strategies to counter this, and the one that would work best, would depend on the team itself. Some strategies that I have seen work successfully have been pairing Devs with QAs to help develop the automation for the tests the QAs write, introducing more tech debt type items that the devs can work on, while QAs catch up, or have strict discipline with keeping the number of total stories in progress limited. Only criteria for the strategy adopted, it has to suit the team well.
Mike believes that getting "TRADE(Yvette's triage team) coverage" for his team and getting help with "external escalation management" is the primary thing that will help them improve. Mike also mentions "getting away from UI automation" as another major improvement that can be introduced.
Having another group triage issues to determine if the issues are real functional issues is a double edged sword. It protects the team from unnecessary interruptions, especially from issues cause due to product knowledge gap, but at the same time pushes the responsibility of closing that gap towards the users instead of pushing the product designers to improve the usability and to make the product more intuitive to use.
Yvette believes that "greater cross-training" is the one major improvement she will make to her team. She also wants to "make the check-in process for customs water-tight".
Yvette's team works in a high pace environment and cross training often takes a back seat. Her team might benefit from pairing techniques to get team members comfortable with working in different areas. CI and a stable build/code check in process is at the base of all successful agile engineering practices. Getting another team(or department in this case) to adopt agile practices can be a tough sell, but at the same time, having a partially agile organization can be an impediment to whichever agile team has to interact with a non-agile part of the organization.
Once again, it was great to review all the information that was passed on to me by this varied group of leaders. I have learned a lot from their experiences and we have had some very interesting conversations with them about the same. Once again, hoping to continue to have these interactions with the same folks and a larger group.
No comments:
Post a Comment