Four Challenges of Adopting Team Structures (And How Leaders Can Mitigate Them)
If you’re considering “going agile,” one of the critical components of such a transformation will be adopting team structures. In your current, pre-teaming state, your developers are probably working by themselves, and may be engaging directly with stakeholders.
Agile will place your developers into teams. Teaming is important, as it will enable your development staff to actively learn from one another, improving the quality of their individual and collective work, and improving the work environment. Teaming will also allow the organization to better facilitate more bold technical directions, which may seem scary or uncertain to any single developer, but together they can brave new methods and products. Teaming will also help ensure that your development staff are providing their best efforts, both in technical expertise and level of effort, as teaming creates a positive peer pressure you may have experienced in any team environment, whether sports, the military, or other experiences. So, while teaming provides a number of benefits, creating teams may pose a number of challenges to you, your organization, and your development staff.
Team Buy-In
Challenges to adopting team structures include getting buy-in from your group of developers to work together. They may be facing a number of fears associated with this transformation in how work is assigned and managed. Some of their fears may include the likelihood that there will be conflict on the new team related to both differences in skills and personalities. This can be mitigated by listening to and responding to their feedback as the teams are formed. It is also helpful to have clear messaging about the need for teams, that the transformation to teaming is about improving the organization, not individuals. Leadership must clearly communicate that the goal of this change is to make the work more fun, less stressful, and more productive.
Adequate Management Capacity
Another concern of reorganizing your development staff into teams is the concern that you may not have enough management capacity to organize and lead the teams. This concern can be shared by developers, middle management, and senior leadership. The reality is that teams will require dedicated managers to ensure that their work is prioritized, appropriately documented, and that the expectations of stakeholders are actively managed. To mitigate these concerns, it is important to identify someone to lead the development team and manage the communication, documentation, and prioritization necessary with the agile method.
This role can be a Project Manager or Scrum Master, but it will take time and effort for someone. This incoming manager can be either someone from the development staff that’s dedicating time to this role, or a new addition to the team that will ensure that developer talents are focused on value-generating activities (software development!). This role of Scrum Master or Project Manager is important, ensuring that the sponsoring organization understands the limits of the development team, that stakeholders are committing to the highest priority tasks, and that developers are not over committing to future work. An important role, and one that It should be filled by staff that are technical subject matter experts with great communication skills, and who are comfortable productively addressing conflict.
Managing Stakeholder Expectations
Another challenge associated with adopting team structures is the fear of managing stakeholder expectations. In your current state, stakeholders may be directly interacting with your developers, and while there may be the appearance of stakeholders understanding competing priorities, the reality is that well-managed teams will improve how development requirements are prioritized and communicated. Teams will bolster commitment to completing assigned tasks, but this will also mean that they will remove tasks they can’t commit to completing. If this hasn’t been done before, stakeholders may be told “no” for the first time on their requirements. This “organizational honesty” is one positive side effect to teaming and the increased commitment it generates, but your stakeholders will be initially concerned about the honest feedback. While stakeholders may be concerned that developers aren’t able to promise as much as they once were, the reality is that the organization is no longer allowing the “white lies” of false promises from planning.
Meanwhile, developers that are soon to be formed up in teams may fear the backlash from stakeholders that were used to interacting directly with developers. This fear may extend to middle management, who may not be comfortable with stakeholders hearing “no”, and who may be ultimately insecure with admitting the organization’s limits in resources, and the conflict that will naturally result from determining priority for these limited resources.
These fears can be mitigated by leadership clearly communicating that conflict is necessary to properly prioritize work. Conflict must be productive and respectful, but it can’t be hidden if the organization is to focus its limited development resources on the most critical tasks. Leadership must communicate that teamwork is expected to generate improved commitment, which will help inform stakeholders what the team is capable of, in terms of capacity, speed of development, and technical feasibility. Leadership must also communicate that stakeholders are a necessary part of the process, facilitating the prioritization of work with discussions with the development team. But, it must be clear that leadership is focused on improving “commitment”, that is developers will provide truthful feedback and commitment, and stakeholders must respect it. Their role isn’t to pressurize development staff into taking on more work than they can handle, rather their role is to ensure the work being committed to is the highest priority tasks for the organization. The roles of development project managers and stakeholders is to increase productive conflict in the organization, and this may be the first time these discussions are coming to the surface. Leadership must help development staff and stakeholders navigate these waters.
Changing Sense of Ownership of Development Resources
Lastly, your stakeholders may fear losing the “developer in their pocket.” Your stakeholders are probably interacting directly with developers, and teaming will reduce this interaction. While this will be an improvement for the organization, stakeholders may currently view the developer as a resource “they own.” Increasing your management over the developers, as well as the “collaborative power” of developers through teaming will reduce the power of stakeholders who have gotten used to engaging with them directly and asking (but not always getting) what they want.
The reality is that adopting team structures will increase the power of the developers to push back against unrealistic timelines, technical directions, or potential solutions, as they will be able to bolster one another in the various agile events (Sprint Planning, Sprint Reviews, etc). To be clear, the organization will benefit from this increase in “power”, but the stakeholders will fear the conflict this will create.
It is important to mitigate this particular fear of teaming by communicating with stakeholders and ensuring they understand “what” work is accomplished is more important than “who” completes it. Leadership can help stakeholders understand that teams will provide stakeholders with access to more development resources, the right talent for the requirements stakeholders are providing. This will improve the speed and quality of software development’s response. Leadership must ensure that stakeholders have ample opportunity to engage with the new teams, reducing their need to communicate or control individual developers. Structured communication approaches will reduce interaction between stakeholders and individual developers. This will reduce the stress felt by both individual developers and their stakeholders. Agile will place requirements into a backlog, and as work is realistically committed to by the development team, stakeholders can stop worrying about “if” the work is completed, and rather focus on managing the priority of work and improving communication with users to better manage their expectations.
While there are a number of challenges associated with adopting teams as you transition to agile development methods, the benefits of teaming will outweigh the challenges and fears. It will be critical for leadership to be actively engaged, mitigating concerns and addressing issues as teaming is adopted, as bringing developers together onto teams is a key part of “going agile.”Check out some of DigitalGov’s recent articles on the agile methodology. Have a .gov or .mil email address? Join the Agile/Lean Community of Practice to connect with others at federal agencies working to increase team efficiency and customer satisfaction, while reducing project risk and cost.
