James Shore just wrote a post on "mediocrity" which nicely explains why Agile doesn't always scale well: It isn't Agile that's being scaled, but corporate inertia. If an organization isn't going to commit to doing things differently, they have succeeded only at mediocrity.
Some of the follow-up comments got me to thinking about the problem. People were asking how to get middle management on-board. I think a few of the questioners realized that finger-pointing, and arguments, and directives to "Just do it!" are counter-productive. It's not that managers don't see the value in Agile methods, but it's not clear how their day-to-day behavior is supposed to change.
We need a little root-cause analysis here. Businesses are run by people, and people are motivated by a variety of things: Self-interest, compassion, fear, joy, confusion. Change is unnerving, particularly when one is not the instigator of the change.
I find that people resist change at work when work itself is a source of stability in their lives (e.g., they would rather be at work than at home), and/or they see their job as just a job, and not a productive, change-generating career. In traditional organizational structures, middle management is detached from the two most dramatic regions of the org chart.
So if I'm a middle manager, and I like my stability, I resist the change. If I would like to be part of the change, I see my own involvement as limited. And, do I even have a role (and a job!) in this new world order???
The good news is that, on a truly agile project, there is plenty of interesting work, and learning, for everyone. Our first step is to stop thinking of them as managers, and start thinking of them as leaders.
I once heard a very good quote which helped me out of a career rut. I'll paraphrase: "Not everyone gets to do what they love [C'mon, I'd be co-authoring novels with Larry Niven and Vernor Vinge. In Maui. Shaka, Bra!]; but we must love what we do."
That's a non-mediocre goal, without being an impossible stretch towards perfection. You help the team by helping yourself grow, and you help yourself by helping the team.
I can't count the number of times I have met a manager who says, somewhat forlornly, "I used to write code..." Leadership involves some wonderful skills that we can learn and be proud of, but we may want to reconsider the "one ladder" approach of moving our most talented technical people into pure management roles.
Nor should we necessarily get our managers directly from a pool of young, non-technical, certified PMIs. We need to be picky, and find people who are familiar with technical endeavors and are willing to lead people towards a common goal.
Maybe that's why "coach" has such appeal for me: It's technical, and people-oriented. I help other people (developers, testers, managers, directors, VPs, everyone) find ways to enjoy what they do while successfully building quality software products. I do love what I do!
Do you? (If not, we can help.)
Further Reading
Jim's post: http://jamesshore.com/Blog/Stumbling-Through-Mediocrity.html
Agile Bob's comments regarding Jim's post: http://www.agileforall.com/2009/03/30/new-to-agile-dont-settle-for-mediocrity/
Subscribe to:
Post Comments (Atom)
Hi, Rob -
ReplyDeleteThere's still plenty for middle managers to do when the organization adopts agile and self-organizing teams. But it is a shift, and brings up all the emotions that come with change: loss of a sense of competence, loss of status, loss or routines.
Middle manager need a road map on what's expected of them in the new environment, just as developers do.
Some musings on that here:
http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=115
More in forthcoming book.
Cheers,
Esther
Giant question: If the middle manager does not want to lead, what does the agile coach do?
ReplyDeleteAs a ScrumMaster and company agile coach I am faced with this question every day. Some managers don't want to change, participate or take the reigns. They prefer to be "project managers" or just stay with the status quo. "No time for improvement," "The system is fine." are the answers proffered.
The temptation is to go over their head for some higher management muscle. This, however, is a bad approach for change. I suspect these kinds of managers will not stay with the company as more agile practices propagate. In the mean time, they bog things down.
Any thoughts on how to help them see value in change?
That's a long, hard road, and there's no single answer that's certain to work. Some things that come to mind:
ReplyDelete1. Read Esther's new book. She understands that so much of the dysfunction on a team is related to human communication.
2. Sometimes I think I need to get a degree in psychology. Only sometimes, though. With enough patience and experience, we can start to see the patterns of people's behavior, and get some insight into their motivation. And that's key to resolving these things: Find out what that person can hold onto while letting go of whatever it is that needs to be dropped. This doesn't mean you have to be a soft-hearted teddy-bear coach. Different styles motivate different people. There are a lot of people on software teams who thrive on direct constructive criticism. But not all.
One of my worst experiences was with one lady who was a programmer/manager on a small team. She would literally say nothing, sitting stone-faced with arms folded, during pair-programming sessions. She would find our tiniest faults or weaknesses and play them up in an attempt to get us (the coaches) thrown out.
She had worked for many years on the product that we were actively re-writing. She knew every detail of how that product worked. She was being asked to learn a new programming language, and strange XP practices, so we could replace the very thing she had poured her career into. Add to that the fact that she was at most ten years from retiring with a pension, and I could finally see that we were really rocking her boat. She hadn't worked on any large teams, so she really didn't know how to make herself heard regarding her personal success on the team.
She had a lot of respect for the gentleman who had built the original team, and he was acting as Product Owner (or XP "Customer") and Project Manager. We went to him to see what he could do, and he simply said he wouldn't fire her. (We weren't explicitly asking for that, but I notice with regret how some managers think of that option first.)
We made her the PO/customer. The PM had far too much to do already; and she knew the business domain, and the capabilities of the old system, far better than he did.
And she flourished! We came to appreciate her (often condescending) "You forgot to consider..." statements, because we were gaining new stories!
3. Know that there has to be a happy ending, because only a suicidal idiot would intentionally sabotage her own livelihood.
4. Be patient. That story above took nearly a year to unfold. That may make us coaches seem insensitive or dense, but change often has to be introduced incrementally. That team became a high-performance XP team and built a rock-solid, profitable product; but if we had taken the old "my way or the highway" approach it would have been us hitting the pavement.
Oh, and find someone to co-coach. Agile coaches need someone to brainstorm with. Pair coaching is almost as essential (and almost as fun) as pair programming!
ReplyDeleteI think too often, middle managers get stuck in a corporate mindset of documents and meetings. They lose sight of their passion which is what (hopefully) got them there in the first place.
ReplyDeleteWhen you're in a place of mediocrity, having passion seems just hard and inconvenient. That's one reason why top-down agile is so important. It's too easy for a middle manager to tell a developer, 'no we can't do that', 'you just don't understand', 'this is the way we've always done it', blah blah.
The key to change to moving out of mediocrity is also completely essential to successfully implementing agile. It is to find that passion, that drive to build better teams, better software, whatever. Only then will going through the mindshift that is required seem "worth it".