How to Make Agile Iteration Possible Within Waterfall Budgeting

Product owners love the flexibility and short lead time of being Agile. At the same time, it can be difficult for management to adopt. Without a determinant understanding of the final product, there’s a struggle to estimate the total cost and rein in scope.  You could mark work as done within a sprint but the feature itself isn’t complete until the total experience is accepted by the business.  Then iterations can turn into scope creep as a “feature” rather than progress, and balloon project cost.

So, I have seen some projects turn back to Waterfall pricing as a defensive play.  The challenge is, the drawbacks of Waterfall haven’t gone away.  What do you do if you start with only a few or still developing requirements?  Or nearly inevitable scope creep?  One solution to mitigate these common pitfalls is utilizing Agile practices in a hybrid approach.

Agile Approach

For shorter projects with tighter timelines, I typically use a Kanban approach.  I particularly recommend Kanban if you don’t have enough requirements solidified at the start to fill out an entire sprint.  Then once the team begins solidifying requirements for multiple features, consider whether or not it makes sense to switch to Scrum.  In either case, work with stakeholders to categorize the long waterfall project planning into key milestones or sprints of well-understood deliverables.  The work should be spaced fairly evenly throughout the project, making adjustments for team capacity in advance.  While the efficiency of the team will increase over each time period, you’ll want to leave room in the project timeline for additional feature iterations.  Product owners and key stakeholders will need to be regularly engaged for the team to progress.

Pre-Project

Whether you will succeed or fail in this endeavor often comes down to management and project stakeholder buy-in to the process during the pre-project planning phase.  Start by presenting the process detailed below end-to-end and explain why it is important. The end goal should be generating a working agreement. Also, consider including appropriate directors and other leadership as attendees to increase the likelihood of buy-in across stakeholders.

1. Identify the features in the project plan that have the largest impact and priority, then sort by ascending effort.
   • Goal: Show value ASAP and develop a working agreement.
2. Consolidate individual features across the scope. Obtain product owner and key stakeholder’s approval.
   • Goal: Efficiency and potential reduction in scope. Standardize look, feel, and behavior.
3. Development team estimates the capacity for each deliverable period.
   • Goal: Ensure available working team aligns with delivery period goals.
   • Tips: Account for time off and other commitments. Plan for backfilling people.
4. Business Analyst and Technical Lead estimate small time periods by key feature milestones to cover the entire scope of the project.
   • Goal: Create checkpoints for ensuring the project is on track and will deliver the final result as expected.
   • Tips: Remember that the efficiency of the delivery team should increase as the project continues. If the workload in your next time period is looking light, pull work forward in the timeline.

Project Start

When the project starts, your steps will continue in a seamless flow as below:

5. Laser focus on solidifying requirements for features.
   • Goal: Prevent rework and ensure the team has a common understanding during working sessions.
   • Tips: Keep the meetings small in attendance – product owner, key stakeholders, business analyst, technical lead, and (optional) developer who will be working on the feature.  You will typically receive more engagement the fewer people you have involved per meeting.  Work ahead to future time periods.  An example rule of thumb for what is solidified, final requirement variation from now until release is <10%.
6. For sprint 0 / 1, assign one or more features to a smaller than usual period of time.
   • Goal: Keep the business engaged, show immediate results, and show the benefit of working in an Agile fashion.
   • Tips: The technical lead can do this while the rest of the team is on-boarded and works on project setup. Use these quick feature wins as examples for how the process could operate going forward and to build trust.  This will help you in obtaining a commitment from the product owner and stakeholders to consistently attend requirements working sessions and demos.
7. Business analyst copies feature requirements to the ticket tracking system.
   • Goal: Requirements are in a single location and are up-to-date.
   • Tips: Include uses cases, error states, validation, messaging, and other common considerations. Decide on who is responsible for copying the meeting or email action items back to the ticket.  For clarifications or other ticket changes, you should include in the comments who directed the change and the date.
8. Developers work with business analysts to split into sub-tasks and work the feature.
   • Goal: Allow developers to work in parallel with individually deliverable pieces.
   • Tips: Decouple delivery from release by building in componentized work and feature toggles. Highlight all work done by the delivery team in the demo, even if it is not visually demoable.
9. Schedule “early-look” feature demos with key stakeholders, even before QA.
   • Goal: Ensure the team is moving in the right direction and finalize requirements before QA tests.
   • Tips: Keep these short and focused. Quite a few people are visual thinkers and have to see how a feature will work in practice before finalizing requirements.  Often you will discover additional use cases and error states during this step!  Stress to the stakeholders that this should be the final lock-in of requirements for this iteration.  Another benefit is developers will work hard to make sure their work is ready for demo, even if the Business Analyst or Technical Lead is the one giving the demo.

Fitting It Together

The individual steps have their own benefits, but it helps to look at the overall schedule.  Here is an example timeline of how this planning might look mid-project.

As you can see, the time period capacity and subsequent velocity generally moves upward as the project progresses, accounting for time-off and holidays.  As the team works to minimize defects and changes in requirements, they have slots open up later in the project to pull work forward or to work on another iteration.  This is beyond the originally planned work, but all still fits within the same timeline and budget!  In part two, I will cover the delivery side of the business process and some final thoughts.  Stay tuned!