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. It’s unrealistic to think that your developers or project team members can be creative if they are tasked to be as close to 100 percent utilization as possible. For agile to truly work, IT groups, CIOs, PMO directors, and development managers must rethink the utilization issue and figure out ways to reward the creative process and the research aspect rather than reward the billable hours concept. Sticking to the old 100 percent rule will lead to adoption failure for agile practices.
Remote Versus Collocation
The remote team concept is one that I’d like to explore further. Everything presented during Angel’s session encouraged collocation of agile team members in order to promote creativity and collaboration. I can understand that. The question is, can agile methods work on a project where team members may never meet face to face for the entire engagement?
We must embrace reality here. In 2012 and beyond, organizations are using IT and project teams built with team members dispersed across the country and around the world. I personally have only managed one project in the past six years where nearly all of my team members were located in the same building. Most projects have involved members two thousand miles away or on the other side of the globe. Some specific management challenges to consider are:
- How well do agile processes translate into the remote project and development team model?
- Can the cohesive rapid development and rollout happen successfully when no one on the project team is located in the same building?
- Is the manager’s role compromised in the remote agile project management scenario? Can he still be the facilitator that he needs to be?
- Will team member creativity take a hit with resources located so far from each other? And if so, what can the manager do to help overcome this and other issues caused by the distance barrier?
What are your thoughts and experiences? I would appreciate reader feedback on agile successes and failures, particularly on the use of agile methods when teams are geographically dispersed.
Summary
In order to successfully adopt agile processes, staff managers and project managers must understand the need to take on different roles—enablers more than leaders, facilitators more than managers. They must be educated or the process won’t work for long. If an organization is going to be successful in adopting agile, then staff members need to properly understand their role and that starts with the organizational leaders understanding how to relinquish some control and focus on helping the team experience success.
Managers must understand that agile team members need time to be creative and, therefore, throw out the full utilization model, even though it’s so hard for executive management to let go of. I still have concerns about remote teams and their success in the agile model. But remote teams are a way of life in today’s IT and project management environment—adaptation is definitely a two-way street.
User Comments
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.
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.
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.
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.
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.
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.
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.
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.
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!
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!
Pages