Like most project managers (and organizations), you are probably struggling to select the optimal delivery approach. Most of us recognize that traditional approaches don’t guarantee successful delivery and are always looking for a better way.
Agile or iterative development techniques have been receiving a lot of very positive press in recent years as being a significant improvement, resulting in more successful project delivery. Therefore, like most organizations today, yours is probably wondering where and how these agile or iterative development techniques can be best used to improve both the timeliness and success of delivering projects.
In a nutshell, iterative development techniques plan, develop, and implement project functionality in small chunks (or iterations). The key to successful iterative delivery is that each small chunk effectively operates as a smaller mini-project under the umbrella of the total project. As a result, each mini-project iteration can better plan the effort required to deliver a two-week iteration versus a two-year plan. Also, because we’re planning in two-week increments, we can easily adapt the plan for the next two weeks to accommodate any changes identified.
Agile versus traditional case study
I want to pause briefly to describe a non-technical situation, where more success was achieved using an agile approach than a traditional plan.
Let’s use an example of planning a full day’s activities—that’s the project. Like a large project, there is a lot of uncertainty and risk to this: we don’t know what’s going to happen after lunch that could impact our plan, but tradition states that we develop a comprehensive plan for what we’re going to do every hour of the day from waking at 6 AM to going to bed at 11 PM.
By 9 AM, we’re off schedule as traffic delayed us getting to work; at 10 AM we’re called into an emergency meeting; and by noon, the only daily task completed was getting to the office, and even that was behind schedule.
Now, let’s treat this as an agile project where all we plan is the next iteration: getting ready to leave the house (so the stories are: shower, breakfast, and kids off to school). This was all successfully delivered on time and on budget.
So, with confidence, we plan the next iteration, which is getting to the office (drive to bus depot, take commuter train to station, and then city bus to the office).
This doesn’t execute very well: The first story (drive to bus depot) has issues with traffic, so we change the user story to drive to the office and agree that the other two stories can be removed from the iteration plan. On arrival, we plan the next iteration. But in the middle of the planning cycle, a new story is added (the emergency meeting), and it will take the entire next iteration.
Finally, after lunch, things calm down and we’re able to look at the backlog and start on the highest priority tasks; we successfully complete two iterations dealing with the highest priority items in the afternoon.
Had we stuck to the traditional plan, we never would have completed these highest priority items, as they got rescheduled to the next day due to the plan slippage caused by the commute to the office.
What’s the best approach—agile, traditional, or hybrid?
It’s this flexibility to adapt to changing business needs that agile or iterative methods are best at, and why many organizations are adopting it. BUT, is your organization really ready to go “all in” on agile? It’s my experience that there are often many impediments to full-scale agile adoption, most specifically firmly established organization policies that are often less than fully compatible with agile approaches.
Policies such as needing a firm budget, benefits realization statement, and target date before a project can be approved are important (but not really agile). Similarly, organizational implementation policies needing to be followed to ensure there are no impacts to existing operations is critical (but is definitely not agile).
As a result, many organizations are struggling with how to preserve some key “traditional processes” while adapting to iterative methods. The answer is a hybrid delivery model. Parts of the project can be delivered using traditional management methods, and others can be iterative.
Hybrid delivery model
The most common hybrid model I have encountered supports traditional project startup and planning, followed by a series of iterations with breaks for traditional implementation activities for releases, followed by another series of iterations and traditional implementation.
In this model, I develop a traditional deliverable-based work breakdown structure (WBS), which identifies the core deliverables needed in the organization for project approval, such as Project Charter, Project Management Plan, and Project Budget.
These upfront deliverables can be developed and managed using traditional methods to show management that this project is appropriate and is a good place to be investing resources.
With the project approved, it can then move into an iterative approach where a backlog of stories is maintained, and the highest priority stories are selected and fully developed in the next iteration. The view of the project changes from the traditional Gantt chart visual to an interactive drag-and-drop board allowing for dynamic assignment of stories to iterations.
At any time, often on a daily basis, the product owner is able to add, delete, and change the stories in the backlog to reflect the changing business needs.
At the end of each iteration, we pause and do a retrospective evaluation of successes and failures, and make changes to implement needed improvements. Next, and most importantly, we review the product backlog and select the most important stories as candidates for the next iteration. This approach ensures the project works on the most appropriate, highest-value work at all times.
Within each iteration, the team can use agile principles such as the daily standup and discuss the status of the stories scheduled for the current iteration. This way the team has total control over the work completed within an iteration, while still ensuring that the overall project remains current and available for enterprise reporting against resource capacity and portfolio and program status.
A key to agile principles is the ability to implement the ultimate solution in small releases. This has the benefit of being able to use preliminary functionality to achieve some of the anticipated business benefits as quickly as possible.
Also, it has the benefit of early validation of the solution, so that any adjustments can be easily factored into the remaining stories in the product backlog. Therefore, as soon as enough high-priority stories have been completed in the iterations, the project would move back to a traditional cycle and execute standard implementation tasks required by the organization.
These release and implementation activities will be planned and controlled using traditional approaches and will ensure that defined processes are followed to mitigate any impact to existing operations when new projects are implemented.
With the first release complete, the project returns to agile approaches and begins to work through another sequence of iterations to continue development of the remaining stories.
While this “phased” approach to blending agile and traditional approaches is most common, you can combine approaches to support specific project delivery requirements. For example, I managed a project that required an extremely high level of compliance and validation while implementing a new product into a very heavily regulated industry. Therefore, the majority of my project was planned and controlled using traditional methods.
However, there was a business intelligence portion of the project where my company was mining the vast amount of performance data the system was generating; this portion was best supported with an agile approach. For the BI component of the project (running in parallel to the traditional work), we would select the highest priority stories—which could be completed in a three-week sprint—and complete an iteration.
Since many of these stories were exploratory in nature, we would often create new stories either for more exploration or for the creation of specific performance reports. These were simply added to the backlog for consideration for the next sprint.
With this approach, I had a single project schedule that ensured I achieved all the reporting and regulatory steps required, while still allowing an extremely flexible approach to developing the non-regulated business reporting component of the project.
Having all the work in a single schedule provided a single lens into everything happening on this project:
- The information I needed to manage resource allocations to the most appropriate tasks (traditional or agile) was immediately available
- The ability to create powerful weekly and monthly status reports was on hand
Agile is an extremely powerful project delivery approach that should offer significant benefits to your organization’s overall project delivery toolkit. It can be used as a standalone, as part of a phased delivery approach, or integrated into a hybrid delivery structure.
The key is to adopt the agile principles that will help your organization achieve delivery success while adhering to the traditional processes that have helped your organization be successful to date.