How Does the Manager’s Role Change in Agile?

[article]
Summary:

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.

Tags: 

User Comments

12 comments
Nirav Assar's picture

Brad this is a nice article. I think the essence of an agile team is to trust your technical people, and for a leader to have the humility to let go of the concept "My way is the best way, and others don't know any better". The only way for individuals to adopt the perspective of the article, is to let go of that thought.

June 2, 2012 - 4:50pm
Nirav Assar's picture

Brad this is a nice article. I think the essence of an agile team is to trust your technical people, and for a leader to have the humility to let go of the concept "My way is the best way, and others don't know any better". The only way for individuals to adopt the perspective of the article, is to let go of that thought.

June 2, 2012 - 4:50pm
Nirav Assar's picture

Brad this is a nice article. I think the essence of an agile team is to trust your technical people, and for a leader to have the humility to let go of the concept "My way is the best way, and others don't know any better". The only way for individuals to adopt the perspective of the article, is to let go of that thought.

June 2, 2012 - 4:50pm
Nirav Assar's picture

Brad this is a nice article. I think the essence of an agile team is to trust your technical people, and for a leader to have the humility to let go of the concept "My way is the best way, and others don't know any better". The only way for individuals to adopt the perspective of the article, is to let go of that thought.

June 2, 2012 - 4:50pm
Anonymous's picture
Anonymous

Brad, a very nice overview of agile management, addressing the need to adapt leadership style when one wants to make it really work, and not just implement the 'mechanics' (processes). Implementing iterative processes can be done, but do not necessary lead towards real agility.

As you write and as Nirav also suggests in his reaction, the key difficult change to make is the change in culture of management towards real trust and the deeply felt conviction that people who are assigned to a (project) job will in general know how to do it in the best way, when given the right support and context for the job (!!).

The notion of self-steering teams are in many cases a scrare-factor for (project) managers. Apart from the fact that they will feel problems in repositioning themselves, the notion that the typical 'command and control' cycle is removed, tends to create unease.

Therefore it is perhaps good to understate that the instating principle of 'tranparency' is so important when changing an organization towards agile project management.
The clear and undisputed ability to 'inpsect' project proceedings, allowing for the project to be 'adapted' for its course is in my mind a prerequisite. Building this capability should go hand-in-hand with the change of leadership itself.

June 4, 2012 - 3:29am
Anonymous's picture
Anonymous

Brad, a very nice overview of agile management, addressing the need to adapt leadership style when one wants to make it really work, and not just implement the 'mechanics' (processes). Implementing iterative processes can be done, but do not necessary lead towards real agility.

As you write and as Nirav also suggests in his reaction, the key difficult change to make is the change in culture of management towards real trust and the deeply felt conviction that people who are assigned to a (project) job will in general know how to do it in the best way, when given the right support and context for the job (!!).

The notion of self-steering teams are in many cases a scrare-factor for (project) managers. Apart from the fact that they will feel problems in repositioning themselves, the notion that the typical 'command and control' cycle is removed, tends to create unease.

Therefore it is perhaps good to understate that the instating principle of 'tranparency' is so important when changing an organization towards agile project management.
The clear and undisputed ability to 'inpsect' project proceedings, allowing for the project to be 'adapted' for its course is in my mind a prerequisite. Building this capability should go hand-in-hand with the change of leadership itself.

June 4, 2012 - 3:29am
Anonymous's picture
Anonymous

Brad, a very nice overview of agile management, addressing the need to adapt leadership style when one wants to make it really work, and not just implement the 'mechanics' (processes). Implementing iterative processes can be done, but do not necessary lead towards real agility.

As you write and as Nirav also suggests in his reaction, the key difficult change to make is the change in culture of management towards real trust and the deeply felt conviction that people who are assigned to a (project) job will in general know how to do it in the best way, when given the right support and context for the job (!!).

The notion of self-steering teams are in many cases a scrare-factor for (project) managers. Apart from the fact that they will feel problems in repositioning themselves, the notion that the typical 'command and control' cycle is removed, tends to create unease.

Therefore it is perhaps good to understate that the instating principle of 'tranparency' is so important when changing an organization towards agile project management.
The clear and undisputed ability to 'inpsect' project proceedings, allowing for the project to be 'adapted' for its course is in my mind a prerequisite. Building this capability should go hand-in-hand with the change of leadership itself.

June 4, 2012 - 3:29am
Anonymous's picture
Anonymous

Brad, a very nice overview of agile management, addressing the need to adapt leadership style when one wants to make it really work, and not just implement the 'mechanics' (processes). Implementing iterative processes can be done, but do not necessary lead towards real agility.

As you write and as Nirav also suggests in his reaction, the key difficult change to make is the change in culture of management towards real trust and the deeply felt conviction that people who are assigned to a (project) job will in general know how to do it in the best way, when given the right support and context for the job (!!).

The notion of self-steering teams are in many cases a scrare-factor for (project) managers. Apart from the fact that they will feel problems in repositioning themselves, the notion that the typical 'command and control' cycle is removed, tends to create unease.

Therefore it is perhaps good to understate that the instating principle of 'tranparency' is so important when changing an organization towards agile project management.
The clear and undisputed ability to 'inpsect' project proceedings, allowing for the project to be 'adapted' for its course is in my mind a prerequisite. Building this capability should go hand-in-hand with the change of leadership itself.

June 4, 2012 - 3:29am
Anonymous's picture
Anonymous

Brad great article. We had been running Agile development teams in major Australian banks for the last five years including implementing Agile into PMOs and across business. And I agree the biggest change for the project manager is to basically learn to let go and trust your people!

June 4, 2012 - 6:17pm
Anonymous's picture
Anonymous

Brad great article. We had been running Agile development teams in major Australian banks for the last five years including implementing Agile into PMOs and across business. And I agree the biggest change for the project manager is to basically learn to let go and trust your people!

June 4, 2012 - 6:17pm

Pages

About the author

Brad  Egeland's picture Brad Egeland

Brad Egeland is an IT, project management, and business strategy consultant and author with more than twenty-five years of software development, management, and project management experience leading business and IT initiatives in nearly every industry imaginable.  He works with organizations of all sizes from startups to Fortune 500 leaders and has overseen the creation and execution of multiple PMOs. Brad is married, a father of nine, and lives in Las Vegas, NV. He can be reached at brad@bradegeland.com or you can visit his website at www.bradegeland.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03