I've been working with several clients on their transition to agile. Yes, the technical staff needs training. Yes, they often need coaching on how to choose small chunks, estimate and commit to an iteration's worth of work, and then to deliver that work. And, I am beginning to think the biggest problem in transition is the management.
Managers do not know what to do. For years, they've been thinking about a Taylor-like approach to projects: get specialists, put them on the project when they are needed, tell people what to do when, and you'll have a successful project and a good product. Oh boy. That sure has not been my experience.
Back when I was a new developer, my managers never gave me that much direction. They said, “I want this outcome. Do you know what to do?” I often said yes, even when I should have said no. When I did say no, they either gave me more information or arranged for me to gather that information.
I've been working with several clients whose managers do not work like that. They are intimately familiar with the product, and don't just coach their people, they tell them what to do. “Design it like this. Do this. Do that.” As a result, the people are not empowered to do what's needed and they are frustrated. The managers are not doing management work.
If managers do management work, they perform this work:
- Manage the project portfolio. That means defining and refining the strategy for the organization, deciding which projects should start when. Maybe even deciding to stop a project for now, or even killing a project. To effectively manage the project portfolio, you need to refine strategy iteratively. Someone needs to talk to customers. You might even need to fund a pie-in-the-sky project for a while to do some experimentation. Managing the project portfolio means you spend hours each week on refining the strategy and making sure the strategy is reflected in the projects currently funded.
- Build trusting relationships with the people whom you manage. That means a one-on-one each week or every other week depending on your iterations. It means developing a relationship where you provide feedback and meta-feedback, coaching and meta-coaching, as well as having career development conversations. That's 15-20 minutes per week or biweekly with each person on your team. You will have action items out of those meetings, and those will take time for you to complete.
- Leading the hiring work. Managers are ideally placed to perform a job analysis. Do not use generic job descriptions. There is no generic person, why would you want a generic job description? You can use expertise criteria, and start from generic job descriptions. But you need to look at the team and ask yourself, what kind of person does this team need? A manager does not do all the job analysis, but managers can draft an analysis for the team to discuss. Once the team agrees, now the manager can lead the work with HR, organize the phone screens, organize the interviews, organize the post-interview decision-making meeting.
- Creating an environment for success. That means seeing when the team needs more people to build capacity, or if the team or team members need training of some sort. It also means dealing with the furniture police, the network nazis, the people who insist that you can't get the tools you need to do your job. Managers remove those systemic obstacles. Individual reviews are a systemic obstacle and do not optimize the throughput of the organization. Managers work with HR or anyone else who thinks individual reviews are a Good Thing. Under this general category is noticing when the ad hoc work starts to overwhelm the project work. And, noticing when a team does not have sufficient capability to do the job. And, understanding how to design the organization so you can create a successful environment for each team and team member.
That's management work. And, too few managers are equipped to deal with it. Agile demands this management work.
If you are a manager in an agile transition, think about the work you do. Does it fit into these categories? If you are doing other work, please let me know. Maybe my list is not sufficient. But if you are doing project-based work, you are not doing the right work for a manager. You may be doing work that needs to be done. Do you need to do it? Why? I suspect you are missing a piece of the management job.
Think hard about your management work in an agile organization. Do you know what to do?
My best managers were also facilitators, which is what I think you allude to in the third point; but specifically in creating the environment for team members to use him/her as such.
I don’t think all managers don’t know what to do. Sometimes they just need a little push and encouraging. They need to be reminded of their standing in the workplace.
I wonder if there is another dimension to this. Managers know “what” to do as managers. When we want to encourage a shift in the “how” toward a more “agile” approach, the problem is that many managers don’t know “how” to do “management things” in a way that facilitates rather than inhibits an agile approach to delivery.
For example, most managers that I’ve seen or worked with in agile transitions continue to insist on tracking performance to (original) plan, on tracking “busy-ness” rather than outcomes, and demanding repeated estimates for fine-grained tasks in an attempt to make the “actuals” match the “estimates.” Without realizing it, they are throwing cold water on their own agile initiatives. They need more than just “a little push and encouraging,” IMHO.
Thanks for this post, Johanna.
Your points here match my experience. However, it’s not that managers are the “biggest problem” in an agile transition. In 20+ years of helping organizations transition to team-based work structures, I’ve found that the useful role of managers is typically a “blind spot”. Too few organizational change sponsors think to notice how the role of managers inevitably must change in response to other changes in the system. When the other changes happen (e.g., agile self-organizing teams, product owner owning business goal, etc.), the role/skills/approach of managers isn’t considered as part of them. If the managers’ roles don’t change, it keeps the system static and the desired transition stalls. When we put our finger into a bowl of water, the whole bowl ripples in response, not just the place we insert our finger – unless it’s ice: rigid, brittle and inclined to shatter.
Great post on a management problem, especially in IT, that I find frequently. The classic origin is the strong engineer or developer that is promoted into management. Without any support or coaching, they don’t evolve into the role your accurately describe. Rather, they direct resources as if they were still a technical lead considering their team an extension of themselves. I’ve tried to capture more thoughts on the challenges of self-organized teams here: http://bit.ly/9xXKSa
I think JF Bauer is pretty close in his comment. The explanation for the behavior you are seeing my not be Taylor.
People–including managers–want to feel useful. And they do what they know how to do to accomplish that.
Plenty of people in tech organizations haven’t seen good management in action, and the training offered is mostly inadequate. But they do know how to design and write code, so they do that.
The challenge is to change the mental model of management and expand options for action.
Thank you for this article.
In my expierence agile methods are “just another way to do it” for managers. The moment you can convince them that something else would bring a better (financial) outcome, they would buy it in a heartbeat. So they don’t really pick up the benefits and stick with the methods they already know as much as they can.
This automatically leads to the problem that managers don’t do what they’re supposed to do or, even worse, do what they shouldn’t (e.g. provide implementation details).
So my opinion why managers are having trouble adopting agile is that it’s sometimes just a lack of motivation not just their inability.