YOUR KEY TO PROJECT MANAGEMENT SUCCESS - A HYBRID AGILE FRAMEWORK

Replacing traditional project management methodologies with a hybrid Agile approach can dramatically improve your end results and allow you to deliver on customer requirements and organizational strategic imperatives more effectively. But a cultural shift within the organization is critical to its success. 

It's common (and easy) to blame the traditional, Waterfall approach as the reason why so many projects are in crisis. For the uninitiated, the Waterfall methodology is a linear approach to projects: only when one stage of the process is complete can the next one begin. It's this inflexibility in how Waterfall projects are designed and managed that can create problems.

By contrast, an Agile approach is less constrained, more free-spirited, and flexible to changing customer needs. It works well when time is less critical; that is, a defined, hard date for delivery is not a key project parameter. For example, new product development projects often have many changes throughout their life-cycle because of testing, re-testing, prototyping, changing customer requirements, and so on. The benefits from Agile have led many consultants to consider the methodology switch from Waterfall to Agile for their projects. However, there is risk that this kind of drastic change can create unnecessary and negative cultural impacts, and ultimately be damaging to project success. 

Migrating to a hybrid approach allows for an easier cultural shift.  

The Opportunity
The Waterfall approach to project planning works well when the underlying mechanisms of the project are reasonably well understood. The Waterfall approach requires strong documentation and when there is employee turnover, this helps limit any negative impacts. Some project deliverables lend themselves well to Waterfall. 

For example, training, marketing, identifying customer requirements, and research. They are usually time-bound and follow a relative linear path of work. The Hybrid Waterfall/Agile framework combines the power of Waterfall with the flexibility of agile to accelerate the management of new product development projects. Let's review how you can approach new product development projects using a hybrid Agile framework. 

1. Identify the Key Agile Roles
Product Owner 
This could be the Project Manager and / or Product Manager - and they're responsible for product success in the marketplace. They prioritize product features and are the link between all customers, other stakeholders, and the Sprint Team(s). They're also responsible for deciding which product requirements and features are actually implemented. And they ensure that the decisions about which features to develop occur at the beginning of each iteration, when the Sprint Team is planning its work.

Scrum Master
The Scrum Master can be the Project Manager, if they're familiar with the agile process. They ensure everyone works with an established time-box (time allotted for meetings, decisions, and so on). They lead all Sprint Team meetings and need to know when to get involved, and when to step back in the team. And they have no authority over the team and its decisions. 

Sprint Team members
They estimate the work required to deliver the features and the tasks to be done to complete the required work. They adhere to a common goal and establish rules (norms) for how they will work effectively together (their behaviours). They are also responsible for developing and testing the product, as well as delivering the product features. Ideally, they include no more than seven individuals, including the Product Owner and Scrum Master (larger teams have difficulty in rapid decision making). 

If there are 100 people, the best approach it to break them into 12 teams of seven 'people resources'. The remaining 16 people resources can be assigned as individual contributors where required. 

2. Create the Work Breakdown Structure
Create a detailed work breakdown structure (WBS), using the Waterfall method, for the entire project. Deliverables that will considered for Agile will usually be developed at a higher level of granularity and with longer task durations. 

The Agile user stories (more in step 6) will be created that correlate these WBS tasks. The product backlog (more in step 10) will be created from the WBS output of this session.  

3. Select Project Deliverables and/or Tasks to use in Agile  
Review the entire program plan and identify a deliverable and/or series of Level 2s and 3s. Then determine what to use through Agile by considering the end result or outcome. For example, will it result in a prototype or major feature? This indicates that the deliverable and related activities and tasks will be suitable to take through the Agile process.

The total amount of time to complete should be at least 2 months but no more than 6 months. 

4. Organize an Agile Release Planning Meeting 
This meeting will be time-boxed for up to one day. It includes the Project Manager, Product Owner, customers and/or internal employees who understand the customer's requirements and subject matter experts (likely the same individuals selected for one of the sprint teams, organized after this meeting). During this meeting, the team will create the product vision, user stories and product backlog. 

5. Create the Product Vision  
Similar to the Project Scope\'92s Goal but specific to the product feature(s) or services to be developed through the agile process. The intent is to create and agree on a vision for the work to be undertaken in a two to six month time-box. The entire project might be for two to three years but each Agile process should be for no more than six months. 

6. Create User Stories 
This process starts by defining the roles of who will use the product. User stories are then created from the groups of tasks taken from the project plan. The stories will produce a product feature(s). The project plan tasks are re-written as a story, wish-list item and/or business/customer requirement. For example, a group of Level 3s, when completed, will deliver 'x'. 

User stores will populate the Product Backlog. Bigger stories (stories too big for a sprint) are called Epics. They are broken down into smaller stories when the Sprint Backlog is created. 

