Agile: So who's the team manager?

People often call agile teams “self-steering” teams or “self-managing” teams. But surely someone must steer the team towards a long term goal? And how about activities that are typically performed by a department head, such as daily operations, coaching, coordination of vacation days, and employee performance management?

The answer to those questions is, as with many things, “it depends”. It depends on the management activity and how far along the organization is in adopting an ABOK (Agile Body of Knowledge) way of working.

Let’s first zoom out before we zoom in.

Traditionally organizations are divided into silos. The division can for example be based on market segment, or geography, but is usually based on the activities people perform. So usually, IT people are pooled in the IT silo. If we look at such a traditional IT department, then within that silo there is usually more compartmentalization; such as a software development team, a network and system administrations team, a database administration team, a 1st line support team, etcetera, with each team having its own team lead. When organizations make the shift towards agile, they often implement a matrix organization; the compartmentalization is kept, where agile teams are formed by using members of each compartment.

Below is a simplified illustration of a matrix organization:

The team members are part of both their original compartment, reporting to the compartment team lead, and are at the same time part of an agile team, probably reporting to a manager overseeing the agile team.

So how are agile teams managed, in both matrix and non-matrix organizations?

Day-to-day operations

Many people assume that for day-to-day operations the scrum master is the team manager, but no, a scrum master is not the team manager. The task of the scrum master is to assist the team with sticking to the agile principles, supported by the scrum framework. So the scrum master for example organizes the scrum sessions such as the daily stand up and the retrospective, the scrum master makes sure impediments are solved by the team, etcetera. An experienced scrum team ideally doesn’t have a scrum master, since the scrum master responsibilities should be embedded in the team. The fastest way to embed those responsibilities in the team is to make the team responsible as a whole. The presence of a manager-like scrum master will prevent team members from feeling responsible, which will make it take longer for those agile principles to become embedded in the team.

So yes, in a non-matrix organization the team really is self-managing for day-to-day operations.

In a matrix organization, the team also ought to be self-managing, but for individual team members (or their managers) that might be too big a break from tradition. However, if a compartment lead wants to know what one of the guys or girls in his compartment are doing, then they really should ask the product owner.

Being self-managing for day-to-day operations doesn’t mean they get to do what they want; they are guided by the sprint planning that they committed to at the start of the sprint.

Short term planning

If the team is guided by the sprint planning, how is that sprint planning made? The product owner, in her role as customer representative, determines what features she would like to have implemented in the next one or two sprints. Together with the team those feature requests (or requirements) are broken down into small work items, that (ideally) can be finished in 2 to 4 hours each. Then, at the start of each sprint, the team decides how much of those items they will finish that sprint. After the sprint planning, the team commits to finishing those items in this sprint. In exchange for that commitment, the product owner agrees towards fixing the sprint; so she (nor anyone else) can change work items during the sprint.

So, for the work that is to be done the next few weeks, the team is managed by the product owner, both for matrix and non-matrix organizations.

(Enterprise) Architecture

The product owner can dictate what to do, but she can’t dictate how to do that; that is the responsibility of the team. But what if you have more teams, wouldn’t it be wise to standardize on the same tools and way of working?

Also, normally a team does more than work for a single customer; they should also be working towards several other mid- to long-term goals that are not strictly product related. Think about stuff like researching technical innovation, or perhaps a project to move all the in-house hosted customer servers to the cloud, or other goals.

In a matrix-organization the compartment leads will set those goals; through regular contact with the people in his compartment, the product owners, and his own vision the lead can define goals that are beneficial to all teams that have members from his compartment.

In a true agile organization, most of those goals will come out of direct market demand. The product owner might for example find in her discussions with the customer that her company is a tad too expensive when it comes to running the product, and the high-available private cloud that was once top of the bill might now be falling behind in reliability compared to the large public cloud offerings. If there is just one agile team, it is easy to coordinate those changes; a percentage of each sprints’ capacity can be used for such general improvements that will benefit multiple customers, or perhaps every once in a while a complete sprint can be dedicated to such improvements. If there are several agile teams working on the same project, then improvements like this can come up in the frequent meetings that the teams have with each other, the so called “scrum of scrums”.

However, if you have several agile teams working on separate projects, then there will be no scrum of scrums, and it would not be economical if one agile team standardizes on C# and TFS and another agile team standardizes on C++ and Git. One way to coordinate this is to have an architecture board, which meets for example once a month with as goal discussing enterprise architecture and defining projects to improve the companies’ IT landscape. Membership of this board should be open for everybody who wants to join.

Vacation days

The number of vacation days is an HR activity, but planning those vacation days should be the responsibility of the teams and the professionals in those teams. So in neither organization this is something that should have managerial oversight. This also goes for other low-level HR activities like going for a dentist appointment etcetera; coordinate with the team, make the dates known before the sprint planning so the velocity can be adjusted accordingly, and don't waste extra time on requesting for (and waiting for) permission.

Performance management and coaching

Most companies have an individual employee performance management process with three distinct phases. In the first phase, the employee and manager define personal and professional goals for this year for the employee. The second phase is about monitoring progress and hopefully stimulating progress through coaching. In the third phase the progress is reviewed, and the results of this review often form the basis for compensation adjustments.

I think traditional performance management and agile don’t get along well since a team should function as a whole. However we can’t ignore the fact that there is a difference in individual performance of team members. While the environment created by the team and company is responsible for a large part of this performance, there still is an individual responsibility. To incorporate that environment into the performance rating, Jeff Sutherland proposed a decade ago that the rating should for 25% be based on how well the company performs, for 25% be based on how well the team performs, and for 50% on how well the individual performs.

The performance management process starts with phase one; goal setting. This goal setting process is the same independent of the organization type, but the goals itself in an agile organization could lean more towards teamwork.

In the second phase the best way to give feedback is to do it daily on the job, but that unfortunately doesn’t fulfill the requirements of the usual performance management process. As an alternative using 360-degree feedback is a good way to receive input, however this feedback should be open (as opposed to anonymous) and be as specific as possible.

In a matrix organization the feedback can be discussed with the employee by the compartment lead, who could also perform a coaching role. Unfortunately in The Netherlands it is a rarity to receive formal coaching in a company.

In a non-matrix agile organization it is not so clear who should perform the task of relaying the feedback to the employee and performing coaching. It definitely shouldn’t be the scrum master, since the scrum master should be an equal team member and not have the suggestion of being the manager of the team. The product owner could perform the role, but ideally this task is done by the IT director.

The best option however would be not to have traditional performance management. I’ll try to revisit this in a later post, to discuss how to embed performance management in an agile way.

The same manager (compartment lead / IT director) as in the second phase should do the “end of year review”, the third phase. The content of that review should never be a surprise, since through periodic feedback and coaching the employee is aware of his appraisal.

Project management

How about project management? Some customers (be it internal or external) want detailed status reports, want escalation contacts, need someone to be present in steering committees, etc. That work is typically the task of the product owner, who can perform the customer-facing role of a traditional project manager or customer director. The product owner should not use the team or the scrum master for those tasks; please let the engineers engineer instead of having them spending 4 hours a week each writing status reports. All the required information should be in the backlog, the velocity of the team, and the burn-down chart of the current sprint.

And inside the team?

Putting several people in a room and calling it a team isn’t enough to make it a team; it takes careful guidance and a lot of openness, respect and successes to create a high performing team. Food for thought for another post!

--
Kenneth van Grinsven

[This article was first posted on LinkedIn Pulse]