Agile and Waterfall processes are not generally considered something that should be mixed. They are mixed – and have to be – as many organizations make the transition from a Waterfall software development and project management methodology to an Agile methodology of the same. The exception being, of course, new organizations or startups that go the Agile only route.
But in reality even as these organizations become larger and their customer base expands, they will encounter customers, excellent on-boarded resources, and other vendors and stakeholders who require – for various reasons – a Waterfall delivery as opposed to an Agile process. It may be a government requirement, or may just be a lack of Agile comfort, adoption, and familiarity.
Not everyone can or will agree to make the jump for whatever reason so the likelihood of maintaining both is high in any organization and industry.
What should be shared across the two methodologies – the Agile focused PMO
To start, it’s probably important to first discuss what aspects of the program should remain unchanged regardless of whether a mixed situation exists or not. First, we recognize that the existing PMO can provide governance across both the Waterfall and the Agile programs. Having a common approach governance will allow key decisions to be made based on the metrics being used.
A key aspect of the PMO is that is should adopt an overall methodology that performs the same core functions of a traditional PMO like Strategy and Investment Funding, Program Management, and Governance, but does so with Agile in mind. While the program change and adoption will need to occur incrementally – it will never happen overnight – the best overall plan is to continually find ways to evolve the PMO towards Agile thinking and the Agile methodology as time progresses.
There are three possible mixed environments scenario in these that must be addressed. These are…
• Independent Teams: Waterfall and Agile programs are completely independent of each other and just need to be deployed in a common release.
• Low Dependency: Some dependencies exist but, success does not require constant synchronization.
• High Dependency: Substantial dependencies exist throughout development, therefore a high level of interaction and synchronization is required in order for each Program to succeed. Each scenario requires a different level of synchronization to ensure the program progresses as planned.
In the independent scenario, synchronization at the Portfolio level within the SAFe framework is sufficient. In the low dependency case, more frequent synchronization is required, at a minimum at the potentially shippable increments of the solution that are defined in the Program level in the framework. And finally, in the high dependency scenario, much more frequent touch points are going to be required that involve team-to-team synchronization. Let’s consider each scenario in greater detail…
Here, the two programs are mainly independent of each other and can be monitored and synchronized. In this scenario, synchronization throughout the project is not required since neither program has deep dependencies on the other. These teams can often even deliver into production at different times or they may come together at the end and be included in the same release in order to maintain consistency with the user community.
In this sense, these teams are synchronized strictly at the Portfolio level of the SAFe framework, since the functionality being delivered by each does not have to be integrated prior to release. Even though the deliverables associated with the teams are independent, it’s still important for the PMO to be able to monitor the progress of each team in a similar manner so that program level reporting and metrics can be consistent.
Low Dependency Teams
This scenario is a bit more complicated and introduces temporal synchronization of the governance milestones that are necessary in order for the teams to ensure their individual components will integrate well. Where possible, programs strive to align these milestones with iteration or PSI
boundaries at the Program Level in the SAFe framework.
Since the Agile team has a faster “clock speed”, it is easier for that team to adjust its plans to align with the Waterfall milestones, than the other way around. This may mean introducing another hardening iteration into the PSI to allow for an integration point or to remove a development iteration if that will allow an earlier integration point.
Ideally, the Waterfall team can also adopt a more incremental approach to developing the product, so that long release cycles are not present and synchronization and integration and thereby fast feedback, comes much earlier in the process.
High Dependency Teams
Finally, the most complicated scenario that requires the highest level of synchronization is the high dependency teams scenario. In this scenario, synchronization is required at the team level and should happen, a minimum, on every iteration boundary. Daily interaction may be required in some cases for key issues or dependencies and could occur both at the technical level (architect to architect or developer to developer) or at the business level (analyst to analyst).
The key is that Agile must not wait for Waterfall. What is meant is the Agile teams should not wait for the Waterfall teams to complete their entiredevelopment cycle before beginning to integrate. Agile teams have built-in processes for these regular synchronizations such as PSI planning, iteration planning, daily stand-ups, scrum of scrums, and iteration demos/retrospectives.
In addition, the high volume of dependencies requires detailed tracking of the dependencies and associated risks/issues. It will be the case that the Agile team needs to make assumptions in order to make progress on its iterations while the Waterfall team progresses towards an integration point. It’s critical that these assumptions be validated on a regular basis and, if needed, be used to drive the appropriate re-factoring within the Agile team for assumptions that didn’t hold true.
The bottom line is this – it is key to start with an Agile mindset, both within the PMO and across the organization. Then, with your PMO continue to evolve into full Agile thinking and behaviors as time progresses. By establishing a common governance structure across both the Agile and Waterfall teams, the PMO can oversee and steer the overall portfolio in the appropriate manner.
By leveraging the inherent flexibility that Agile processes provide, synchronization between the Agile and Waterfall teams is possible at whatever frequency the dependency structure between the teams dictate. In the end, whether the environment is purely SAFe or mixed, the business goal of “sustainably fastest value delivery” is always the same. Win.