Over the past five years organizations have been making a strong, concerted push to shift to a more agile project management framework from the traditional waterfall model.
According to the 15th Annual State of Agile Report, there has been a strong increase in agile adoption with more than 94% of respondents noting that their organization is practicing agile. Similarly, Goremotely.net reports that 71% of companies use agile approaches as their software development methodology and business project approach.
What Is the Waterfall Development Process?
Waterfall project management is a sequential approach that divides the SDLC to distinct phases such as requirements gathering, analysis and design, coding and unit testing, system and user acceptance testing, and deployment. The next phase can only proceed if the previous phase has been completed. In between phases, a deliverable is expected or a document is signed off.
Why are Organizations Pivoting Away from Waterfall?
Waterfall is more of a sequential approach to project management and it relies on moving through each phase (i.e., analysis, design, development and testing) once receiving sign-off on the prior stage. The challenge is that most projects are not ideal and neat – with the ability to move sequentially through each phase efficiently. Projects (and also products) are more evolutionary. Waterfall does not provide much room for that evolution.
Waterfall provides for many benefits but the challenges can out-weigh key factors in organizational success. Key disadvantages of waterfall include:
- Extended time in the project planning phase. Gathering requirements and obtaining alignment and sign-off can be a very lengthy process;
- Focus on perfectly formatted, often lengthy deliverables (i.e., reports and documentation) which can require more time for already overallocated resources than often proves useful;
- System and UAT testing that occurs only at the end of the project meaning less opportunity for stakeholder input and changes after the initial requirements are gathered. (What stakeholders want on paper and what they want in reality after “seeing” can be very different and changes are now very costly); and,
- Lengthy and sometimes excessive timelines for implementation which can hurt the organization’s return on investment
There are however benefits that are near and dear to a veteran project manager’s heart including:
- Ability to clearly track the detailed schedule, impacts of dependencies, and costs leading to better insight into performance;
- Full discovery and alignment across teams and organizations (whole-system approach) leading to better design;
- Clear agreement on project scope and deliverables. Essentially the “contract” on what the Project Manager (PM) is to deliver is well-defined which can feel like a safety net; and
- Overall less ambiguity in terms of managing the effort.
What Is Agile Development?
Agile development is a team-based approach that emphasizes rapid deployment of a functional application with a focus on customer satisfaction. It defines a time-boxed phase called a sprint with a defined duration of two weeks.
The Agile Challenge
Based on findings about the benefits of Agile, Project management offices (PMOs) want to move toward being an agile organization, but what does that mean? Oftentimes in organizations, it means wanting to use a certain approach to manage and deliver software and business projects iteratively in sprints, but this is a myopic view of agile.
Leadership requests PMOs to transform the organizational project approach to an agile approach. They often want a highly prescriptive, waterfall-like process and set of standardized documentation templates using agile words and practices; however, that is not agile.
Agile is less about having a set suite of actions to take but rather a mindset to develop and principles to apply in the right way to the right situation using a few organizational guardrails.
Go in-depth to learn more about the Agile methodology’s key features.
Create an Agile Team and Embed the Guardrails
Creating an agile team is different from leading a purely agile project. All project teams can be developed to be agile. To do so, establish a few key frameworks within the team or the larger broader organizational project management framework. This will guide the injection of the agile mindset across teams.
1. Daily or multi-day standups
For an IT PM managing a key set of team members, it may make sense for a daily standup or perhaps a PM that works with just one team. However, for PMs working with multiple teams across an enterprise organization, daily standups may be more intrusive than they are beneficial. In those instances, the PM should consider if there is more value out of having two or three standups per week instead.
2. Retrospectives
Meaningful retrospectives at the end of each month or quarter will allow for meaningful discussion on what worked well and how the team can improve. In between meetings, work with your team to determine how to enact those improvements, and then at each monthly or quarterly retrospective, determine if the improvements are working and what modifications are still needed to drive success.
3. Planning sessions
Planning sessions can be used to map out the month or quarter of upcoming work, look ahead into any risks and dependencies and discuss those with the team. Planning sessions allow for the team to conduct resource and risk planning and allow the team to collaboratively drive the scheduling and ownership as opposed to a schedule that is PM-driven, where team members are disconnected from the tasks to be performed.
4. Embed the customer throughout
From the initial intake and understanding of the overall project requirement to the incremental project deliveries, work hand-in-hand with the customer. In the beginning, find out what success means from the customer’s vantage point, then design, develop, review against, and measure against that.
Include the customer in planning sessions, retrospectives, and collaborative documentation sites like Jira. Allow them to see the plan, dependencies, and risks with the ability to refer back to it at their convenience. These are not items to be hidden and shared monthly with the hopes of mitigating them first but rather items that together you can work through to solve in a partnering fashion.
5. Iterative reviews
Whether an item can be released incrementally or not should not stop the team from engaging the customer in the progress. For any IT solution, product, training storyboards, website mockup, etc., keep the customer and stakeholders engaged via iterative reviews, product feature discussions (if applicable), and demos to ensure that the team doesn’t go too far down the road only to find out that the final outcome is not the intended outcome.
6. Organizational communication
None of these high-level changes can occur without organizational level communication and leadership support. Imagine a team of business resources with regular operational work that is now a part of a highly visible, regulatory, time-based project and the PM requests a 15-min standup three times a week with this already very busy team.
While the team will most likely not respond well, nor see the value, it gives the PM an opportunity to touch base multiple times a week to keep the project tasks moving and support any impediments as opposed to waiting for the next weekly meeting and losing four to five days of progress in the process.
Determining If/When a Project Can Be Delivered as Agile
Every project should be managed to include the core principles of an agile framework, but not every project can be incrementally delivered to provide benefits. To determine the level of agile project management, start with the key question: Can the project or product be delivered in such a way that it can provide benefits incrementally? Perhaps a better question is how can the PM structure the project management strategy to obtain iterative benefits from the project or product? Can the product be released in micro-usable components?
When defining the project management strategy, determine when and how a project can iteratively deliver results. That is the point in which it makes sense to transition from a waterfall approach to agile.
Whether fully agile or hybrid, the various approaches can be used throughout. Perhaps a project cannot be released in micro-segments initially. However, the PM can start with a waterfall schedule in MS Project for the initial foundational components; create a Kanban board to help keep the team on track; and manage open actions and a JIRA site to track the requirements, dependencies, risks, and testing or reviews. Once the foundational waterfall aspect completes, they can then transition to a two- or three-week sprint model with incremental deliveries.
Flexible Support for Organizational Challenges
In any toolbox, the user selects the most useful tool to support the challenge at hand. They also combine the tools to get the job done. The project management tool box is no different. It is not a one-tool solution, but rather the flexibility to employ the right tools in the right combination at that right time. The best approach is one that factors in the complexities of the work which often can be found as a hybrid approach of both waterfall and agile tools. Select from the expansive options as they best fit the engagement type or solution, team needs, and organizational challenges.
