One of the challenges I have discussed with a number of organizations that are expanding their use of agile is the difficulty of having team members who need to work with both agile and traditional/waterfall approaches. When agile represented just a small, specialized area of project execution, it was relatively easy to have a few dedicated agile teams, create continuity among those team members and benefit from teams who grew together from one project to the next.
As agile grows, there are more variables introduced that make it harder to keep those dedicated teams intact. Agile projects cover broader areas requiring different skillsets, and the variability in agile workloads means that the number of agile resources and teams grows and declines with the business cycle. In addition, as agile expands into new business areas, new people need to be trained in agile—and those individuals and areas need to be integrated with existing agile teams.
Inevitably, as these changes happen there are individuals who find themselves shifting between agile and waterfall projects, and that can cause a lot of disruption to an organization. Individuals will naturally prefer one of the two environments—either the structure and predictability of waterfall, or the self-managed (relative) freedom of agile. That will lead to lower engagement and motivation when they are asked to work in areas they are less comfortable with, and that will drag down overall performance.
In addition, it takes people to adjust from one approach to another, just as it takes time to adjust when team members change. That further impacts performance, and when the shift in approach is combined with a shift in the team members, the individual is working with a loss in productivity that can be significant and long lasting.
When further evolution occurs and we introduce hybrid projects, the potential for disruption grows further. Now we don’t just have people shifting between agile and waterfall projects, they are also asked to work on projects where the approach they take is different from other areas within the project. That requires them to understand and incorporate transitions between the approaches, which again impacts productivity. If someone is working with an approach they are less comfortable with, they now also have to deal with their preferred approach being conducted by others right in front of them.
So how do we deal with this? Do we have to minimize these disruption scenarios, or can we create an environment where teams are more comfortable with the shifts?
The right solution, not the easy solution
The easy answer is to look for ways to eliminate the need for team members to move between agile work and waterfall work. However, very few organizations will be able to become 100% agile or 100% waterfall. The ability to choose between approaches is required to maximize performance — not all projects benefit from the same approach.
As a result, if we define resources as dedicated to agile or waterfall, we are limiting the project execution capacity we have and limiting resource efficiency. For example, if 50% of our project resources are dedicated to each approach but 60% of our current project load is agile, we will have underutilized resources on the waterfall side and projects being delayed on the agile side.
To try and solve this issue, organizations are frequently tempted to create a hybrid methodology—not hybrid projects that have elements of both, rather an overarching approach to project execution that combines agile and waterfall elements into a third methodology. This offers a compromise that allows the more adaptable project resources from each approach to work on hybrid projects as necessary, maintaining resource utilization and preventing projects from being delayed.
This is a tempting approach, but I don’t like it for many reasons—not least it requires compromise everywhere, and compromise frequently creates a lose/lose situation. Firstly, a subset of projects that are designed for waterfall and/or agile execution will actually be managed through a less optimal hybrid approach. Secondly, resources will have to move away from where they want to work, just moved to a “less bad” option in the hope they will be less disrupted by a smaller shift.
From an organizational standpoint, this approach also requires a third methodology to be managed and maintained. In a number of situations, I have seen hybrid grow to be the dominant methodology because it is more acceptable to some stakeholders than the preferred approach, and we should not be choosing how to execute work based predominantly on appeasing stakeholders!
The better, but admittedly more difficult, approach is to stick to agile or waterfall methodologies, but to encourage hybrid projects (purely agile and purely waterfall work packages within the same project) where necessary. This requires us to build a pool of project resources who are not only more comfortable with both approaches, but can work effectively and efficiently in an environment with elements of both. For that to be achieved, we need to address three areas: understanding, flexibility and support.
Understanding should be the simplest, so let’s start there. We have to ensure resources working in a hybrid environment understand not just the mechanics of agile and waterfall—what makes them different in how they operate — but also why we might choose one approach over another in different circumstances.
We also need to provide an explanation of why one or the other approach was selected for the specific initiative each individual is currently working on; and, when the project uses a combination of hybrid and waterfall approaches, why the combination was chosen. We also have to provide team members on hybrid projects an understanding of how agile and waterfall elements are going to interact—we can’t just set up two separate sets of work and ignore the need for work to be passed between those areas.
Flexibility is the next piece, and I believe the most important. This is an element that organizations can find difficult, but that helps move project execution to a more flexible and adaptable discipline that will ultimately allow for greater success.
This involves removing some of the structure and rigor around project execution (waterfall in particular), and allowing teams to operate with a degree of autonomy. In agile, this premise is built in; the self-managed team concept is fundamental.
In waterfall, however, work is frequently rigorously controlled to the point of team members having assigned task lists broken out into individual days, or even fractions of days. Removing some of this control will reduce the reluctance of resources to work on waterfall tasks and will serve to increase motivation and commitment. This doesn’t mean the waterfall approach should be abandoned (it’s still important at the project level), but it should be “eased” at the task level, where team members operate.
Support is simply ensuring there is active and constructive support provided to team members regardless of how they operate. High-performing teams need to feel as though they are working in a comfortable and familiar environment, and introducing hybrid elements can compromise that comfort. The PM and other key stakeholders need to recognize this and consciously work toward making individuals and the collective team feel comfortable.
In a practical sense, that may be no more than answering questions on the different project approaches and how they are being applied. From a soft-skills perspective, it is providing more time for people to adapt, being more tolerant of variances to process while people adapt and allowing time for people to adjust by providing easier deadlines/deliverables in the early stages.
Organizations have been dealing with how they effectively create hybrid agile and waterfall environments for some time now — the growth of agile has made it a necessity. With a few exceptions, this is proving to be a difficult adaptation. Organizations are finding it difficult to operate the two approaches in an integrated fashion.
If it is difficult for organizations to make the adjustment, then it’s understandable it will be more difficult for project managers. They are dealing with the details of hybrid on a daily basis, and having to figure out how to apply the organizational principles as they go. Of course one of the reasons why it is so difficult for PMs is because of how hard it is for their team members.
Project team members rely on an established project execution approach to provide the framework to their work. It allows them to focus on the work they are doing and not have to divert their focus toward understanding the “how” of that work. When we confuse that framework by introducing hybrid elements, we make it much harder for team members to concentrate on their tasks and increase their reliance on PMs to provide clarity to the situations, which in turn makes it harder for the PM.
There are no easy solutions to this. Organizations must take the time to help all levels of project execution understand the impact a hybrid approach will have — and it has to start at the front line of project team members.
Ready to get your copy of the PMBOK® Guide – Sixth Edition and Agile Practice Guide?