How Agile Killed Managers

Once upon a time in a land far away every few developers and every few testers had a manager. Everybody wanted to be managers because they had power and were paid better. But only the best engineers became managers. Then they hated their jobs because they really just wanted to be engineers and didn't like dealing with people. Then Agile happened and POOF! the managers disappeared.

What happened to them? Continue reading to learn about different ways managers can become an obstacle during Agile transformation, and what they should do instead to help the teams grow to their full potential and be successful.

First of all, not all the managers are gone. Of course, scrum teams don't need as much supervision and control as individuals did in the olden days, so companies don't need as many managers as before. Some of the more technical managers return to what they do best: develop, test, design and create, establish standards and nurture innovation. In this new reality they can create more value by being technical leads, subject matter experts, domain experts or architects.

You don't need a title or direct reports to be a leader.

But for the remaining few the rapid change sweeping the workplace can be brutal. Uncertainty leads to confusion and fear, stress and distrust. Managers who don't understand the spirit of Agile, who cling to their titles and try to preserve the chain of command, can sabotage and hurt the Agile transformation.

What did the managers lose?

To understand what causes managers to be such a pain in the neck, let's see what happened to their roles. Here's what they lost:

• Clear lines of responsibility. Cross-functional teams erased the boundaries between development and testing, but many organizations still operate in the shadow of the outdated functional silos, in which developers report up to development managers, and testers to QA managers. Unclear lines of responsibilities lead to conflict, power play and agendas. As part of Agile transformation many organizations realign themselves to form engineering departments, in which all developers and testers report up the same chain on command. This eliminates the tension between development and QA groups, but can cause anxiety and insecurity for the managers, who now need to learn a new trade to support both functional areas.
• Power over individuals and business value. In the traditional "command and control" model the manager decides what needs to be done, assigns tasks to individuals, monitors the execution and reports the status up the ladder. In Agile world, the responsibility over the business value (what to do) belongs mostly to the product owner, whereas the knowledge about what needs to be done to achieve the goal (how to do it) lays within the team. The managers in this model can feel excluded and out of control.
• Technical expertise. Today the managers are not expected to be domain experts or technical gurus. It is still great for a manager to have technical background, but it's far more important to be a leader, have a vision, serve the teams and individual employees, and help them grow to their full potential. This transition can be hard for those who used to be a single point of decision making in all matters technical.
• Metrics. This can be extremely painful for people who used to do what we call project management. In the traditional SDLC the project work is highly quantified through percent complete on each phase of the project, key performance indicators, scorecards, project plans and financial forecasts. It can be argued that these metrics give a false sense of visibility, but not having metrics at all causes a lot of anxiety.

How managers can abuse Agile

We all heard horror stories about managers destroying Agile. They do it because they try to preserve everything they had, which is now lost forever (control, power, influence, metrics) and are insecure about their own future. All management dysfunctions in Agile environment stem from fear and distrust, and the only way to overcome them is through learning, coaching and cultural change.

First line managers need the same amount, perhaps even more Agile coaching than the scrum teams.

Here are some examples of management decisions and actions that are damaging and counterproductive. If you know a manager who does this, be patient and remember - they are in pain and need help.

• Constantly move people in/out of teams. Being agile means accepting the uncertainty and being ready to adapt and adjust the course if needed. The team, however, is in the center of this process and should be kept as constant as possible. Moving people in and out, creating partial allocations and temporary team members will never allow the team to come together and start performing.
• Give individuals assignments outside of their team role and scope. Treating people as resources that can be easily moved between projects is wrong. Planning projects around existing teams is a much better way of creating roadmaps.
• Undermine or disrespect team's decisions. Probably the most certain way to dis-empower and alienate the team.
• Forcefully change the sprint scope during the sprint. Same as the above, only in this case the manager acts aggressively not only towards the team, but also the product owner.
• Measure velocity as an improvement target and compare velocity across teams. Focusing on numbers leads to inflation. Teams can easily game the system by creating bloated estimates or closing stories before they pass the definition of "done".
• Track the "estimated" hours vs "actual" hours. Another fool-proof technique to turn the team's estimates into completely meaningless numbers that only serve the purpose of being "on target" and nothing else.
• Worry about people being underutilized. Remember, high utilization represents high risk. As utilization approaches 100%, the throughput time increases exponentially, which means that every simple task now takes forever to complete and nothing gets done.
• Reward individuals who exhibit anti-team behavior. The classic article "On the folly of rewarding A, while hoping for B" was written in 1975 by Steven Kerr. 40 years later it's still not uncommon to praise individuals who make decisions without discussing with their teams, hoard knowledge and generally refuse to collaborate.

How managers can boost Agile transformation

The good news is, it's not hard to be a great first-line or middle manager in Agile environment. All it takes is to understand that some of the former manager's responsibilities now belong to the team, but there's so much more that can be done to reinforce Agile principles, optimize processes, improve technology, create synergy within the team, and maximize business value.

Here's what a good manager could do to help the team be successful:

• Build teams wisely. It is still the manager's responsibility to make hiring decisions and design teams. It might be a great idea to use team's input during the hiring process to ensure acceptance and cultural fit.
• Make sure the team gets all the training, mentorship and coaching they need. It's great if the manager can act as a coach him/herself, but they can also hire experts, pay for courses, certifications, books and other materials.
• Trust the team and stay away from their daily process. Trust is the biggest gift a manager can give to the employees. The only way to build self-organized team is to let the team to organize itself, establish its pace and master its processes.
• Protect the team from disruptions during the sprint. This might sound as an unexpected suggestion, but sometimes the team needs protection from an over-eager product owner. Development is a creative process that requires focus and sometimes it's just a matter of getting into the zone and not being distracted by phone calls and meetings.
• Identify and eliminate waste, drive for lean processes and practices. Any manual process or step in the process is a waste. Invest in automation, innovation and technology updates. Identify gaps, facilitate and brainstorm solutions, setup priorities, get funding, allocate resources and follow through with the execution.
• Reward teams and individuals wisely. Creating incentives, boosting morale and rewarding positive behavior can be tricky, but the secret of balanced approach is simple: managers should recognize both teams and individuals, depending on the situation and nature of the reward. Recognize teams for job well done, projects completed on time, high quality and successful deployments. Praise individuals for their creativity, leadership, unique ideas, technical or process-related improvements, proposed or implemented outside their job description.
• Create opportunities for growth. A rotating role of scrum master is a great opportunity for the team members to try themselves for a job that requires to facilitate, coordinate and help others to collaborate. Those who like it can one day become managers themselves.
• Identify the team's weak spots and come to the rescue. There are certain telltale signs and anti-patterns that can be easily identified through a careful observation of the team's artifacts: inconsistent velocity, over- or under-committing, carry-over, scope creep - these are just a few examples of symptoms that can expose a potential issue within the team. The manager can be an Agile coach, or bring an Agile coach to diagnose the problem and help the team to get better.

Did you like my post? Please like or share with your network. Follow me to read my posts and send me your questions about practical Agile.