The Manager's Role in Agile

23 July 2008

Michael Spayd
Agile Coaching Institute

Lyssa Adkins
Agile Coaching Institute

What role does management play in the agile world of self-organizing teams? What is the function of managers in this new world? What does an agile organization need from its management team? Where should the agile manager focus their efforts for greatest benefit?

In a general sense, an agile manager is responsible for the “gray area” surrounding agile teams and throughout the organization.

This gray area can be divided into three large categories: managing teams, managing investments, and managing the organization’s environment. Within these three categories, eight clear competencies have emerged from our research and experience with fully engaged agile managers. These competencies can be mapped to the categories as follows: (Note: the meta-competency, organizational change, applies to all three categories and is listed and discussed separately.)

Managing Teams
Agile team management
Resource management
Performance management

Managing Investments
Managing through metrics and reporting
Agile portfolio management

Managing the Environment
Internal partner management
Supplier managemend and outsourcing

Organizational change

Perhaps unsurprisingly, the competencies are not revolutionary. In fact, they are largely similar to what most organizations expect of their managers. The big difference is one of style, though in this case the style has real substance. agile managers coach, inspire, and lead teams more than they measure and manage them. They focus on the organizational environment’s ability to deliver value more than they worry about their department’s own measurements.

An agile manager’s effectiveness in these eight areas is further helped (or hindered) by her personal leadership style, the company culture, and her ability to enact the competencies in an agile-values-based way. Knowing oneself deeply, and having an understanding of these style and culture dynamics, is essential.

Managing Teams: Self Organization Meets Leadership Intelligence

For the agile manager, teams become a fundamental object of study: how they work and develop over time; how to form them and nurture their growth; and how to measure, reward, and sustain them for the long term. The agile manager’s domain is as intimate outsider and champion of the team, not as inside micromanager or chum.

Agile Team Management

Agile teams do not need managers directing their work. Instead, the manager’s role is to set the team up for success and then support from the outside – from the boundary of the team itself. Teams need sponsors outside their boundaries who can champion and cheer them through their challenges. An agile manager’s goal is to enable the team to solve its own problems and come up with its own amazing insights and products. Skills such as assessing team health, removing organizational impediments, making room for failure, and having the ability to coach become central.

Resource Management

Agile processes value getting work done over having items in progress. The question for an agile manager becomes, “How can I array people to best increase throughput?” rather than, “How can I maximize ‘my’ people being utilized at 100 percent?” Assessing the organization’s current resource management model will help the agile manager understand its (often negative) impact on agile teams. By understanding both the downsides of task switching between projects and also the team dynamics of forming and developing over time, the agile manager is in a position to formulate a new resource management model that helps strong teams form and stay together for continued value delivery.

Performance Management

Motivating teams, rather than merely individuals, becomes key for the agile manager. Working to change performance measurements to complement, rather than contradict, agile values is an important new goal. Even so, performance management for agile teams is about more than handling the annual or semi-annual performance management cycle with dexterity. The agile manager synchronizes with the cadence of the inspect-and-adapt cycle, helping performance feedback to teams and individuals become rapid, relevant, actionable, and open.

Managing Investments: What is the Best Investment Now?

In the pursuit of delivering the most business value possible to gain competitive advantage, the agile mindset regarding managing investments is, “What is the best investment now?” rather than, “Are we on schedule and on budget?” Getting the most from agile means moving from the conformance-to-plan paradigm to conformance-to-value thinking.

Managing through Metrics and Reporting

An agile manager harnesses the metrics coming from the team and product owner both to help the team improve its own throughput and also to inform executives about how the teams are conforming to value. This requires a new mindset for using metrics, a new set of updated executive-style status reports, and a new ability to address the changes in conversation that occur when executives become engaged in reacting to and enabling business value delivery rather than handing out carrots or sticks based on stoplight views of scope, schedule and budget.

Agile Portfolio Management

An agile manager leverages the portfolio management and governance process to reinforce agile values: the ability to maximize value while embracing feedback and change. Generally, a more frequent cycle becomes essential as management begins to manage the portfolio of projects just as a product owner manages a portfolio of stories. In both cases the goal is to make frequent planning cycle decisions regarding which projects to stop, start, or continue based on which will return the highest business value now.

Managing the Environment: Helping the Organization Think Lean

Agile teams operate within an overall organizational environment that includes support processes and suppliers. As agile teams begin operating with newfound speed and agility, the rest of the organization tends to slow them down. The agile manager is in the position of bringing a lean perspective that focuses on flow and the elimination of waste.

Internal Partner Management

Managing internal partners, such as finance, governance, real estate, production support and others, requires thinking (and acting) like a lean manager. An agile manager uses lean skills such as value stream analysis and kaizen to achieve a deeper understanding of what motivates internal partners. Through this, an agile manager leads (or provokes) activities to “lean-out” the end-to-end processes in which their teams participate so that the value their teams deliver can be realized without delay.

