Rapid Product Development Projects Using a Hybrid Agile Framework

Editor's Note: Take a look at our featured best practice, Pricing Strategy (38-slide PowerPoint presentation). Pricing Strategy is a core pillar of Marketing and Product Strategy. It is 1 of the 4 Ps of Marketing (also known as the Marketing Mix - Product, Price, Placement, and Promotion). As such, knowing how to properly price your product is extremely important to the commercial success and viability of [read more]

Also, if you are interested in becoming an expert on Strategy Development, take a look at Flevy's Strategy Development Frameworks offering here. This is a curated collection of best practice frameworks based on the thought leadership of leading consulting firms, academics, and recognized subject matter experts. By learning and applying these concepts, you can you stay ahead of the curve. Full details here.

* * * *

Why Agile Matters to Consultants

Combining traditional project management methodologies with hybrid models impacts the way projects are planned and managed.  A hybrid approach can increase the end results, delivering customer requirements and organizational strategic imperatives.  But a cultural shift within the organization is critical to its success.   

It is easy to blame the traditional, waterfall approach to why so many projects are in crisis.  Maybe it’s because of the linear approach to how these projects are designed and managed.  Agile seems less constrained, more free spirited and more 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.  They have a specific deadline which must be met or the company can lose market share.

Moving to a hybrid approach means training and cultural adjustments.  Agile can seem daunting to project managers and teams accustomed to working in a pure waterfall environment.  Moving from one method directly to another can be damaging to project success.  Migrating to a hybrid approach allows for an easier cultural shift.  As projects become more complex, standard project planning becomes more challenging.

Many organizations are still managing their projects using waterfall.  Training and coaching helps make the cultural shift to a hybrid approach.  Consultants who are solely focused on agile often create unnecessary and negative cultural impacts on an organization.  They don’t understand how to manage the change from traditional to agile.  Nor do they consider a hybrid approach.  They tend to throw out the old and expect an immediate adherence to the new.  There are many reasons for this severe approach to change but one of them is that they really only know agile – they lack an understanding of traditional project management models.   Hybrid trained consultants can help organizations successfully migrate to a hybrid approach because of their combined knowledge of waterfall and agile project management methodologies.

Consultants understand the change management process.  Changing the management of projects from the traditional to the agile or hybrid approach requires a shift in culture.   Agile is built on the concept of breaking down the project schedule into smaller, more manageable work components.  This is effective for longer projects or projects where not all the design elements of the product are clear.  Projects that require innovative approaches to realize the final product design will often benefit from an agile approach to their development.

The Opportunity

The Waterfall approach to project planning works well when the underlying mechanisms of the project are reasonably understood.   As well, when there is employee turnover, waterfall’s strong documentation allows for minimal project impact.  Some project deliverables lend themselves well to the Waterfall approach.  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.  

Hybrid Agile Framework

1. Identify the Key Agile Roles

Product Owner

• Can be the Project Manager and/or Product Manager
• Responsible for product success in the marketplace.
• Prioritizes product features.
• Link between all customers and other stakeholders and the Sprint Team(s).
• Responsible for deciding which product requirements and features are actually implemented.
• Ensures that the decisions regarding which of the features to develop, occur at the beginning of each iteration, when the Sprint Team is planning their work.

Scrum Master (can be the Project Manager)

• Can be the Project Manager, if familiar with the agile process.
• Ensures everyone works with established timebox (time allotted for meetings, decisions and so on).
• Leads all Sprint Meetings
• Needs to know when to get involved and when to step back in the team.
• Has no authority over the team and its decisions.

Sprint Team Members

• Estimates the work required to deliver the features and the tasks to be done to complete the required work.
• Adheres to a common goal and establish rules (norms) for how they will work effectively together (their behaviours).
• Develops and tests the product and delivers the product features.
• Ideally includes no more than 7 individuals including the Product Owner and Scrum Master (larger teams have difficulty in rapid decision making).
• If there are 100 people resources the best approach it to break them into 12 teams of 7 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 (step 6) will be created that correlate these WBS tasks.
• The Product Backlog (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.
• 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 1 day.  It includes the Project Manager, Product Owner, customers and/or internal employees who understand the customer’s requirements and subject matter experts (likely be the same individuals selected to join one of the sprint teams, organized after this meeting).
• During this Agile Release Planning meeting the team will create the product vision, user stories and product backlog.

5. Create the Product Vision  

• Similar to the Project Scope’s 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 2 to 6 month “timebox”.  The entire project might be for 2 to 3 years but each Agile process should be for no more than 6 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 that are too big for a sprint) are called Epics.  They will get broken down into smaller stories when the Sprint Backlog is created.

7. Calculate Business Value

• The team will describe 3 to 5 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 will be given an effort of 1.  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:

Return on Investment (ROI) = Business Value / Effort

• The Product Backlog will be created from this Return on Investment number.
• Once all of the stories have an ROI number, the team organizes/orders the stories based on this ROI number.  The highest ROI will be the first and the lowest will be 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 – 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 of the items identified in the product backlog.  These 3-week meetings will 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.  They are held for 10 to 15 minutes.
• The daily scrum meeting is a debrief of what the team has done, will do and their impediments.

13. Create Sprint Burndown Chart

• This chart is created by the Sprint Team after they’ve created their 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 (burn down rate) which 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 that is being built. The team will ddemonstrates their deliverables/working product features to the Product Owner and relevant stakeholders.   This Demo is done as 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 is focussed on how the team managed itself.  The team assesses their effectiveness in working together throughout the Sprint and discusses what improvements can be made during the next Sprint.

16. Hold a Backlog Refinement Meeting

• After a couple of sprints it is usually apparent that the 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-upon.

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.

Summary

When a process is too complicated for a defined Waterfall method, it is more effective to use a hybrid approach which combines the Waterfall and Agile framework.    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 their behaviour accordingly.

Want to Achieve Excellence in Strategy Development?

Gain the knowledge and develop the expertise to become an expert in Strategy Development. Our frameworks are based on the thought leadership of leading consulting firms, academics, and recognized subject matter experts. Click here for full details.

"Strategy without Tactics is the slowest route to victory. Tactics without Strategy is the noise before defeat." - Sun Tzu

For effective Strategy Development and Strategic Planning, we must master both Strategy and Tactics. Our frameworks cover all phases of Strategy, from Strategy Design and Formulation to Strategy Deployment and Execution; as well as all levels of Strategy, from Corporate Strategy to Business Strategy to "Tactical" Strategy. Many of these methodologies are authored by global strategy consulting firms and have been successfully implemented at their Fortune 100 client organizations.

These frameworks include Porter's Five Forces, BCG Growth-Share Matrix, Greiner's Growth Model, Capabilities-driven Strategy (CDS), Business Model Innovation (BMI), Value Chain Analysis (VCA), Endgame Niche Strategies, Value Patterns, Integrated Strategy Model for Value Creation, Scenario Planning, to name a few.

Learn about our Strategy Development Best Practice Frameworks here.