7. Calculate Business Value
The team will describe three to five drivers for the entire group of stories. These will identify the Business Value (driven by the Vision). The Business Value helps clarify how the vision will be measured. Measurements can include outcomes. That is, when the product is fully released these measurements (in the business value) will answer the question: how will we know we’ve met the customer and business requirements? 

8. Calculate Effort 
Within Agile we compare all of the User Stories to each other. This measures the relative effort of one story to another. The smallest story is given an effort of 'one'. A larger story might be '20'. This is not a measurement of time or resources. It is a measure of relative effort of one story to another.

9. Calculate Return on Investment (ROI)
The Return on Investment calculation identifies the order the stories should be executed through the team sprints. It is calculated as: ROI = Business Value / Effort. The Product Backlog is created from this Return on Investment number. Once all stories have an ROI number, the team organizes/orders the stories based on this ROI number. The highest ROI is the first and the lowest is the last.  

10. Create the Product Backlog 
The Product Backlog is the master list of all work to be done in the entire Agile process. Essentially it is a list of all the things needed to be done \'96 the 'what' is to be built. The final order of the stories, based on their ROI factor, is used to create the Product Backlog. 

It is a living document that can be changed throughout the entire Agile process. New requirements can be added and existing requirements may be modified, defined in more detail or deleted. As well, the priority of the stories can be changed. 

This is common as sprints are completed and new information is brought forward.  

11. Organize the Sprint Meetings 
Sprint meetings are held to manage all items identified in the product backlog. These 3-week meetings last over the full 2 to 6 month timeframe agreed to for this product feature(s) or services to be developed through the agile process. There are a number of elements required for success:

• The creation of a Sprint Goal for each 3-week sprint.

• The creation of the Sprint Product Backlog for each sprint (items taken from the product backlog)

• The identification of the Sprint Tasks from the sprint product backlog to be managed each day within the 3-week sprint.

• The development of the Sprint Task Board, which identifies the work to be done each day within the sprint. 

12. Hold daily Scrum Meetings
These are daily stand-up meetings held at the beginning of each day (at least 3 times per week) during each sprint for 10 to 15 minutes. The daily scrum meeting is a debrief of what the team has done, will do, and any impediments.

13. Create Sprint Burndown Chart
This chart is created by the Sprint Team after they've created the Sprint Backlog.  It indicates the total remaining team task hours within one sprint. The burndown rate is calculated each day by measuring the hours remaining from the hours originally estimated.  This is plotted on the burndown chart. 

The burndown chart provides information about the current performance (burndown rate) and helps the team determine if the Sprint Goal can be reached in time or if the team has to find additional measures to speed-up completion of the remaining activities. 

14. Schedule Sprint Review and Demo Meeting
The Sprint Review Meeting is held on the last day of each 3-week sprint. The goal is to inspect and adapt the product being built. The team demonstrates its deliverables/working product features to the Product Owner and relevant stakeholders. This is a live demonstration of the product features completed, not a report. 

15. Hold a Sprint Retrospective Meeting
This meeting is held after the Sprint Review Meeting. The Sprint Retrospective Meeting focuses on how the team managed itself. The team assesses its effectiveness in working together throughout the sprint and discusses improvements for the next sprint. 

16. Hold a Backlog Refinement Meeting 
After a couple of sprints it is usually apparent that Product Backlog items need refinement because they are too large and/or poorly understood. In a Backlog Refinement Meeting (sometimes referred to as 'grooming the backlog') the sprint team(s) estimates the amount of effort required to complete the remaining Product Backlog items and provides other technical information to help the Product Owner prioritize them. This meeting is really a pre-sprint planning meeting. The stories for the next sprint are agreed on. 

17. Complete the Product/Release Burn Down Chart 
The Product Burndown chart is an essential part of any agile project and is a way for the team to clearly see what is happening and how progress is being made from one sprint to the next. It is created after each sprint. It shows monthly (per sprint) progress towards the Product Vision and tracks the remaining Product Backlog effort from one sprint to the next. 

The chart provides information about current performance (burn down rate) which helps the team determine if Product Vision can be reached or if additional measures have to be identified to speed-up completion of the remaining stories and activities.

In Summary
When a process is too complicated for a defined Waterfall method, it is more effective to use a hybrid approach, combining Waterfall and Agile frameworks. The hybrid approach provides a number of benefits:

• Ability to manage changing customer, sponsor and other project priorities.

• Increased collaboration with customers to support a market-driven approach.

• Reduced cost of failure figures by finding defects earlier in the development cycle through automated testing.

• Continuous improvement in team development. The team continuously reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

The transition from a Waterfall methodology to hybrid Agile can be challenging, but can be achieved with effective training and coaching of your team.