The Hybrid/Agile Project Management Process

The Hybrid/Agile Project Management Process

Combining traditional Waterfall project management methodologies into a Hybrid model positively impacts the way projects are planned and managed.  A Hybrid approach will increase the end results, improve the delivery of customer requirements and help the organization realize its strategic imperatives.  The process steps included in this article does require an organizational cultural shift.  This is critical to its success, but it is an exciting journey to take.

Hybrid/Agile Project Management Process

1.  Define the project’s goal and deliverables

  • Confirm the Project Manager role.  This will be the individual accountable for success of the entire project.  They will assign work and get the status of work completed for the waterfall portion of the project.
  • Scope out the project’s goal, deliverables and deadline for completion.

2.  Select Project Deliverables

The project manager will determine how the delivery of the deliverables will improve the overall quality of delivery of the project.  To realize this, they will identify which deliverables have:

  • Elements of certainty (linear processes such as marketing, training, manufacturing)
  • Elements of uncertainty (i.e.; product/service/ software development, innovation)
  • Use waterfall to manage the deliverables with certainties.
  • Use Agile to manage the deliverables with uncertainties.

According to Andy Jordan in his article of September 2018, “Hybrid Is Not the New Agile!”
Andy Jordan – September/2018, “Individuals cannot become effective managers of hybrid projects by simply learning a new approach. The must have the judgement to be able to determine which approach to use for each individual element of the projects they are managing, and the ability to adapt those elements to the needs of the project.”

3.  Assess Risks

  • Review all deliverables to identify the risks that might prevent success.
  • Create mitigation tasks to reduce risk likelihood for all deliverables.
  • Add the mitigation tasks to the waterfall plans to be created from the deliverables with elements of certainty.
  • Add mitigation tasks to the Agile user stories to be created from the deliverables with elements of uncertainty.

4.  Identify Agile Roles

  • Product Owner – Link between all customers, stakeholders and Sprint Team(s).  Responsible for deciding which product requirements and features are implemented.
  • Scrum Master – the Sprint Team facilitator.  They help, guide and coach the Sprint Team members to self-organize and support them whenever they encounter problems.
  • Sprint Team members – Identify what and how much they can do in each Estimate the work required to deliver the product features and the tasks to be done in each sprint (2 or 3-week iteration).

5.  Organize Agile Release Planning Meeting (ARP)

  • This is where Agile begins.  During this 1 to 2 day meeting the product owner, scrum master, stakeholders and Subject Matter Experts develop the product vision, user stories and product backlog.
  • This is the most important, yet most often overlooked agile process.  Incredibly, many organizations start with Sprints.  However, it is the ARP meeting that sets the right direction and deadline for the Agile project.

6.  Create the Product Vision

  • Reach agreement, in the ARP meeting, 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 (sum of all sprints) should be no more than 6 months.

7.  Define User Actors & Stories

  • Start by defining who will use the product.  These will be the user and customer roles.  They are described as the “actors”.  Briefly describe what each actor wants or needs and what you’ll do to meet their requirement(s).
  • Then create User Stories.  Each story will produce a product feature(s) for the users and customers.  User stories are written as: “As an actor I want/need/must have so that…. can be achieved/realized or – As an actor I can…so that…”

8.  Determine Business Value (BV)

  • The ARP team describes 3 to 5 drivers for the entire group of stories.  These 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?”
  • Then the ARP team will determine a Business Value for each story.  The user story with the biggest/most business value is given a value of 100.  All other stories are weighted against this one and given a business value.

9.  Estimate Story Efforts

  • This is a measurement of the relative effort of one story to another, rather than individual effort or duration of time per task (as in traditional project planning).  The smallest story is given an effort of “1”.  A larger story might be “20”.  Rather than being a measurement of time or resources it represents a measure of relative effort of one story to another.  That is, how difficult it will be to do the work of one story when compared to another.

10.  Calculate Return on Investment (ROI)

  • The Return on Investment calculation identifies the order that stories will be executed through the sprint teams.  The ROI is calculated as: Business Value/Effort.

11.  Organize/Order the User Stories

  • The ARP team organizes/orders the stories based on the ROI value.  Once completed, teams can re-order, based on technical or other obvious dependencies.

12.  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 that need to be done – the “what” that is to be built.
  • The Product Backlog is created from the final order of user stories.  Stories that are too big for a single sprint are called Epics.  These will be broken down into smaller stories when the Sprint Backlog is created.  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.

13. Organize First Sprint

  • Determine the total number of meetings required to meet all the Product Backlog requirements.   This will define when all Sprints will be completed, and the product vision realized.  Then the first Sprint can be organized.

14.  Develop the Sprint Goal

  • The Product Owner will start the sprint meeting by working collaboratively with the team to determine the Sprint Goal.  This defines the outcome for this 2 or 3-week sprint.   It is a one- or two-sentence description of what the Sprint Team plans to achieve during the Sprint.

15.  Create the Sprint Backlog

  • These are the user stories, taken from the Product Backlog, that the Sprint Team agrees it can complete during the Sprint.

