Coming from a waterfall background, Brad Egeland found himself questioning the role of the manager on an agile project. What he learned at an agile conference helped him find some answers.
While attending the Better Software and Agile Development Conferences West in 2011, I had the chance to attend a very worthwhile discussion on agile leadership. Skip Angel, a consultant and coach from Big Visible Solutions, led the session, which focused specifically on management’s role in the agile development and project management process. Basically,it answered the question: What happens to the manager in the agile environment?
Coming from more of a waterfall background, I had my own concept of where the manager fit in. He led the show. The team is important, but the project manager is definitely the straw that stirs the drink. All communication flows through him, and the target is definitely on his head.
Executive leadership within the organization has certain expectations of him, he creates and follows a project schedule and manages all tasks and progress against that schedule, and overall project success is almost always based on how on time and on budget the project is and how satisfied the project customer is when the engagement reaches the finish line—assuming it even gets there, considering the greater than 50 percent failure rate of your average project.
So let’s reconsider the question above. Does the manager have a role in the agile development process? What happens to him when his organization adopts agile? Is he lost in shuffle? Do traditional management methods get tossed out the window?
Well, the answer really is, the manager must adapt. From department managers to resource managers to project managers, things just have to happen differently. Agile teams do still need leadership—just a different kind of leadership. And the key concept—if you were to take only one from Skip Angel’s great session—is this: The manager must change his leadership hat to move from being a “director” to being a “catalyst.” There are, however, other things to consider: How does the remote team fit into the agile model? What about full resource utilization being pushed in every IT organization that I’ve ever been a part of? How does that affect the creativity needed to make the agile model successful?
Directive Leadership vs. Catalyst Leadership
Mr. Angel did a nice job comparing and contrasting directive versus catalyst leadership roles: Directive leadership forces analytical thinking, catalyst leadership brings systemic thinking. Directive leadership looks at either/or while catalyst leadership looks at both/and. Directive leadership enforces unilateral control while catalyst leadership encourages collaboration. Directive leadership is deterministic. Catalyst leadership is chaordic, blending chaos and order.
As opposed to traditional, directive leadership, the catalyst leader must be collaborative and flexible. He must enable, boost, energize, and coordinate. He must be inclusive, adaptive, facilitative, courageous, and self-reflective—ready to look at things in terms of what he may have done wrong or missed rather than searching out someone to blame. No defensiveness allowed here: It’s not about you, it’s about the big picture. It’s about accuracy, getting it right, creating the right solution, and making the engagement a success.
Full Utilization Is a Bad Thing
Another interesting concept is that full utilization—the 100 percent level that most professional services organizations strive for and reward individuals on—is likely a bad thing. Agile team members need time to research and investigate. They need time for the creative process, and not “their own time.” Google is a good example of this practice. Google allows and encourages employees to invent on company time, which is where many new Google features have come from. Rather than seeking 100 percent utilization, shoot for 80 percent and reward team members for meeting sprint deadlines by allowing them to “invent” with the other 20 percent of their time.