Learning to be an Agile manager — Part 6: Manager as a Servant- Leader
This is Part 6 in a series on lessons I have learnt as a line manager for Agile teams. It takes the form of the “continue-stop-start” approach often used in retrospectives. See Part 1: Release Trains for background.
Line management can have a destructive influence on Agile teams or transformations. Some suggest that this role is now redundant. I believe that a line manager has a critical role to play in an Agile transformation.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” — Fifth Agile principle
Many organizations have a culture and structure that go back 20 plus years. They are not Facebook, Google, Spotify or Valve. They have silos, turf wars and policies, it is messy. An organization is not going to transform because someone decides it is a good idea to implement Agile. They do not care about creating environments that motivate individuals, do not trust them and believe they need to be controlled. A line manager can influence the organization or the part of it that she were given responsibility for. The organizations expectation of what line managers do will not change. The value that Agile provides to an organisation will sell itself, if it can survive the status quo for long enough, thinking will be influenced.
A Scrum Master has a leadership role in a Scrum team. However, a Scrum Master’s influence is limited by the organization and its hierarchy. A line manager’s influence might also be limited by hierarchy, but it typically exceeds that of a Scrum Master. A Scrum Master’s focus is limited to the team and part of the organization that team works with, line managers see a bigger picture.
Line manager have a responsibility for all the Scrum team members in their area. They are exposed to environmental impediments/opportunities that, here are some that I had to deal with.
Production deployment frequency (Release Trains). In large organisations were Agile is introduced production deployments are infrequent (monthly or quarterly). The original reasons for this might be valid, find alternative ways to address the need.
Development infrastructure and tools. Agile is not about tools, tools will not make organisations more agile. However, some tools and infrastructure can enhance agility by supporting continues integration and testing.
The physical layout of the work area to support collocation. Things I have started considering are access to the “Scrum board”, the ability to make eye contact with out getting up from your desk and being able to hear each other without raising your voices.
Team structure to reduce or eliminate hand-offs. Find ways to let team work as cross-functional teams.
Once cross-functional teams are established there might be skill that needs to be developed within the team to enable the team to deliver working software without external dependencies. Identify and facilitate the development of these skill sets.
Hire people that are willing to give up individual glory for the greater good of the team. I have learnt that there are people that have been conditioned to seek individual glory by the environment that they worked in. I have not seen many of them unlearn this behavior. It is extremely destructive to the team, even if the individual has amazing technical skills, the team is better off without one of them.
Performance management (KPI’s) can have a similar effect on the team as a person seeking individual glory. Individuals still has a need for feedback on how they are doing. To do this I have started to treat KPI’s like story cards (Card, Conversation, Confirmation), something like KPI, Conversation, Growth Goal. In this approach individuals identify their own growth goals.
Your organization is different and what it will need from you will be different. The key is to remember that you decide how to address the need, through command-and-control or Servant-Leadership.
Servant-Leadership has intrinsic rewards that far exceeds the value of money.
This is Part 6 of 6 in a series, See Learning to be an Agile manager — Part 5: Stop and Start — The difficult things.