By Alex Yakyma.
Project managers exist in many organizations. With agile adoption throughout the industry, it turns out that most of the work tactics of the inglorious past, such as top-to-bottom planning, tracking, big up-front requirements and design, are no longer competitive. Methodologies like Scrum had clearly put project managers out of the scene, calling them "chickens" and claiming that they are not committed. Many authors explicitly call them the "overhead" in an agile organization. Given the overwhelmingly growing need for methods for scaling agility within an enterprise, the following question is becoming more and more important:
Where do project managers fit in the agile enterprise?
To be completely clear about our objective here, we are not trying to legitimize the role of the project manager or his equivalent. Nor do we aim to build a mapping of responsibilities or see how we could sneak traditional methods into the agile world just to ensure that a certain number of jobs remain secure. In fact, there are hordes of project managers who, for months, if not for years, have not been able to figure out how they fit into this new Lean | Agile paradigm. For the most part, these people should be given a chance to succeed elsewhere – agile teams only need strong and courageous enablers who are capable of challenging existing organizational rules and procedures in order to enable a fast sustainable value flow. But the question remains – if they (project managers) can't even enable themselves, then who needs them?
That being said, there are people who hold this position and are effective leaders, who, instead of impeding agility, end up being essentially helpful. I personally know such people – they embrace Lean thinking, paradigms of agile software engineering, and lead teams and programs to better alignment with business needs, a faster flow, and eventually assist the organization in its agile transformation at scale. Moreover, the actual reality of a large organization makes us think beyond the simplistic chicken and pig metaphor in order to realistically cope with external dependencies and overall organizational resistance to any change that could expose the dysfunctional aspects of its behavior. There is wide variety of areas where these people are able to help tremendously, and that is what I would like to explore in this article. But prior to starting our journey, it is necessary to indicate exactly
what these people should
stop doing once they embrace their new role, and that is...
managing people on the teams in the context of their daily engineering activities. This has to unconditionally go away. Agile teams essentially estimate and plan their work, and they make most of tactical decisions on their own and do not require anyone to micromanage them.
There must be a conceptual shift from a manager-centric model towards a team-member centric model, where the project manager strives to find a way to enable teams in all possible aspects, instead of becoming a bottleneck for their daily work, as well as encouraging team members’ learning process and continuous improvement. Below are the areas where project managers are indeed capable of helping. It takes much more skill, expertise and courage then creating another Gantt chart or time reporting process. But this real leadership becomes quickly visible due to the fast feedback loops in the Lean | Agile enterprise, and serves as an optimum strategy to make a meaning and impact on your organization. Here are those areas where they may benefit the organization:
1. Foster organizational changes in bottleneck areas. This is the toughest one that requires real courage to challenge what has been believed to be best practices (or at least necessary ones) within your organization for years and years. Teams extremely appreciate effective help in this regard, whether it is an overly heavyweight procedure of deployment, obtaining approvals for something, receiving admin/ops/production support, or such a useless thing as time reporting, etc. The people who created these procedures in the first place are most likely ignorant in terms of lean thinking or understanding the principles of flow. Thus, what they have created for repetitive use by agile teams not only could be, but rather actually
should be challenged. Most project managers simply fail in this respect, as their role never actually requires taking a chance by changing the status quo within the organization. Now, not only have they fallen outside of their own comfort zone, but they also have to challenge the status quo of others. A very simple formula works here: no courage – no result.
2. Create an environment that fosters the right team behavior. Work to eliminate individualistic performance review models. Instead, work to embrace team-centric improvement objectives, where individuals are left with a wide variety of options to manifest spontaneous situational leadership in different domains and thus, be evaluated "according to their contribution" to these team-centric objectives. Work hard with teams and communities of practice in terms of adopting collaborative agile practices such as side-by-side (and pair-) programming, specification by example, ATDD, and continuous integration. These are not just engineering techniques, but important cultural scenarios within and across teams.
3. Make key problems at scale visible and unambiguous to everyone. This should be done so that they can actualize and collaboratively improve once the problem becomes apparent. Is the problem due to too much work-in-progress across multiple teams, excessive delays on the part of ops teams, or too much rework of overly detailed design specs, or it is due to something else? People in our industry are not stupid, but they have become rather blinded by decades of theories promoting overly hierarchical methods of “managing” an organization’s productivity by maximizing utilization. Unfortunately, this has made the flow and thinking around the flow of value somewhat counter intuitive to us. This is something you’ll have to change. Make it visible to developers, testers, your fellow PMs, other departments and upper management by efficiently using BVIRs and actively engaging people in a conversation about how the work is flowing (well, unfortunately it will be mostly about how and why
it doesn’t flow). This should all stimulate reflection and adaptation on their behalf, which you will also likely need to actively facilitate.
4. Help teams to embrace essential agility. Practically guide them through real challenging things such as splitting value into vertical slices, working collaboratively on those slices, or continuously refactoring code to enable future value delivery, or defining effective acceptance tests. These are all very challenging things that require a substantial shift in the team’s mentality. This is much more important at scale and much harder to achieve than simply ensuring that the team formally follows the Scrum ceremonies.
5. Educate your peers and upper management in Lean thinking. Show your peers and management how your teams resolve real problems in action, how they plan, how they resolve dependencies during execution, and how they demo. Teach them "indiscernibly" by engaging them in "Gemba kaizen" – the "real place" where all of the action actually takes place. Stimulate curiosity and encourage them to challenge existing rules and processes. Be patient as it takes time, but take every opportunity to present the results to other people in the organization and take every opportunity to involve them in the collaborative workshops for your teams – such events speak for themselves without any words.
6. Engage business stakeholders in alignment sessions. Events like program backlog grooming, release planning, release demo, etc. are pretty much useless if they are done only by the teams without synchronizing actual plans with product managers, infrastructure managers, the system/enterprise architect, and other people that have stake in the forthcoming scope. The recipe is simple: developers, testers and product owners from different teams should come together in the same room with business stakeholders.
7. Facilitate learning within and across teams. Build and facilitate different communities of practice (CoPs) for Scrum Masters, Product Owners, developers and testers, where they can exchange the proven best practices emerging in their agile team.
8. Create a balanced decentralized decision-making model. Essentially, tactical decisions need to be made quickly by the people who actually do the work and know best what should be done. Legacy mindsets and cultural scenarios within teams may largely prevent such decentralization and paralyze the flow. You should practically guide teams through the decision-making process and coach them in real scenarios whenever they stumble. Over time, this will transform them into a substantially self-organizing and self-managing team and will allow you to concentrate on identifying the next bottleneck in the organization, requiring your dedicated work as an enabler.
Rather recently, I had a talk with a bunch of project managers at one of the world’s largest organizations (unfortunately, I am not entitled to specifically name them here) regarding their role in agile enterprise, and it took quite a bit of time to go through all topics of interest. I have only summarized some of them in this post, but there are many more and they require your attention. However, to execute your agenda, you need to start small and realize that your ability for analytical thinking, your passion and unconditional courage must be combined together to do the job. Start the journey as soon as possible as there is a long way to go.
