Many organizations use the agile scrum model — from the simplest forms advocated by the Scrum Alliance to more complex models such as the Scaled Agile Framework (SAFE). These tend to prescribe a small set of specific, new roles on each team, while allocating most team members to a generic “team member” role. We now have several years of experience with agile teams: what are we learning about the success of these models?
Leadership for agility provides a framework for understanding the results we see. Our organizations typically comprise many smart, creative, opinionated people designing and building complicated new things in an uncertain context, making thousands of decisions that need to result in something that fits together and runs with few flaws. The leadership model emphasizes rigor (making fact-based decisions after considering multiple options), alignment (getting large numbers of creative, smart people all moving in the same direction), and efficiency (doing the above in a way that respects people and their valuable time).
Viewing this leadership model against team roles, here are 6 tips to make your efforts more effective:
1. Scrum roles are too simple. The simplest scrum models specify just a few roles: Product Owner (prioritizes needs), Scrum Master (facilitates ceremonies), and team members. More sophisticated models like SAFE add roles like “Release Train Engineer” and “Full Stack Engineer.” While avoiding over-specialization and consequent handoffs on the team is valuable, so can be specialized skills and experience. For the sake of rigor and efficiency, we need to cultivate experts. Lean product development emphasizes “towering technical competence.” What specialized roles make sense for your teams and your organization?
2. “Traditional” roles can still be valuable. New approaches introduce valuable new roles, but for much of our work, we can leverage proven roles (and proven people!) with decades of skill and experience. These roles can help drive rigor and efficiency. For example, systems analysts master the art of understanding and articulating incoherent business needs to enable unforgiving coding. Scrum typically subsumes this role in the Product Owner or undifferentiated team member. Don’t forsake expert roles like system analyst, test manager, or project manager just because the new methods don’t include them.
3. Missions, not tasks. Some scrum roles are overly focused on the tasks – e.g.; the Scrum Master conducts the specified ceremonies, the Product Manager prioritizes the backlog. To best enable leadership for agility, roles are better defined by their mission, not their tasks. Sure, the test manager develops the master test plan, but their mission is to ensure that the decision to go live is made with a full understanding of remaining defects. We want people to have the freedom to innovate how to accomplish their missions, leveraging all of their knowledge, skills, and teammates.
4. Many teams need a robust formal engineering leader. There is an agile principle that the best work comes from self-organizing teams. While this is ideally true, in practice, formal positions of leadership for engineering are often needed. I learned this from Toyota, where a respected senior engineer leads each new car design/engineering program. These chief engineers typically have few direct reports, are fully engaged with the team, and exercise leadership through influence, respect, and relationships with senior leaders. Several firms involved in agile transformations report that this kind of leadership position is struggling to emerge. The role is often called “lead developer” or “architect.” Consider making it a formal role to which the entire engineering team is indirectly or directly responsible.
5. Standardize team roles just enough; err on allowing diversity. The advantage of standardizing team roles is that we then hire, train, tool, and utilize them more effectively. Chief engineers aren’t typically employed or developed without specific intent. Standard roles also facilitate inter-team and management communication. A good example is a commercial software product firm that releases a few times a year to corporate customers. This organization has a dozen or more scrum teams sharing a common code base and release train. The test managers can all work together, as can the chief engineers and the scrum masters.
Beware, however, of the alternative case. When an organization doesn’t require such deep cross-team collaboration, let teams and leaders adjust roles as needed. Amazon is an excellent example of this approach — its API-centric approach obviates the need for team uniformity.
6. Formal reporting hierarchies still matter. Hiring, firing, career development, compensation — all most often remain a function of formal management hierarchies. As you design your agile organization, optimize the formal hierarchy to drive rigor, alignment, and efficiency. Should all team members report to the team leader? What if the team leader has a marketing focus: can that person effectively manage technical staff? Should product managers roll up to marketing, so there is a consistent view of the market? One sophisticated firm well into persistent product teams has morphed its formal organization structure around its teams, with all technically-focused team members reporting into the CIO organization and other team members into business lines. This works for them, at least for now.
What is right for your organization?
**Originally published at Real Leaders