How Project Managers can be a Positive Agent for Agile
At the Agile Tour London 2015 Graham Dick gave a talk about the project manager as a positive agent for change. InfoQ interviewed him about how agile impacts the role of project managers, if there is still a need for project managers when organizations transition to agile, how to deal with project managers that oppose to agile, applying agile principles to project management, what self-organized teams expect from project managers, how project managers can be a positive agent for change, what to do to make collaboration work in agile, and any advice that he wants to give to project managers when their organization adopts agile.
InfoQ: Can you share some experiences on how agile impacts the role of project managers?
Graham Dick: Agile is a big impact on the project manager’s role. What's happening is that with agile done well the team ‘step up’ and start to do quite a lot of the “work” that PM’s in a traditional organisation spend their time doing. However to be fair I think that a lot of the responsibility delegation that happens under agile has happened in the past when mature project managers were working as they appreciated they did not have a monopoly on experience and knowledge and if they were smart they engaged heavily with their team in a facilitative manner to collaboratively work through a lot of these activities.
So some examples are identifying and managing risk where now an effective agile team will just brainstorm and track these themselves utilising the power of agile to identify which stories when implemented will mitigate which risks – then aggressively targeting them to take risk out of their project.
Another area of change is the work breakdown structure beloved of traditional methods – particularly when developed in excruciating detail up-front. Agile just changes this for the PM, instead she lets her team free within the constraints of agile and watches as they collaborate with their product owner (PO) to allocate stories to iterations and then use their experience to identify what tasks need doing to get the story to Done. So overtime if we were to track the task boards each iteration we would come up with something equivalent to the old full blown WBS. Now instead of driving this activity out up front the PM just needs to ensure that his team are working agile well! Another interesting one is issue resolution. Traditionally the PM took ultimate accountability for project delivery and therefore command and controlled the team to ensure delivery to budget, schedule, scope. Now what happens with agile is that the team make themselves jointly accountable to each other every iteration for delivering the iteration scope to Done. The product owner is accountable to the customer to ensure that sufficiently valuable features are delivered to address the business need. Given these two accountabilities the PM no longer needs to obsess about tracking issues, unless of course their resolution is outside the span of resolution of the team or PO. In which case there are impediments to delivery and the PM can chase their resolution. Other responsibilities like 'incorporating change’, 'assigning tasks’, 'identifying training needs’ become team responsibilities and are addressed as a matter of course with agile done well. So to sum up, agile done well takes a number or responsibilities away from the PM, however this should be seen as an opportunity and not as a threat as it frees the PM up to provide much needed focus to managing outwards to wider stakeholders and other groups within the organisation and also within partner delivery organisations.
InfoQ: Do you think that there is still a need for project managers when organizations transition to agile?
Graham Dick: Now there is a interesting question! I think in principle once an organisation has really transitioned then the need drops away. However, the devil is in the detail. Firstly for many organisations the transition to agile is a journey that will take a considerable time and suffer many reversals en-route. So we often have groups or departments who are really exploiting agile well but are ‘clashing’ with other groups/departments who they need to collaborate with but are just not on the same pathway or much further back. In this context there is continued need for the PM to exploit their people skills in influencing and seeking collaborative relationships with these other groups/departments or with senior management who are not yet so far forward on the adoption journey. So helping these groups ease forward and adapt to be more agile friendly in their interactions and eventually to adopt agile thinking themselves. Another area where I think we’ll still see the PM is in larger corporate environments which are mix-sourcing delivery, so blending on-shore and off-shore development with all the contractual, supplier management concerns that then arise. Another area we see the PM continue to thrive is the system integrator market where agile is considered just one of a number of methodologies they will use to deliver to their customers. Of course the tension the system integrator’s then stumble into is if they cost both project manager and scrum master into a bid they risk being uncompetitive! Which is really begging some sort of hybrid role in these situations.
InfoQ: There can be some overlap in the kind of activities that project managers and Scrum masters are doing. What are your thoughts on combining the role into one person?
Graham Dick: In my experience this is one route that project manager’s take. We often see some of our larger customers make this move when they first “embrace” agile – converting many of their project managers into scrum masters. However, as with most things there are a number of caveats to this seemingly elegant solution.
The most prominent caveat is that as well as a ‘simple’ job description change and learning how to ‘do agile” the project manager has, if she wishes to be truly successful, to embrace the agile mindset shift. And this for the typical fairly directive, driven project manager can be a significant challenge. Principle factors in this transition are first developing sufficient self awareness to appreciate that’s one’s wired-in command and control mentality will actually hamper the development of the agile team. Once the project manager is aware of this then in my experience they have to work really hard to dial down their command and control tendencies and dial up their inner servant leader. This is often fairly straight forward when things are going well, but insert some stress and people tend to revert to type so the sometimes only lightly buried command and control come flooding to the surface and the project manager’s actions and words promptly undo much of the teams emerging self-organisation and collaborative behaviours. Other big learning edges for project managers are simply to learn silence and to take a problem to the team. Or to learn to let the team and other stakeholders on occasion fail so that they can learn from that.
I’ve seen many of these challenges in transitioning project managers that I have coached and trained – sometimes buried deep, sometimes just below the surface!
Summing up – the transition is entirely possible but only when the project manager really learns to dial up his self awareness and self management – which of course leads onto another discussion on emotional intelligence!
InfoQ: What if project managers oppose to an agile transition, any suggestions how to deal with this?
Graham Dick: This is a very real situation we often see. The opposition often comes because they feel threatened by the new agile world. Interestingly we seen some organisations address this by just inviting all PMs to retrain as scrum masters - which of course partially ‘solves’ the problem but also raises a whole bunch of other challenges! To a certain extent then this should not be seen as a surprising situation – in a transition of any size it will happen. Addressing it takes time, takes the establishment of trusting relationships through which one can coach and mentor the PM through their change and work with them so they see agile as something they can benefit from rather than fear. Often part of the challenge is a slug of good old fashioned misunderstanding which can be cleared up. But also reasons for this sort of ‘dysfunction’ can be as simple as the PM feels increasingly squeezed between projects running agile, senior leaders liking the results but middle management still asking for reports etc in the old style. We spend a lot of time with our customers helping develop their agile coach communities. So that’s working with their scrum masters and working with them through a education path where we blend in the numerous soft skills of the professional facilitator and coach to help them up skill. Equipping this community with the coaching and mentoring skills, tools and techniques is part of the answer so they can seek to engage with PMs, turn around their expectations and help them see agile as an opportunity more than a threat. The agile community also needs to appreciate that set backs like this are perfectly normal and should be expected!
InfoQ: Can you give some examples of applying the agile principles to project management?
Graham Dick: The agile principles in a way articulate the mindset shift required of project managers seeking to thrive within an agile environment. For example “simplicity” comes into its own as the project manager refrains from grand-design end to end planning and instead embraces tiered incremental planning. So a 'mile wide inch deep” release plan at the start of the project and then sprint planning each iteration which incrementally builds the plan in a just in time manner. In addition they need to recognise that they are no longer responsible for pulling this together – that is the teams responsibility. 'Welcoming change’ and ‘regular reflection’ exemplify the mindset shift to adaptive planning from predictive planning and continually asking how can we be more effective. ‘Welcoming change’ also ushers in one of the big mindset shifts in that the ‘trick’ with agile is to get working software in front of the customer as soon as possible for only then does the reality of what is being asked for finally start to emerge. We then collaborate daily to steer the software towards what is actually needed. The contrast between this approach and the traditional one of attempting to exhaustively specify all up front, plan out delivery in great detail and then manage to the plan whilst avoiding change can not be greater.
In working with agile coaches I always take them back to the agile principles and values as their coaching bedrock to use when they are helping colleagues to ‘get agile’. In my experience they are incredibly powerful but also remarkably under-utilised.
InfoQ: What do self-organized teams expect from project managers? Are their expectation feasible and realistic?
Graham Dick: The big-deal breaker they expect is for the project manager to retreat from a "command and control” mentality and to buy into the “power of team”. That’s often a huge shift in behaviour as project managers often pride themselves on their abilities to steer and drive complex projects and fight many fires. In agile we’re asking that the project manager essentially step back and give the team the space to thrive inside agile, self organising, collaborating, exploiting daily customer interaction, delivering software to done each iteration. The project manager’s role now moves to become so much more of a support artist. So instead of leading he is a facilitator, coach, remover of sticky impediments. Above all he/she empowers the team and trusts them. As I always say – trust the team because what is the worst that will happen? We’ll stumble in the current iteration and then can pick up the pieces at the retrospective in a spirit of mutual learning. Often working with ‘developing coaches’ we see that although they get all this with their head, in times of stress they start to revert to type and become more directive again. The huge challenge for the project manager (or coach!) is to learn that in times of stress they must especially role-model agile values and principles. This does raise the often thorny issue of performance management as the really effective project manager is far less of the stand-out strong leader than of old. Although the results of his projects should speak louder than words.
InfoQ: You already mentioned the retrospective as an opportunity for the team to learn and take action. Should project managers attend the retrospective?
Graham Dick: Project Managers should first recall that the retrospective is an event by the team and for the team. Having said that, if the project manager is able to attend with the perspective of being another team member then its entirely feasible. Retrospectives present project managers with challenging learning and development opportunities, as they need to appreciate that they don’t have a monopoly on the improvement agenda. They may have a ‘clear idea’ of what needs improving but they need to respect the team’s perspective on this. If they can present their ideas in a truly collaborative manner – such that ownership and ego are parked, then that’s fine but they need to respect their team’s decision. If they want their team to grow and learn then they need to let the team pick what they believe is relevant to address as improvements. I recall from personal experience how as a young developer how mind boggling it was to hear that I could change things! I recall definitely not feeling brave enough to do that then. And that then is the nub of the challenge. If we want our teams to learn to grow and adapt then we need to give them the space, encouragement and support to do this at the pace they feel comfortable with.
The opportunity for the project manager (in the absence of a scrum master) is to grow their coaching muscles and help the team through this transition. When the team have a scrum master then I believe its only polite for the project manager to discuss their attendance with the scrum master first and also discuss how their behaviours can be most appropriate to ensure the teams success. The project manager in this context should be quite comfortable with hearing that maybe the team would prefer her not to attend. That’s not a big deal merely a learning opportunity to reflect and ask what aspects of her behaviours make the team uncomfortable in this situation?
InfoQ: At the Agile Tour London you talked about the project manager as a positive agent for change. Can you elaborate on this?
Graham Dick: Building on a couple of the answers above the project manager gains ‘space’ when agile is done well by their teams. The opportunity is to use that ‘space’ and their sense of purpose and people skills to help their teams address the bigger organisational impediments. At the same time they have to recognise that this will take time! So impediments like: the interface presented by Dev & Ops (so ably described by the DevOps community); like organisations still insisting on individual performance targets at the expense of team working focussed ones; like PMO’s requiring extensive waterfall style reporting etc. So they look outwards but also they can use the ‘space’ to look inwards and help the team live agile better. So brushing up on facilitation skills and coaching skills so that they understand how to better manage their behaviour, how to observe and give effective feedback and how to give the team the space to come forward and account to each other for their commitments they make to each other. Putting these two dimensions together means that the project manager becomes a “small” but important agent for change. Often when we are working with customers in this sort of situation we urge the project managers to form communities of practice so they can support each other in their agile transition and also support each other in addressing the “big impediments” and in championing agile within the wider organisation.
InfoQ: Does this mean that project managers should also act as coaches towards their agile teams?
Graham Dick: One very real development opportunity for project managers is to migrate their role towards that of scrum master / agile coach – which is what some of our customers have done en-masse, effectively doing away with most project managers in the process.
A variation that I believe is practical especially when the full-on migration is just not immediately feasible is for the project manager to start to adapt their behaviours to be more agile friendly and at the same time to start to flex their agile facilitation muscles. By this I mean start to support the team in their efforts to be more agile by facilitating collaborative discussions (generating the appropriate amount of divergent and convergent discussion) about issues/problems rather than imposing or ‘strongly recommending’ a solution as in the past. The project manager can practice idea generating facilitation techniques such as silent brainstorming, thinking hats, open space, mad-sad-glad etc to help the team suggest solutions. They can then facilitate decision making with techniques like open forum, nominal group, devils advocate, voting etc.
I think this is the first level of “coaching” support the project manager could profitably think of. Clearly the team may have an effective scrum master or may be self-facilitating in which case the role of the project manager is to bring his focus and perspectives to the team as another team member.
Although this is all very feasible there is often considerable tension in the role especially as the project manager often interacts direct with the “squeezed middle management” of the organisation (squeezed between teams starting to succeed with agile and senior management starting to like what they see and hear but not themselves leading the necessary change in behaviours). So in reality what we see is that for organisations in transition the project manager often epitomises the tension between the old and the new world views and to thrive in this environment demands considerable “agile thinking” – so there’s an irony!
InfoQ: Collaboration is essential to make agile work in organizations. What in your opinion is the role of project managers in this? And what should team member do themselves?
Graham Dick: The project manager helps in this by stepping back and giving the team space. If the team has an experienced scrum master then that’s great. If they do not then the project manager can whilst stepping back use effective facilitation techniques to help the team members generate ideas and then move to decisions. They can recognise conflict and help teams defuse situations from “me vs you” towards “lets look at the facts”, they can role model collaborative behaviours such as not taking personal ownership of suggestions, respecting ‘questioning’ and remaining calm and objective in their answers – so acting as a team member in a way. Working in these ways helps the team appreciate that collaboration is key and by role modelling collaborative behaviours the project manager demonstrates this. This outlines part of the challenge in front of the project manager, that of moving from controlling and directing the team to a position of facilitating and encouraging and supporting their use of agile. Again, if there is an experienced scrum master / iteration manager available then this is less of a role. Looking outward the opportunity for the project manager is to role model collaborative behaviours with colleagues and other stakeholders – potentially a challenging ask!
InfoQ: Any final advice that you would like to give to project managers when their organization adopts agile?
Graham Dick: the number one advice is that agile is a huge opportunity! In some organisations there will still be clear need for the project manager, albeit with a modified role. In other organisations the opportunity is to morph into a agile coach or enterprise agile coach assisting with the change across the organisation. The other piece of advice is that by supporting and encouraging the team(s) to stick with agile out will emerge a portfolio of projects that have never been so effective and with such transparency.
About the Interviewee
Graham Dick has been involved with Agile since before it was called Agile. A software engineer in a small team in a obscure corner of a large mobile phone company Graham came across the Agile principles mostly by accident and being in the right place at the right time - resulting in the feeling we could tackle any problem – heady stuff! Moving on he spent many years helping organisations get Agile. Graham also spent time working with larger organisational process improvement initiatives and there learned the lessons of sustainable change at scale – something that has mow become super relevant as Agile starts to reach further across the organisation. Graham is an ICAgile accredited trainer offering public and in-house Agile Coach development education programmes also Agile Project Manager, Agile Product Owner and Fundamentals of Agile Behaviour training and blended this in with his work for clients large and small.