Agile teams are structurally different than their waterfall counterparts. Agile teams focus on the team itself, where waterfall teams often follow the structure of the organization. In traditional waterfall development scheduling often is “top down,” meaning management sets the pace and schedule. In agile, the team is self organizing, and sets its own schedule and destiny within the larger organization. As I was learning scrum one of the questions that kept coming to mind was, “How do development managers and scrum masters share responsibilities in the team?” In this piece I’ll explore the answer to this question.
Waterfall teams vs. scrum teams
Most waterfall teams are manager centric. They look to the the manager to set priorities, track progress, and evaluate performance. Agile teams are self-organizing, and work with a product owner who sets the vision for what should be built, and is not usually in the management chain of the team. The team, through a series of sprints, drives how the product should be built.
Self-organizing teams own their destiny. In sprint planning they decide how much work to commit to the sprint, and because of that their level of ownership in the success of the program remains high. Engineers who own their own schedules build products of higher quality more consistently because they own their schedules. Engineers want to build high quality products on time, because everyone in the organization has the same goal. Tuckman’s stages of group development outlines how teams form and thrive. Self-organizing teams are no exception.
Mutual trust and candor are essential to well-performing agile teams. Management that continually focuses on hiring the right team is able to trust the team to get the job done. The need then to micromanage every detail of the team’s work becomes vastly reduced. The scrum master and the development manager then protect the team from outside distractions such as feature creep, waterfall anti-patterns, cross functional thrash, or side projects that will compromise the integrity of the sprint.
Role 1: Scrum masters
Scrum masters are the project leaders in agile teams who focus on optimizing performance of the scrum. Scrum masters work between the product owner and the team ensuring consistent, successful sprints by running stand-ups, and working to reduce blocking issues for the team. Cross-functional thrashing can be costly for teams, so successful scrum masters own cross-team coordination so the core team can focus on product development. This practice keeps everyone efficient and on the same page.
The scrum master coordinates most of the inputs and outputs required for an agile program. He or she drives the sprint kickoff, daily stand-ups, sprint review, and sprint retrospective. The scrum master is also an agile coach, helping the team to adopt and own agile practices throughout the product life cycle: story point estimation, sprint planning, and continuous delivery. The coaching aspect of the scrum master’s job is critical; He or she not only helps the team to be agile, but advocates for agile development throughout the organization, and spreads the good word about why agile development is right for the project and the company. Often times when agile methodologies are new at a company, the advisers and stakeholders outside of the team need agile coaching as well.
The scrum master works with the team and the development manager to estimate items in the backlog. At first, the team will need some guidance from the scrum master and development manager. As the team is forming it builds shared knowledge of the program through successful sprint planning. As the team moves into a performing stage the scrum master focuses less on estimation and more on optimizing the velocity of delivery.
Role 2: Development managers
There’s a lot of uncertainty for engineering managers when their team goes agile – an Admiral Stockdale moment, if you will. But despite the fact that agile development teams don’t rely on their manager for estimation and prioritization, managers still play a vital role.
The most important thing a development manager does is hire. You bring excellent people onboard and develop them within your team, everyone has the potential to bring significant value to your program. Why spend so much time on hiring the right candidate? Team changes are expensive on two levels:
- Searching for candidates takes focus away from building great product.
- When a new employees join, the existing team needs to spend time on-boarding them. Teams will experience a drop in velocity over a few sprints as each new person integrates into the team.
When a team is truly self organizing and performing well, everyone in the organization sees it through product quality and delivery. No one has more impact here than the development manager.
One of the big differences between agile and waterfall teams is that the development manager is a partner in the estimation process. In a waterfall team, a conversation like this wouldn’t be unheard of:
- “Hey, how long is it going to take to deliver this feature?” – Manager
- “It’s going to take six weeks. We need to do A, B, C to get the feature to market.” – Engineer
- “Hmm. That makes sense. However, you need to find a way to get it done in four weeks.” – Manager
But an agile development manager knows to hire great people, then trust them. One of the fundamental tenets of agile process are that those closest to the work are best able to scope and deliver. The team sets the schedule. The development manager adds unique value in inquiring and vetting assumptions made in the estimation exercise – partnering in the process, rather than dictating it.
While scrum masters focus on team velocity, development managers build up team members’ velocity by coaching individuals one on one. Development managers curate and inspire great talent in their organizations. Great managers are adept at the fundamentals of management: One on ones, giving feedback, and coaching their teams. Successful development managers mentor engineers to bring greatness to the table: ideas, code, tests, and culture. Great development managers partner with their teams. At times, the team will struggle or come to an impasse with architecture design decisions. Adept development managers know when to intervene to break the impasse or let the team continue to struggle to grow the team. The scrum master may not be as technical as the rest of the team – the development manager lends valuable context between the scrum master and the team when there is a clear knowledge gap.
In addition, they also partner with the senior developers in the company to set the development culture. They are often influential in the technology choice for the program, and continue to own responsibility for the quality of the product from the code architecture to the end-user experience. Development managers engage in code reviews to ensure team members are contributing code that meets the short and long term goals of the program. They also set context internally for the team and in the larger organization.
To learn more
We’ve spent a fair amount of time looking at what makes a great manager in an agile culture. For more information on how you can go agile, take a look at Do Agile Right at Atlassian.