As organizations have transitioned to agile projects and programs, what happens to the managers? Do we need managers any more? If so, what good would they do?
Yes, we need managers. And in a truly agile organization, where the managers are freed from the day-to-day tactical project tasks, we need them more than ever as organizational leaders: setting strategy, managing the project portfolio, removing organizational obstacles, building trusting relationships with technical staff, coaching, providing feedback, assisting with career development, leading the hiring decisions and process, and building the capacity of the organization.
Technical leads, project leaders, ScrumMasters, program managers — whomever it is that facilitates the project team’s or set of project teams’ work — cannot perform all those functions. In fact, it’s not a good idea for people who manage a project to both manage the people and participate on a project. Project work is tactical. Management work is strategic. In an agile organization, managers have the opportunity to be strategic;the never-ending project risks, issues, and problems do not distract them. Attempting to mix the tactical and strategic work means the person will only pay attention to one kind of work.1 Most often, that work is the tactical work.
So, let’s examine the role of the manager in an agile organization. Agile managers provide true leadership— directing the organization, guiding the people, and making those difficult decisions that help the organization prosper and grow.
MANAGERS DECIDE WHEN THE STRATEGICALLY IMPORTANT WORK STARTS AND FINISHES
One of the leadership roles required in an organization is managing the project portfolio. Deciding what work to do when, and reevaluating that decision at periodic
intervals, is a leadership role; it directs the organization to work on the most valuable work at the time.
In a more traditional, serial-lifecycle organization, it’s difficult to know when you can replan the portfolio. It’s too easy to allow — and almost impossible to prevent — emergency projects from running the organization. That’s because you can’t predict the end of the project. Even if you execute the project perfectly, the users or customers may not know what they want until they see what the project team provides. So instead of a six-month project, you end up with a nine-month project.
With an agile lifecycle for your projects, you can decide on a regular basis when to commit to which project and for how long. Do you need to decide as often as an iteration? Can you wait longer, say, up to a quarter’s worth of work to decide? That means you can refine the organization’s strategy periodically as you manage the project portfolio. Freeing managers from tactical project work means they have the time to make strategic decisions, avoiding management debt.
The Perils of Management Debt
When managers don’t decide which projects to fund, in which order, and for how long — and equally important, which projects never to fund — they create management debt. The lack of decision making is the debt. The longer it takes to make a decision, the more debt you take on. You can see in Figure 1 the chaos that ensues when you don’t have a project portfolio. (2)
Look on the right, at the balancing feedback loop. The more competition for people’s time, the more you perpetuate the number of emergency projects that start, which reduces the ability to manage the project portfolio and increases the overall competition for people’s time on a given project. That reduces everyone’s ability to finish projects quickly, which reduces the number of completed projects, which increases the number of new projects that start, which increases the number of active projects. The whole system perpetuates itself through the reinforcing feedback loop, causing chaos and lack of completed work.
Not only does it cause chaos and prevent people from finishing projects, it prevents the organization from fulfilling its strategy. Without completed projects, you can’t implement or change the strategy.
This chaos makes it more difficult, and sometimes impossible, to make decisions about what to do first, second, and third. That’s where the lack of decision making earlier — management debt — shows up. If you have a ton of projects, all ongoing, none of which is making the progress you want, you have to make more difficult decisions now.
Maybe you had encountered this problem of competing projects, all of which were important, most of which were urgent, when you decided to move to agile. The focus of the timebox provides people an opportunity to say no to concurrent work, which gives you a dynamic such as the one shown in Figure 2 (3).
Without multiple projects competing for people’s time, the project team completes projects. This allows new projects to start because some projects have finished,
and managing the project portfolio becomes easier. Not only is it easier to make project decisions; it’s also easier to see whether a project fits with the organization’s strategy, which reduces management debt. Once you have a regular opportunity to redecide on the work, managers can take a strategic and periodic approach to their project portfolios, stabilizing the system.
Moving to Management Iterations
When project staff complete projects — or complete them enough to release — managers have the opportunity and obligation to refine the project portfolio. Managers now have a cycle to their work: iterations. Iterations are wonderful for strategic planning. Strategic planning isn’t something that happens once a year or once every five years. Smart managers recognize that their business needs fine tuning, if not adaptation, more often than once a year.
When the project teams complete work periodically, the demos and the customers provide data to the managers. You might not like the data — “We won’t use that product. Yes, it works; no, we won’t use it” — but you have it. Managers can use the data to make strategic decisions about killing or transforming the project. Managers can also use iterations to address the organizational obstacles, make small changes, and evaluate the effects of those changes. All of this frees the project team to focuson the work. Because managers focus on the strategic decisions and the organizational obstacles and needs, the team does not have to.
LEADERSHIP MEANS REMOVING OBSTACLES
Once managers no longer have to deal with the tactical project issues, they can decide when to take on organizational obstacles. One of the biggest obstacles to team work is the HR system of individual reviews.
Individual Reviews Do Not Build Relationships
There is a growing body of evidence that supports throwing out the individual review system. Stanford University business professor Jeffrey Pfeffer (4) and author
Alfie Kohn (5) have shown that individual reviews do not provide the incentives the conventional wisdom says they provide. Furthermore, individual reviews are not a measure of objective performance, and they imply that the manager, not the employee, is in control of the employee’s performance.
In fact, individual reviews prevent teamwork — precisely what an agile organization requires. You can think of an employee having two contracts at work: the offer letter, or legal contract, and the social contract — the informal, not-discussed agreement with a manager to create a trusting relationship.
Genuine and timely feedback reinforces the social contract. Yearly feedback, especially feedback that is coupled with money, breaks the social contract. The social contract is all about internal motivation; yearly money “incentives” are about external motivation. Individual reviews break the social contract between the manager and the employee by making the work about the money instead of keeping the money as just part of the equation. Individual pay for performance also creates a zero-sum game. If the total pool of raise money is fixed, then if I get some, that’s money you can’t have.
If you are one of those managers who says, “OK, I agree, but what do I do instead?” here’s what you do: build a trusting relationship with each member of the team, share the strategy, share the organization’s profits, and provide cost-of-living raises to the team. The team members take care of feedback to each other. Once the management team relinquishes the idea of the fixed performance contract,(6) the project team members can internally commit to their work.
AGILE MANAGERS BUILD TRUSTING RELATIONSHIPS WITH THEIR TEAMS
In First, Break All the Rules,(7) management consultants Marcus Buckingham and Curt Coffman report that an employee’s relationship with his or her manager is key to that employee’s success and long-term happiness in the organization. Moreover, if people have friends at work, they are more likely to be successful and happy at work. In an agile team, it’s easy to build camaraderie among team members. But if a technical person’s primary affiliation is with his or her colleagues on an agile team, how does a manager build the relationship key to retention?
Managers in agile organizations must become the champions for their teams. That means we no longer can afford functional managers, such as development or testing managers. Instead, as the teams are crossfunctional, the managers also need to be crossfunctional, able to manage developers, testers, writers, database administrators, writers, business analysts —whoever is on the team.
To function as the team champion, the manager has to learn about each team member. That means a weekly or biweekly one-on-one (8). More often than once a week, and not enough has happened in the project; plus, it’s too easy for managers to fall into micromanaging. Less often than biweekly, and the manager is not taking the time to learn about how the employee is working on the team, what areas the employee wants to explore for career development, and how to offer help solving the human and system problems. Regular one-on-ones help managers see system problems: when a product owner doesn’t want to allow time in an iteration for the team to support previously released products, when there are issues in a specific product area, when the team has trouble estimating because they don’t quite know the acceptance criteria or because the criteria change, and more. It’s hard for a manager to understand what’s really happening at work (9). One-on-ones make it easier for a manager to understand the business — not the strategy, but how the teams build the products to implement the strategy.
The team solves the project problems. However, team members may not have enough practice to recognize when they are encountering a system problem — an obstacle — or know-how to manage a human interaction problem. Managers can recognize system problems and help solve them.
Managers Provide Feedback and Meta-Feedback
Managers provide team members with feedback and coaching, and they provide meta-feedback (i.e., feedback about how to give feedback) and meta-coaching (i.e., coaching about how to coach). Let’s face it, few of us started in software because we thought we would have the opportunity to work with people all day long. Most of us are products of a university education where we had few group projects, and certainly none of them were longer than a few weeks’ duration. Working with a group of people, day in and day out, iteration after iteration, is bound to help some people build great relationships. It’s also bound to make problem relationships
If you know only how to give feedback by saying, “That’s brain-dead,” you may have limited success working in a team. If you learn how to express your concerns without labeling, and you have someone to practice with, you are more likely to navigate conflicts successfully.
The agile manager is ideally placed to help provide metafeedback and metacoaching. If the manager has one-on-ones with each person on the team, the manager will hear about the intrateam issues and can ask if an employee wants help solving the problem. Or if the manager hears about an issue, the manager can raise the issue with the employee.
Softening Steve’s Rough Edges
A manager, Tina, is responsible for an agile team. Tina and the team have recently hired a new tester, Steve. Steve graduated three years ago from a prestigious university. He’s bright, has some great ideas about testing, and is able to pair with developers when the project needs developer-tester pairs. However, Steve has a habit of saying, “That won’t work,” if he hears an idea he’s never tried. Since he only has three years of experience, there’s a lot he hasn’t tried.
One day the entire team, including the product owner, got together to nail down a high-level design decision. They’d implemented and tested a few features in that area of the product, and they were reviewing their design to see whether it would scale to their anticipated features. Don, a developer, had an insight about where
the design could head, given what the product owner had as ranked features for the next few iterations. Before anyone could discuss Don’s idea, Steve jumped in and said, “That won’t work.”
Tina asked, “Why?” Steve replied, “It just won’t.” Later, after the meeting, Tina asked Steve if he had a few minutes to chat. They walked to a small conference room, and Tina said, “Steve, do you remember when I asked you why you said that design wouldn’t work, and you said, “It just won’t”?
“Yeah. I still don’t see why we’re doing this spike to try it. I’m convinced it won’t work.”
“Can you explain why?” asked Tina.
“No, I’m just positive it won’t,” replied Steve.
“Steve, when you say, ‘That won’t work’ and can’t tell me why or propose an alternative, I feel as if you’re rejecting something for no good reason. That may not
be why you’re rejecting the idea, but that’s what it feels like to me. If I were a different person, I might feel as if you were rejecting me, not just my idea. Can you see how I might feel that way?”
“Yes, but you shouldn’t.”
“Maybe I shouldn’t, but I do.”
“I’ve noticed that you have a tendency to first say something won’t work. But I’ve also seen enough of your work to know that as soon as we’re done talking, you’ll be back with Don, working with him on how to make it work! And when I’ve seen you do this before, it looks as if Don has trouble working with you. Does that happen?”
“Yes, it’s as if he has all the good ideas and I have none.”
“Well, can you see how Don might be annoyed if your first reaction to his idea is ‘It won’t work?’”
“I guess so.”
“So, I’m concerned with your statements of ‘That won’t work’ when someone brings up a new idea. Do you think you can come up with another way to express your reservations?”
Tina and Steve discussed this for a while, and Steve finally decided that he could say any of these things:
- “I’ve never seen that before,” which was true.
“How do you see that proceeding?” when he couldn’t see the next step.
- “What made you think of that?” in a nice tone of voice when he couldn’t follow the other person’s logic to its conclusion.
Tina’s ability to provide feedback and coach Steve into new behavior made him much more of an asset to the team.
Human Problem Solving
Many of us work in IT because we love solving technical problems. We hone our technical problem-solving abilities, not our human problem-solving abilities. That means that we are often blind to the real issue. A caring, trusted manager who is more of a coach than a controller can help people learn to give and receive
feedback. By doing so, the manager acts as a coach, removing team obstacles.
Managers Provide Career Development
Some people attempt to plan their careers; others don’t. Yet each person needs to use feedback about his or her strengths and decide what to do next. The manager can act as a sounding board or mentor to a person who is deciding how and where to take the next step in his or her career.
Career development is rarely linear. People experiment with different roles at work. It’s even easier to experiment on an agile team, where the team members are generalists. A manager — one who is not responsible for a specific iteration’s goals but is responsible to the organization — can suggest alternatives for a person to take on different responsibilities.
For example, a developer who would like to be an architect might need the chance to be an architect on a local agile team and be the representative to an overall architecture group for a program. A tester who wants to be a manager might try the facilitation role of ScrumMaster first. A business analyst who wants to be a product manager or potentially a product owner might work with a product owner more closely.
In one-on-ones, managers can see whether the employee has leanings toward management and that kind of strategic thinking. A manager who is a team champion
can constantly look for and encourage career development for the entire team. That helps people manage their careers and increases people’s capabilities, thereby increasing organizational capacity.
BUILD ORGANIZATIONAL CAPACITY
One job of a manager is to help people in the organization learn to be more productive in their jobs. This is not flogging people to do more; it’s about helping people learn how to work better. As we’ve seen, the first thing a manager can do to build organizational capacity is to remove obstacles.
Managers Remove System Obstacles
When project teams move to agile, they encounter many obstacles. Some are technical: the builds take too long,they don’t know how to unit test without database access, their legacy product has insufficient automated tests. Some obstacles are about where people are located or that the team is missing some key capabilities. But more obstacles are about the system in which the project teams find themselves.
Managers fix the system to remove obstacles for their teams. If the furniture police say, “No, you can’t have a team room,” or senior management insists that everyone has to be stack-ranked, or HR insists, “We must have individual performance evaluations,” the system will prevent project teams from delivering their best work.
Removing these obstacles requires perseverance, influence, and negotiation. Lower-level managers may not be able to effect all of these changes. Middle managers may have a shot at changing the system for their sphere of influence. Only senior managers can change the whole system — and that’s if they want to.
Still, it’s worth a manager’s time and energy to choose an obstacle, chip away at it, and remove it. As the manager makes things better, the team will respond with better productivity.
Team Velocity Is Personal
Team productivity is literally the number of running, tested features the team can produce in a given time period. It’s tempting to compare teams, but the problem is that feature sizes are not normalized. Even if you use points as a measure of productivity, each team counts points differently. Team velocity is personal. You can’t compare teams (10).
While team velocity is not comparable across teams, you can see a team’s velocity over time and ask some questions. You can expect a team new to agile to stabilize
and then increase its velocity over several iterations. In my experience, it takes somewhere around five to seven iterations for a team to discover its velocity. It
takes another three to seven iterations for a team to arrive at a normal velocity. If the team’s iterations are four weeks in duration, that’s up to 14 iterations — more than a year until you can tell what a team’s velocity is. That’s one reason I prefer two-week iterations. The team and you can learn even more about how a team works in much less time. The team can’t accommodate obstacles, so you may have more work as a manager; however, you can see the value of removing obstacles sooner.
So even if you give a team 12-15 iterations to improve its estimation practices and ability to decrease story size, how can you know if a team is more productive than it was before? Ask about the ease of performing the work (11). You can ask this in your one-on-ones.
A team should, at some point, find that it’s easier to finish stories. Over some number of iterations, the team should have this environment: builds are automated, the automated tests provide quick feedback, the stories are smaller, and the team is better at estimating. All of these improvements provide more ease to people working on the team.
Sometimes, even if you remove obstacles, the team doesn’t accomplish more work or have more ease in its work. Sometimes, the team needs more people.
LEAD THE HIRING WORK
Leaders don’t hire people alone. They start the hiring process and bring others in, so that the team has control over who is on the team.
Managers lead the hiring process by:
- Creating a hiring strategy
- Developing a job description for team review
- Developing the phone screens
- Teaching team members how to do phone screens
(or doing the screening for the team)
- Organizing the in-person interviews
- Facilitating the post interview decision
- Checking references
- Making an offer
Most project teams I’ve encountered prefer that the manager lead the hiring process. They don’t want to write job descriptions or check references. Some teams prefer phone-screening candidates. All the agile teams I’ve worked with want to be highly involved in interviewing and deciding on candidates.
Managers may have to teach teams how to interview effectively and how to come to consensus on whom to hire. Otherwise, managers can serve the team by doing the hiring.
AGILE MANAGEMENT IS LEADERSHIP
Leadership is about setting the direction and paving the way for the organization to move in that direction. Agile managers set direction by managing the project portfolio to carry out the organization’s strategy. When people know which project is first, second, third, and so on, they will make good decisions. They won’t interrupt people on the highest-ranking projects with lower-ranking project issues. That helps everyone finish those higher-ranking projects.
Once everyone understands the direction, the technical staff is free to focus on the work. As long as management does not reinforce the idea of a single person’s pay
for performance, agile teams will continue their collaboration and teamwork. Even if an organization cannot embrace the concept of eliminating individual reviews, a trusted manager can manage some of the individual versus team problems by allocating group bonuses and group objectives that the group has control over. When an agile manager builds a trusting relationship with each member of a team, and helps each person learn to give and receive feedback, the manager helps the team manage its human interactions better. And by working on career issues with each person every week or biweekly, the manager helps each team member reach his or her capacity as an individual.
An agile manager acts as a champion for the team. These managers remove system obstacles and help the team realize if they are missing knowledge or people. If they are, the manager can help arrange education or training opportunities for existing staff and/or lead the hiring of more people.
Having curiosity, the ability to change the organization, and confidence to teach are the hallmarks of a great leader (12). When the manager champions the team and supports the team, the manager is a leader. Agile development demands that we have leaders — generalist managers who work for the team. Are you ready?
- Rothman, Johanna. Hiring the Best Knowledge Workers, Techies, & Nerds: The Secrets and Science of Hiring Technical People. Dorset House, 2004.
- Rothman, Johanna. Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects. Pragmatic Bookshelf, 2009.
- Rothman. See 2.
- Pfeffer, Jeffrey. The Human Equation: Building Profits by Putting People First. Harvard Business School Press, 1998.
- Kohn, Alfie. Punished by Rewards. Houghton-Mifflin, 1993.
- Hope, Jeremy, and Robin Fraser. Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap. Harvard Business School Press, 2003.
- Buckingham, Marcus and Curt Coffman. First, Break All the Rules: What the World’s Greatest Managers Do Differently. Simon & Schuster, 1999.
- Rothman, Johanna, and Esther Derby. Behind Closed Doors: Secrets of Great Management. Pragmatic Bookshelf, 2005.
- Pfeffer, Jeffrey. What Were They Thinking? Unconventional Wisdom About Management. Harvard Business School Press, 2007.
- Rothman. See 2.
- Marick, Brian. “Two Forgotten Agile Values: Ease and Joy.” Exampler Consulting (www.exampler.com/ease-andjoy.html).
- Pfeffer, Jeffrey, and Robert I. Sutton. Hard Facts, Dangerous Half-Truths and Total Nonsense: Profiting from Evidence-Based Management. Harvard Business School Press, 2006.
© 2010 Johanna Rothman. This article appeared in Cutter IT Journal, March 2010, Vol 233, #3, pp. 21-27
Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.