Supplier Management and Outsourcing

For the sake of value delivery, agile managers treat their suppliers like they are an extension of their agile teams. To do this well, an agile manager uses new perspectives and techniques when crafting contracts with suppliers and knows strategies to help teams cope when suppliers will not work in an agile manner. An agile manager also knows that the decision to outsource a function of the team is purely a business call.

Given the reality that outsourced functions generally create a velocity drag on agile teams, a manager will carefully weigh the benefits and costs before pursuing an outsourcing model and will empower teams to adjust the model to reduce velocity drag.

Managing Organizational Change: Putting It All Together

For an agile manager, organizational change management is about being an organizational change artist. Affecting existing performance management systems, working with peer managers to lean-out business processes, and saying “no” to starting more work are all typical examples of thorny organizational impediments that an agile manager will likely face.

When agile is introduced into an organization, a tremendous amount of organizational change must occur to empower and enable agile teams in their pursuit of delivering business value. An agile manager needs to develop keen skills in organizational change and an ability to shepherd an organization through the adoption change curve.

Health Check for Agile Managers

The agile principle of inspect-and-adapt applies to agile managers as well. To that end, we’ve devised a few questions agile managers can ask themselves to see how they measure up to the full expression of the agile manager role.

  • Are you catalyzing organization change to support agile values, starting with marshalling a culture of value delivery?
  • Do you provide significant organizational roadblock removal for agile teams? Do they perceive you as a coach and leader more than as a manager?
  • Are you able to effectively distribute resources across teams to maximize team value delivery, rather than striving for resource utilization per se?
  • Is your performance management system helping guide teams to their highest performance, while fairly evaluating both individual and team contributions?
  • Do you use metrics to help teams improve their performance and to help senior leaders make decisions that improve value delivery?
  • Does your organization make frequent project portfolio decisions based on value rather than conformance to schedule and budget?
  • Are you helping your internal partners create lean processes to synchronize with agile teams, rather than tolerating their velocity drag?
  • How are suppliers encouraged to work in an agile way? Does your outsourcing help or hinder your agile teams?

Exploration and Learning at Agile 2008

Want to know more? A workshop on agile managers will be held in August during the Agile 2008 conference in Toronto. The final results also will be made available on the AgileManager Yahoo! Group. Check it out.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.5 (2 ratings)


Bent Myllerup, CST,CSC,CSP,CSM,CSPO,REP, 7/28/2008 6:56:25 AM
Thanks for at well written article that states good points of reflection regarding the change of the manager role when tuning in on Scrum.

I think that managers shall be aware that their role rather should be leading and coaching teams than managing teams. ThatΓÇÖs why I dislike your use of the term ΓÇ£Managing TeamsΓÇ¥ and I find it in contrast to the messages in the article. I do have been very fund of the phrase: ΓÇ£Self Organisation Meets Leadership IntelligenceΓÇ¥. In some way it says it all: Leadership Intelligence means (among other) that the leader is aware of the stage of the team (is it a new formed team, a mature and well performing team or something in between?) and determine what actions is appropriate according to the current situation.

To bad I can’t make it to the workshop in Toronto – it would have been great fun to attend…
Kevin Newsom, CSM, 8/1/2008 9:37:31 AM
I am curious as to what these metrics are, that would be used in performance management. One of my challenges is that I'm being asked to answer the question, "How do you know you're getting better?" We've been agile for almost two years now. How is it possible to show metrically that we're making continuous process improvements?

Duncan Campbell, CSM, 8/2/2008 7:32:34 AM
In response to Kevin's comment, I can think of several ways to measure process improvement.

But the fundamental point is that you can easily identify process changes due to the sprint retrospectives. In the retrospective you ask what went right, what went wrong, and what to do better (and how). The issues identified as what to do better become action points to be reviewed in the next retrospective.

Given that you have the regular question "What went right?" you can use that as a basis for quantifying by how much things improved. Though this leads you into the realm of lies, damned lies and statistics, so tread carefully. Any kind of comparison has to be valid, comparing valid data.

You can compare defect rates, turn-around times, customer satisfaction, etc. but all of these comparisons must take into account a multitude of factors for them to be relevant.

Perhaps a more important question is, how would the process changes which happen because of using Scrum compare to the process changes that might happen if you were applying an alternative methodology? Where would process improvement come from in an alternative methodology?
Kevin Newsom, CSM, 8/4/2008 6:04:35 PM
Thanks, Duncan. Scrum is a given for us, so I'm not sure what I get by comparing it to some other methodology. I'm being asked for numbers. I can say that 'things are getting better' from the retrospectives but again, how much better?

I think I've settled on Running Test Features as the best metric I can obtain. Certainly defect rates is also a possibility. We can show this information as trends over time. This should give us some sense of improvement.

I've begun pushing back on trying to measure productivity.