16.  Identify the Daily Sprint Tasks

  • The Sprint Team breaks down the product backlog user stories and enters these into a Sprint Backlog.  These become the Sprint tasks that they will complete each day during their Sprint.

17.  Create a Kanban Board

  • During the Sprint, the Kanban Board is created on a white board or other visual to illustrate: the Sprint backlog stories, Sprint tasks, tasks started and tasks completed.

18.  Hold a Daily Sprint Meeting

These are daily sprint team stand-up meetings.  They are held for only 10 to 15 minutes.  During these meetings, the Sprint Team presents to each other, not the Scrum Master.  The Scrum Master facilitates the meeting and the Product Owner often attends. During the daily stand-up meeting, each team member answers three questions:

  • What did I do yesterday that helped the team meet the Sprint goal?
  • What will I do today to help the team meet the Sprint goal?
  • What impediments are in my way? (Do I see any impediment that prevents me or the team from meeting the Sprint goal?)

19.  Create the Sprint Burndown Chart

  • This chart is created by the Sprint Team after they’ve created their Sprint Backlog and Kanban Board.   It indicates the total remaining team task hours within their Sprint by illustrating the progress within the Sprint toward the Sprint Goal.
  • It is re-estimated daily, at the end of the daily Sprint meeting.  This provides information about the current performance (burn down rate) of the Sprint which helps the team determine if the Sprint Goal can be reached in time or if additional measures are needed to speed-up completion of the remaining activities.

20.  Hold a Sprint Review & Demo Meeting

  • This meeting is held on the last day of each Sprint.  This demo is done as a live demonstration of the working product features completed.  It isn’t a report. The goal is to provide an opportunity for the Product Owner and users/stakeholders to inspect and analyze the product that is being built and to measure it against the Sprint goal.

21.  Hold a Sprint Retrospective Meeting

  • This meeting is held after the Sprint Review Meeting.  During this meeting the team assesses their effectiveness working together throughout the sprint and discusses how they can improve their effort during the next Sprint.

22.  Hold a Backlog Refinement Meeting

  • After a couple of Sprints, it is usually apparent that the Product Backlog items need refinement.  This might be because they are too large and/or poorly understood.  During this meeting, 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 “grooming” process identifies what user stories will be used for the next Sprints.

23.  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 illustrates the progress of the Sprints towards realizing the Product Vision.  It provides information about the current performance (burn down rate) so that the team can determine if the Product Vision can be reached or if additional measures are necessary to speed-up completion of the remaining user stories.

24.  Estimate Sprint Velocity

  • Velocity is a metric that predicts how much work a Sprint Team can successfully complete within their Sprint and how many more sprints are required to complete all product backlog user stories.

25.  Continue Sprint Meetings Until All Product Backlog User Stories Completed Project Productivity

  • Most often project productivity initially dips when moving to a Hybrid or especially a pure Agile approach.  Well-trained teams can take up to a year to reach their full potential. They’ll need continuous coaching and mentoring from highly trained and skilled scrum masters.
  • Agile enthusiasts sometimes forget that the leadership team expects the entire project to be completed by a pre-determined date and to realize specific, measurable outcomes that align with one or more of their strategic imperatives.  It is critical that communications and reports be delivered to them to create an understanding of how the Sprint Teams are working towards realizing their goals.  Reports and communications on the successes of each Sprint and the ability of the project and Sprint Teams to work toward the final project goal are crucial.

Project Productivity

Most often project productivity initially dips when moving to a Hybrid or especially a pure agile approach.   Well-trained teams can take up to a year to reach their full potential.  They’ll need continuous coaching and mentoring from highly trained and skilled scrum masters.

Agile enthusiasts sometimes forget that the leadership team expects the entire project to be completed by a pre-determined date and to realize specific, measurable outcomes that align with one or more of their strategic imperatives.  It is critical that communications and reports be delivered to them to create an understanding of how the Sprint Teams are working towards realizing their goals.  Reports and communications on the successes of each Sprint and the ability of the project and Sprint teams to work toward the final project goal are crucial.

Ensuring Your Success

Prepare people for the changes in adapting to the Hybrid way of doing things.  Combining traditional project management methods with Agile methods impacts how projects are planned and managed.  It will improve the delivery of customer requirements and helps the organization realize its strategic imperatives. However, a cultural shift is critical to its success.

 

 

 

 

 

 

 

 

Michael Stanleigh

Michael Stanleigh, CMC, CSP, CSM is the CEO of Business Improvement Architects. He works with leaders and their teams around the world to improve organizational performance by helping them to define their strategic direction, increase leadership performance, create cultures that drive innovation and improve project and quality management. Michael’s experience spans public and private sector organizations in over 20 different countries. He also delivers presentations to businesses and conferences throughout the world. In addition to his consulting practice and global speaking he has been featured and published in over 500 different magazines and industry publications.

For more information about this article you may contact Michael Stanleigh at mstanleigh@bia.ca