Thinking if we still need managers in Agile seems to be a common question to answer these days. This is a great question, which I think stems from misconceptions… and these misconceptions have many sources.
If you don’t like the suspense or don’t like to read long posts, I’ll start with my opinion first and then you can relax and enjoy the article.
If you like the suspense, scroll down to the next section right now to go on a journey with me.
Here it goes in tl;dr; version:
Managers are valuable and needed. Pain and misconceptions generated the myth of no management in Agile.
Ground-breaking right?
So let’s dive in.
Historical references on manager antagonism
Great managers have always existed. And the same can be said of less than inspiring managers.
Back in the late 1990’s the cliché of overworked geek developers was not a cliché for many. I can definitely say I got to experience a lot of stress from project life as a software developer. Before things like the Agile Manifesto came to light, it was not common practice for developers to experience these cool things we see today when we talk about team commitments and team decisions. Collaboration, team agreements, proximity to the customer.
To a great extent, commitments were already made, dates set, and developers would come in as executors. I even remember being asked to give estimates and hearing the project manager say: well, we’ll have to do it in less time. Not bad if we were all thinking in agile. If the date is fixed, the scope is flexible. But no. Both scope and dates were fixed. And the approach was gate-phased in waterfall.
In many cases, team managers and project managers were also not knowledgeable about software development. They were well-versed in management and administration.
Let’s pause to acknowledge there were happy teams and awesome managers even then!
But we are talking about the bad stuff, where misconceptions get generated. So let’s get back.
Time-wasting and soul-draining management was prevalent enough even before the 1990’s. So much so that a cartoon like Dilbert came to light.
Those were years of a lot of resentment and misunderstanding. Developers and managers had an antagonistic relationship.
While it’s good to think when Agile came to light the world got better, no one was healed from that animosity yet. And the animosity remained for quite sometime because what I’m about to tell you dates from past 2010!
Some of us are old enough to have seen or experience or discussed around the famous pig and chicken cartoon. The one where it was implied that managers were just involved while developers were committed. Developers had skin in the game. Managers didn’t.
I remember those references even as a Scrum Master, around 2012 and my peer Scrum Masters would also rally around the image in contempt. Not that long ago if you ask me. So even in the Scrum world 10 years ago there was such an antagonism towards management.
It cannot be discounted either that beyond the team manager, we had project managers coming into the picture. Tons of meetings and tons of documents were brought by them back then. You would have
- Status report on many different things going on in the project.
- Many meeting to go over these reports and extra meetings that took time away from doing to reporting.
- Many disciplines involved in project management. PMI was championing the knowledge of project management and a good, big project would have a project charter and many plans: resource management, quality management, scope management, time management, risk management, communications management…
All this is deeply described in the PMBOK guide.
And a good, certified project manager would know how to plan those things to the level of Bob giving 13.5 hours this week, to keep time and costs in check. Everything was so complicated that you’d need projections.
If you are noticing on the human part:
- Bob can’t contribute to the level of his expertise. If he takes more than 13.5 hours, we can’t pay him. In my experience, Bob is probably not even sitting with most of the team.
- There were a lot of rules, with so many plans. And project managers were the ones manning all these plans. Controlling, updating and deciding on these plans. So developers would focus on their work… and constantly be interrupted to give status to a project manager at some point.
Once again, all these styles of management created loads of documents and logs and meetings. Projects were so big and long lasting that these things needed rather specific management. Or so was the thought at the time.
And the projects were all late anyway. But managers were accountable for them.
The point being: managers came from administration school. Developers came from computer school. There was no intersection to their domains. And none of them had human skills class in college, so their ability to deal with people was more about personal talent.
I am not a historian. I am not a bearer of the truth either.
I speak of my perception. This to me is one piece of the puzzle: how ineffective management of that time shaped the perception of their own roles up to this day.
Misunderstanding of self-organizing, then self-managing teams
Then along came self-organizing teams.
Scrum definitely made the idea of self-organizing teams a widespread notion. People reacted. Later they renamed it to self-managing team. And then a lot of people reacted.
I think on the topic of self-organizing teams there is a piece written by Nitin Mittal that explains so beautifully already that I invite you to read it and I will not expand much. While it was originally published at ScrumAlliance, you can find it here:
Work of Nitin Mittal on Self-organizing teams
But basically, self-organizing teams and self management teams reflect the notion of trusting employees to do their best work (an agile principle) and restore their autonomy in the workplace. I mean, you hired them! How can you not want them to give their best shot at everything they do?
We all know a lot of issues happen in the day-to-day of work. People at all levels in an organization are required to make decisions about what to do next, how to solve a problem, who to talk to.
So now, the team is accountable, not the manager.
The most important thing about self-organizing or self-managing teams?
They still require boundaries. They don’t run the company. They are not a group of people turned loose.
As a passionate systems thinker student, I can talk about boundaries all day if you let me.
Every system has boundaries.
So, to recap: we once had a misunderstanding of manager as the sole and bad decision-maker, now we had some people understanding self-organization/management as the polar opposite solution. It isn’t.
But self-managing teams do exist and I’m sure some people will be able to comment on this post with their experience. I was part of three such amazing teams when I worked for other organizations. My small and mighty team in my company is self-organizing as well.
Here are some of the elements you will find in self-organizing teams. They display:
- a high level of decision-making authority about their work.
- working efforts toward meeting their emerging vision.
- ownership of how they work and can continuously evolve.
Self-organization in systems is recognized by science, both in computing and evolutionary domains and to quote David Willshaw, it can be defined as:
“the process by which individuals organize their communal behavior to create global order by interactions amongst themselves rather than through external intervention or instruction.”
The truth is self-managing or self-organizing teams still need managers. It’s just that the focus and attention of management should be different.
What about scrum masters and agile coaches? Do they manage anything?
With the mainstream of agile practices and frameworks, scrum masters and agile coaches are everywhere. So, it made sense that people started asking: hey, are those people the new managers in agile now?
And this confusion has made companies ask for Scrum Master Delivery Lead and other “hidden” positions for management + favorite agile framework.
But it must be said: the accountability of agile coaches is coaching, mentoring, and facilitating agile conversations. Helping agile teams and individuals thrive in a world of iterative development, incremental change, and constant feedback.
In fact, it is expected that at some point, the agile coach will leave their teams and individuals. Coaching is not a perennial relationship. Agile Coaches follow a code of conduct and ethics that in fact prevents them from doing status reporting and personal evaluation and appraisal. Coaches, by helping people, need to maintain neutrality and confidentiality. They can’t be managers.
That does not mean that managers can’t use coaching skills. But Agile Coaches are not managers of their coachees or of their work by definition.
A similar thought can be used in Scrum, although to be fair the framework doesn’t deny or suggests scrum masters as managers. Or even product owners as managers.
I’ve seen all sorts of interesting implementations where Scrum Master and Product Owner were even the same person, on top of managing team member’s needs, such as vacation, allocation, training. It’s a very charged profile, but I’ve seen it done.
In my opinion, though, I’d rather separate these concerns from frameworks.
All of these current Agile frameworks in 2022 do not consider the accountabilities of delivery centered in one person and they in fact ignore people management.
We still need management
But management is still needed in many forms! In fact, I encourage you to think about it this way: the shape, the form of management is shifting, evolving. Just like Agile continues to do.
You can think of:
– Managing the work
In the beginning of management and its many disciplines, managers… managed people. Literally, starting in the 1800’s managers managed people almost like cattle: controlling who comes in and out and what can and cannot be done personally.
But people eventually started mastering their jobs and their own selves in the work environment, and that requirement is no longer needed.
Then eventually, they moved to managing the work. While no one agrees to necessarily having managers handing over pieces of work to specific individuals, in some complicated cases a manager can do wonders for managing work, especially when they understand the means of production.
Ultimately, though, management has shifted. It is becoming increasingly more about complexities of organizations and many teams put together. That is managing systems and its constraints. The requirement for management got more elaborated.
– Supporting people, not managing them
As a result, the needs for management today are more about supporting, not managing, people. Creating environments where people can interact within safe boundaries and conduct great work. This is the grounds where leadership styles like Servant Leadership and Horizontal Leadership started being coined.
This is elevated management. If you could never “wing it” in management before (some might disagree) you definitely can no longer do it.
Being able to rally people around significant goals, help people understand healthy variations from total system breakdown is no small feat and require skills. While a lot of leadership is needed to work with people in general and to help them collaborate and be happy and productive, knowledge of techniques to investigate situations and bring about results are a much important skillset of management.
Pause for a moment.
What do you see at the end of iterations in many agile iterations? Impediments are mentioned but not removed. Results are subpar and no one takes action.
This lack of proactivity and inability to make decisions and remove obstacles to a healthy production system is a clear symptom of lack of management. But the management that is needed today is not the tayloristic management that made sense 100 years ago.
So yeah, managers are needed!
Manager-coach
Coaching is about helping people unleash their very potential, become resourceful and highly autonomous. So unsurprisingly, coaching skills can help managers both on the human part and on the problem-solving part. There are very simple skills that can help anyone in any position, and definitely managers.
HBR recently came up with an article exploring the issue, one especially where many managers could benefit from asking and listening instead of “telling and selling”. So inconspicuously simple! Just simple doesn’t mean easy.
Again, while managers don’t have to be coaches, they can certainly benefit from coaching skills. Asking, listening, creating a safe space, building trust, and making the best out of everyone just come out and flourish.
Managers as part of the team
I would like to make a point here to invite you to think: maybe you had a manager that was part of your team. I know I had. And having the manager as part of the team brought a lot of communication and transparency. With the added benefit that the main decision-maker, team champion and main impediment-remover is integral part of the team.
Team leads, department managers are examples of managers that are part of the team. There are many configurations in organizations where the manager has the function to support personal and professional growth of individuals. And many times, also act as the expert systems thinker that knows how to probe and reengineer the system in a way that makes positive change stick.
This should not be discounted in the name of frameworks. Nor management abolished. As part of the team, if the team works now in “agile ways”, so do the manager. If the team gets access to training and coaching, so does the manager. We need to train managers, not discard them.
In Conclusion
We need to stop separating or distancing managers from their teams. We need to help managers evolve their mindset and skills.
Basically, we should stop assuming the problem is that we should not have managers because they lack skills. The problem is elevating the skills of the traditional manager to navigate from pay and career management to organizational design to people development.
Organizations navigating agile don’t suffer because we don’t need managers. They suffer because WE DO.