We cannot measure outcomes as we are not capable of determining the ROI of any given development initiative.
Andy Murthar, CSM, 9/1/2008 9:44:09 AM
Kevin,one way is to see an improved velocity. After 2 years this information should be at hand. If requirements gathering, estimating\planning, retrospectives are improving , it is suggested velocity will improve also. testing measurements merely shows improved quality. i suppose it depends what the metrics are for improvement. As a rule i monitor velocity, quality and a 'feel' relative to staff satisfaction, teamwork values etc. I am a scrummaster\project manager, so after that i let the it technical manager defend the information i provide:) and boy, does it get agile at thet point.
David Harris, CSM, 9/10/2008 4:26:45 AM
Hi Kevin, looking outside of the internal delivery stats you may be able to find (defects, testing, velocity etc.)... I wonder, for example, if the staff retention rate in your team(s) has improved over the last 2 years since you have been using SCRUM? Also, your customers may be able to assist with metrics (ratings at least) highlighting areas of your improvement in delivering services over time from their perspective. If you don't already use customer surveys,you may want to institute them for the future so they can help you answer the "How do you know you've improved?" question from their business/customer perspective.
Gil Rooke, CSPO, 9/22/2008 10:57:52 AM
Andy,I am puzzled by your concept of looking for improved velocity. As represented to me, velocity is purely relative related to the one project. The next project may decide that each story has on average twice as many story points. That does NOT matter, because they will just have twice the velocity. Of course, it hits the start of the second project, but very quickly settles down at twice the velocity. Of course if the second project is four times as big, then the new velocity may be half that of the first project. There is NO measure in there of any improved performance. Of course, if the team has improved by a significant amount, the velocity will be higher but you will NEVER know. Even if it is the same project still running two year later, you cannot tell whether their estimating standards are NOT just drifting, or whether they are improving. I think that the other value judgements you suggest (quality, staff satisfaction, teamwork etc) are very relevant. I would add 'Customer Satisfaction', which I assume you have included in 'Quality'. However, There is nothing in there that says your teams are producing more software per buck, except 'velocity' which is a very weak measure.
Scrum seem to be excellent at bringing a single project or product line into sychronisation. However, to get the absolute view you need, and the initial size estimate that a Product Owner needs is NOT covered. They both rely on absolute and NOT relative measurements. I cannot see how we can do either of these tasks without a subtle mix of experience and guess work. Can anybody contradict this please?
Jorge Almeida, CSM, 10/27/2008 10:48:53 AM
The issue raise here by Kevin, is very interesting, as I have serious difficulties also in finding any figures that can be used as a definite prove about the value of Agile. At the beginning of my experience of the introduction of Agile, often the more upper management asked to the Agile coaches / advisors to present figures that shows that after some time the Agile methods really added more value ( in here you should read money) for the company.
Armond Mehrabian, CSM, 9/18/2012 3:17:27 PM
In many organization that I coach, the first line managers have the tallest hurdle to clear when moving to the Scrum framework. Many first line managers are former tech leads who were on the job long enough to "warrant" a promotion to the manager rank. In this role, they still write a lot of code and view their teams as their hands and feet. They are totally unprepared and, as a rule, unwilling to abdicate their hands-on role to become a coach to the team. They feel that they have worked extremely hard and sacrificed a great deal in order to get to where they are and are not willing to abdicate their role. To make matters worse, the management team, in many cases, wants a "strong" manager to remain in charge of the "self-managed" team to ensure the successful, on-time delivery of features.
This is a conundrum for organizations; on one hand they view these managers as indispensable to their product delivery organization because of their tenaciousness, reliability and deep knowledge of the product but on the other hand they realize that as long as these type of managers remains in charge of the team there is no hope of the team ever becoming truly self-managed. How can this organization work through this difficult but common situation?
Justin Kwak, CSM, 10/1/2012 1:23:24 PM
Many people initially think that agile is a new concept or a new freshly created methodology. Theoretically it should show significant improvement in a typical development environment as a result of "switching" to this latest and the greatest of concept. In order to truly assess where the improvements were made however, they need to analyze how often they had to re-do something in the past and at what cost. In other words, how often did they have to make changes to their code base as a result of discovering something they either missed or found to be defective? At what stage of their SDLC did they discover them? How expensive was it to make those corrections / adjustments? One clear way of measuring improvements is to measure how much waste in time / money did the team eliminate as a result of discovering the unknowns as early as possible by making the end to end connections to do a demo even at just a fraction of the total functionality. How early we're they able to accommodate the changes the client didn't have a chance to mention in the initial requirements but came up during the demo? How much cheaper was it to make all these changes as early as possible instead of waiting until the typical CAT phase? How much value can you put on the satisfaction of the client who wishes to do another project based on his/her level of satisfaction instead of going elsewhere?
Could you count these as a measure of improvements? What companies should measure today is the number of projects they are losing to competitions who are more lean and agile...........

You must Login or Signup to comment.