What’s your Hybrid?

As project managers we love our definitions. Our definition of done. Our measures of success, our detailed schedules, our work breakdown structures, our defined scope or product backlogs. We navigate the grey areas as investigative analysts to seek out clarity for our stakeholders. Through definition we are able to communicate effectively and lead our project team with that sturdy comfort of direction that we need in order to sail towards and reach our ultimate destination.

What method or approach will you choose for your project to reach your destination? A waterfall approach? An Agile approach? Or a Hybrid approach? I won’t go into the details of what a waterfall or agile approach would look like, and will assume that you are are already familiar with waterfall and have some understanding of the various agile methodologies out there. Rather I would like to focus on what a lot of people call a Hybrid approach. Hybrid by my definition is a blend or combination of elements to form something new. If someone was to refer to their project methodology as a Hybrid methodology, it would not give me any detail as to how they are actually approaching the delivery of their project. It would be the same as me asking someone what vehicle they drive, and them answering: ‘Oh I drive a hybrid’. This would give me no indication of what make and model of vehicle they drive, how many passengers their vehicle can take, or how many wheels it has. Only details left up to the imagination of how they would arrive at their destination.

We each have our own definitions of what a Hybrid approach would look like. I’d like to share one version of a Hybrid approach that has worked well for me.

My version of a hybrid delivery approach means that the requirements gathering and documenting is performed in a traditional waterfall style approach. The requirements are captured in a format known as User Stories. The IT consulting vendor will structure the workshops in a Waterfall manner in order to refine their understanding of the requirements and user stories.

The actual delivery and implementation is conducted in a waterfall manner which means that requirements for the system will be refined in an Analysis & Design phase and these requirements are captured as user stories into a product backlog. The minimum viable product features are determined from the product backlog and form the scope of the build and delivery phase.

During the build and delivery phase agile principles specifically the scrum framework project ceremonies such as daily stand-ups, sprint reviews and sprint demos are used.

Should time allow and new requirements are identified these are added to the product backlog, the product owner prioritizes requirements /user stories, and then scheduled as part of the project delivery during a sprint. Normal project change control is followed for any out of scope requirements of significant size and impact.

The project delivery itself usually incorporates 2 or 3 week sprints with a sprint demo at the end of each sprint. This allows the end users to have greater input and visibility into the solution as it is developed and improves user adoption throughout the journey of the project.

I have found this approach great for organisations that are unfamiliar with agile methodologies as it caters to the stakeholders who want more detailed schedules but also keeps future end users engaged and excited throughout the build process.

Hope this helps and good luck with your Hybrid!