One of the very cool things about doing The Cranky Middle Manager podcast is the ability to learn about new trends in management before they show up in places like Training magazine, by which time they have already gone the way of the dodo (just as your kids have already deleted any music by anyone making the cover of Time or Newsweek).
I've been talking to a lot of people in the software world lately, and learning about Agile project management. (You can hear a whole interview about it here). The more I learn, the more I'm convinced that while there are extremely valuable lessons to be learned, there are some warnings to be heeded as well.
First, a definition: "Agile" is actually a single name for a number of methodologies for designing software that have proven to be more effective than traditional project management theory in dealing with business realities like changing requirements during development. It promotes best practices that emphasize teamwork, customer involvement and the frequent creation of small, working pieces of the total system. This is important because so much changes in software development , often overnight, and you never know how long it will take to create a working piece of code.
In other words, if you think about how software people work, traditional project management is a recipe for frustration ( if not actual madness and homicide). Because coding is more art than science it's almost impossible to say how long a certain step in the process might take- it might take weeks of grinding, testing and cussing or it might happen in a sudden Red Bull-inspired flash of genius.
By breaking the steps into small discreet tasks, doing frequent check-ins and working as a small but "agile" team, no one goes too far off the rails, and everyone knows what's happening in the project on a regular basis. So far so good.
In many ways, the software world is a great model for the workplace of the 21st century. The teams are frequently "virtual"- different members answer to different parts of the organization but the project leader has to keep things together and on task.
They are also "remote". Team members may be literally anywhere in the world and in any time zone making it a 24/7 workplace and day to day communication is usually through technology. Finally, it's all about small tasks, done with insane focus- always being mindful of the desired final outcome.
The difference between an Agile environment and where you and I work is that there's a NAME for this craziness and the software folks have started to get their mitts around how to work in that system. The rest of us are left flailing as they give us that superior/sad shake of the head software geeks give us mere mortals when they think we aren't looking.
On the surface, it would seem that Agile is a great solution to the challenges of a modern workplace. But there are potential problems with the way people manage in this environment - problems that are easily handled if the manager is aware of the dangers but can become crippling if they're not
For a start, because the focus is on small tasks requiring intense concentration, it's really easy to lose track of what's happening in the rest of the company and open yourself to ugly surprises at budget time. Loyalty is often to the team rather than the company as a whole. Many programmers assume that the manager's job is just to keep the rest of the world from interfering with their work. I don't know how many times I've heard Agile team managers say that their job is to "just get out of the way".
But projects, particularly software development, don't happen in a vacuum. The financial and operational reality of the Organization is critical to their success. It's up to the manager to keep delivering context for the team and to be the eyes and ears of the group. Brilliant code is useless if the company's strategy changes or the Project that drives the team is cancelled.
Part of the macho Agile environment (remember, this is a process that calls team meetings "scrums"- as in rugby) is to do things "lean and mean". This throws up another potential pitfall because it frequently means that the manager is a part of the team doing the work. (Pause while I scream at the term "working manager" which is finding its way back in vogue).
While pitching in and being part of the team is terrific in theory, remember that the role of a manager is not to "do", but to "help it get done". Too many times managers who were great individual contributors revert to their coding role and let the "management stuff" (paperwork,coaching, reporting to THEIR bosses) slide.
My theory is that people will always default to the parts of the job they like and ignore the parts they don't. A successful manager can't get so lost in the day to day operations that they lose site of their role as manager.
Yet because speed and attention to the task at hand is the team's driving force, it is all too easy for managers to forget the human side of managing teams. So many Agile managers tell me, "I don't have time for one-on-one's - that would be 7 hours a week and we can't spare it".
In the short term, team commitment to the goal is sufficient to get tasks accomplished, but over time the human factors that bedevil teams set in. If getting to know each other, building relationships between teammates (especially if there's no chance of meeting in the lunchroom) and talking about what's going on in the individual's personal world are perceived as "extras" or as not essential to the team's mission, engagement, productivity, trust and all the other human issues so critical to success can become huge problems. This can lead to missed deadlines, turnover and calls to the Employee Assistance Program.
Add to this mix the fact that the team is usually separated by geography and conducts its business via technology like webmeetings, conference calls and email . You can see how easy it is for poor communication to cripple a team.
The main way to tackle these problems is in what organizations choose to measure. If the only metric of team success is how much code or which tasks get accomplished, I can almost guarantee that the higher-level management behaviors will go by the wayside. If human connection behaviors like one on ones, team building activities and the like are part of the mix, Agile can be a great part of the company's success.
Many organizations are more than happy to implement Agile teams in their workplaces, but without equipping managers with the tools to communicate effectively and form truly human connections across distance they are setting up teams that are more fragile than Agile.
Great article, Wayne.
I couldn't agree more. Whilst Agile can be a great tool, that's all it should be - another very useful MANAGEMENT tool (Yes, there's plenty of emphasis on that word 'management').
As someone who works regularly with middle managers from a wide cross section of industries and cultures, I can say that they all have one thing in common - their liking for, and sometimes inability to pull themeselves out of the technical aspects of the job and doing more managing.
I've had one manager who had this problem and decided to so something about it. He has six direct reports (some remote) and he now spends one hour each Friday with one of his people talking about their work, job, career etc. He reports that the changes in his management style and the motivation of his team have been fantastic.
Keeping managing, mate!
Bob