When I look at newspapers, I come across a lot of failed projects and these are not only waterfall projects. In the Netherlands I have seen agile projects that were stopped after spending more than €200 million. The Standish Group1 presented figures showing that 60% of agile projects were challenged or failed. First figures of a benchmark showed that 30% of agile projects are more expensive than traditional software development (A more detailed study is now running in the Netherlands).
The number of agile frameworks is growing too. If you look at figure 1 Bird’s eye view on the agile frameworks forest2 you can see frameworks on team level related to the process (e.g. Scrum) and the engineering practices used by the team. On product or program level we see frameworks to facilitate temporary projects and programs (e.g. AgilePM or PRINCE2 Agile) and frameworks to facilitate business as usual. This last one can be divided into three groups. Product targeted frameworks facilitating teams(s) of agile teams working on a single product (e.g. SAFe or LeSS), focusing on autonomous teams (e.g. Spotify model) and frameworks to support the agile mindset and culture in an organization (e.g. AgileSHIFT). The top level shows agile frameworks facilitating the portfolio level (e.g. SAFe or AgilePfM). I think that this huge number of different frameworks has a commercial reason and that this number, and it is still growing, has nothing to do with failed agile projects. In this article I focus on five perspectives, namely the project manager, leadership, organizations, teams and culture. For each perspective I look into the traditional and agile view and what’s in between.
Figure 1: Bird’s eye view on the agile frameworks forestThe project manager
A lot has been written about the project manager’s role in traditional (and waterfall) projects. Project managers who are focused on the process, time and budget, using a command and control style, are explicit, and using formal communication. The project manager who selects the people for his or her project teams, who manages the project on a day-to-day basis, who develops work packages for the teams, and escalates when needed to a steering committee. After project closure all people will go back to their own departments. In traditional projects we bring the people to the teams. Maybe six months later a new project will commence, and it starts all over again. A sponsor selects a project manager, the project manager selects the people for the teams, et cetera.
When we look at permanent agile teams, we can say that we bring the work (via the backlog) to the teams. There is no need to build those teams anymore. An agile team has a product owner and a Scrum master, and you could ask yourself if a project manager can add value to this team. If one team is not enough a few teams can use a Scrum of Scrums for the coordination. If you need more teams to create a single product coordination can be managed by an integration team (e.g. Nexus) or a Release Train Engineer and Product Management (SAFe). As a result, many organizations have fired their project managers as part of their agile transition. But I noticed that those organizations are hiring project managers again or introducing new roles with fancy names but what these people are doing is comparable with that of a project manager.
You could ask yourself why are they hiring project managers again? I think there are several reasons. One reason is the fact that if you want to bring work to teams, these teams must exist. If there are no teams you have to build them and who could do that? The embedding of the change is another reason. The agile teams are focusing on the product or software. So, I think these project managers could play a role, in this hybrid structure with temporary and permanent agile teams, by facilitating the agile teams, building new teams, looking after the coordination between the teams, and taking care of the embedding of the output of the project in the organization. These agile project managers will be people oriented, focusing on value, informal and transparent, facilitating and collaborating.
Leadership
More traditional leaders tell and sell what they want to achieve, they convince and push the people to do the job while agile leaders listen and inspire, invite people to pull the work and co-create. The book Turn the ship around from David Marquet is a great example to see the differences between traditional and agile leadership. Do you use a leader-follower or a leader-leader model? Will you give orders or avoid giving them? Will you take or give control? Will you have meetings, or will you have conversations? Will you focus on the process or on the people? Will you protect or pass information? In the book you can find much more.
Probably many organizations will benefit more from agile leadership, but I would say it will be situational. There are situations where a more traditional approach will be a better choice. Probably not for all the mentioned characteristics but for some. Think for example when there is a crisis, issue or deadline that has severe consequences for a lack of action. In this case a more directive leadership style could be more beneficial, definitely when the team is new to a task.
Organizations
Traditional organizations have a functional, silo-based structure and a task delivery focus. Management has the power, sets the strategy and decisions and rules will move from the top to the bottom and reporting will go the other way. They are probably suffering from a lot of bureaucracy with long approval procedures and need for authority approval. There will be a limited tolerance for mistakes.
Organizations who are more agile have a team-based structure, combining different competences and have a value delivery focus. These organizations can be characterized with a servant leadership that shows direction and enables action. The empowered teams are built around end-to-end accountability, hierarchical structures are less important, and the focus is on the actions. Experimentation and learning from mistakes are key. There is a lot of collaboration and cooperation.
Does this mean you have to move away from a traditional organization? McKinsey sees the traditional organizations as “machines” and the more agile organizations as “organisms”. Being a “machine”-organization means efficient and being an “organism”-organization means effective. John P. Kotter explains in his book XLR8 – Accelerate organizations using a dual operating system. On one hand a network structure reflecting the effective agile organization and on the other hand a hierarchical structure reflecting the efficient traditional organization. Staff members can play a role in both systems.
Teams
When do we talk about teams? In the Lonely Planet you can find the following text “Rumoured to be the busiest intersection in the world (and definitely in Japan), Shibuya Crossing is like a giant beating heart, sending people in all directions with every pulsing light change. Hundreds of people – and at peak times upwards of 3000 people – cross at a time, coming from all directions at once, yet still to dodging each other with a practised, nonchalant agility.” Can we see this group of people as a team? They all have the same goal (crossing the street) but the group is far too big for interaction (Dunbar’s number), and team members are not connected.
Have you ever seen Japan’s unique precision walking routines ‘Shuudan koudou’, which means ‘collective action’? It is a unique routine where a group of people put up an amazing display of synchronized walking. This group is definitely a team with a single goal (precision performance), but can individuals act autonomous or embrace changes?
And if we look at a jazz quintet. A small group with a single goal (good performance), where the individuals are connected and co-create music. On the other hand, they can act autonomous and everyone embraces change and acts upon.
Depending on the situation you could need a team to deliver, in an efficient way, specific products of a certain quality. Look at the F1 Red Bull Racing’s pit crew who changed all four tires in 1.91 seconds at the British Grand Prix (June 2019). In other situations, you need a more agile team that performs experiments, is focused on a specific opportunity and is responsible for a specific outcome.
Culture
Many agile transitions fail. In my opinion one of the biggest reasons for failure is a clash between the existing traditional and required agile culture. Jack Duggal in his book The DNA of strategy execution but also Dominik Maximini in his book The Scrum culture compare these different cultures. The traditional organization is organized to execute and sees the customer as an alien. Responsibilities will be delegated to experts. You have to confirm and follow rules and you have to do it right. It’s objective, you choose among defined options. You do the learning before you start doing it. It’s a culture of separate expertise and one of the goals is to drive out variance. Responsibility of line management is the team and more specific the daily operation.
The agile organization is organized to learn and will heavily involve customers. You, a generalist and part of the team, experiment with passion through trial and error and empirically solve problems and the teams learn from doing. Responsibilities will be adopted. Integration of experience is key, and variance will be used to analyze and improve. Responsibility of the line management is a focus on the intrinsic motivation of the individual and the strategy.
Many of the previously mentioned topics like leadership, organization or teams will have its impact on the existing culture too.
Conclusion
It’s not that black and white. My neighbor is in the middle of an agile transition, so I have to move in that direction too. As of next month, the delivery teams will become agile teams so we will fire all our project managers. Look at your own situation. Where are you standing, where do you want to be? Where can you benefit from a more traditional mindset, where from a more agile mindset? What’s the gap, how can you bridge the gap?
And this will not be an easy exercise. Definitely not in the world of today where volatility, uncertainty, complexity and ambiguity (VUCA) are drivers we have to cope with.
Fot. Visual Coach Anna Szczepkowska
This article is an updated version of the 50 shades of gray between agile and waterfall story I presented during the last NTPM 2019 conference in Gdańsk. Of course, an article cannot replace the pictures, sound tracks, movies and interactions I used, but it gives an impression of my message. Feel free to send me your comments henny.portman@planet.nl
- Source: Standish Group CHAOS database FY2012-2016
- Source: https://hennyportman.wordpress.com/2019/01/09/a-birds-eye-view-on-the-agile-frameworks-forest/
Partner of HWP Consulting. He has 40 years of experience in the project management domain. He was the thought leader within NN Group of the PMO domain and responsible for the introduction and application of the PMO methodologies (portfolio, programme and project management) across Europe and Asia. He trains, coaches and directs (senior) programme, project and portfolio managers and project sponsors and built several professional PM(O) communities. He is an accredited P3O, PRINCE2, MSP, MoP, PRINCE2 Agile, AgilePM, and AgileSHIFT trainer and a SPC4 SAFe consultant and trainer too. He is a P3M3 trainer and assessor and PMO Value Ring Certified Consultant (PMO Global Alliance). In addition, Henny is international speaker and author of many articles and books in the PM(O) field and blogger (hennyportman.wordpress.com).