In the past few year the world has become more and more agile.
There’s no shortage of people who swear by agile methodologies, particularly in the IT management world. It’s vibrant, flexible, it’s fast paced and recognizes change as the only constant in this world. It values human interaction over tiresome contracts, and software that works over brain dulling documentation. It is in line with the modern philosophy of fail fast, fail better, as it immensely reduces time to market when compared to the waterfall approach.
On the other hand, if waterfall had a mantra, it might be something along the lines: shortcuts create long delays (as wisely put by Pippin in The Fellowship of the Ring). Waterfall enforces rigid planning and a well defined work breakdown structure (WBS).
Agile – Fail fast, fail better
Waterfall – Shortcuts create long delays
The more traditional approach to project management suggests taking a series of well thought out steps and defining hard milestones in order to eventually deliver a complete project that satisfies all set requirements.
Which is perfect if you are building a nuclear waste disposal system! You’d better have every feature working bug-free before you deploy it.
But what if you have a project that is somewhat loosely defined? What if your customer is not quite sure what they want?
The problem of waterfall is that the today’s market is quite dynamic, and the input from the customers and user acceptance testing come at the very end of the process. And maybe then you find out that this is not exactly what the users want after all but you’ve already spent too much time and resources.
Okay, great, go agile and iterate like there’s no tomorrow?
Yes, well, agile comes with its set of weak spots too. Since it allows its backlog to change, without robust documentation and control, it is susceptible to scope creep, and some say constant additions of features actually degrade user experience. And perhaps most importantly, agile doesn’t scale so well. It shines brightest in smaller projects, but big projects and large teams are better off with a more systematic approach [1].
The definition of Hybrid Methodology
There have been some major factors that contributed to the rising popularity of Hybrid:
- Uncertainty and complexity – PMI’s 2018 Pulse of the Profession survey notes that the percentage of projects with high complexity is on the rise. It’s risen from 35% in 2013 to 41% in 2018.
- Competitive markets – In today’s market you need to anticipate competitive issues and influences to ensure you always have a proactive plan and strategy in order to stay ahead of the game.
- High client expectations – Personalization, ease and speed are what most clients have come to expect, even with large scale projects. Not being able to make changes in a years time is no longer seen as realistic. The client’s needs are evolving, a the projects need to follow.
The solution? Waterfall Agile Hybrid!
Some call it hybrid agile or structured agile, or just simply hybrid.
This is a relatively new methodology that combines a short focus on each product feature with a long focus on the end result.
The hybrid manifesto defines the method as following:
Hybrid Project Management combines the formal and Agile methods to create a new project management method. Hybrid employs the thoroughness of Work Breakdown Structure (WBS) with speed and lean benefits of Agile for a new project management method which is both detailed and fast.
So how does it work? Where is the merging point?
Here are the three basic principles that should get you started:
- it can be compatible with any industry and team of any size
- blending happens at the beginning of the project
- responsibility needs to be clearly defined
Blending happens at the start of the project
In the initial stage of the project, a hybrid team sits down and spends an ample amount of time on analyzing the project’s life cycle and its complexity to come up with a work breakdown plan, chunking the work top down into phases and sub-phases in form of a tree-like structure. But rather than precisely defining each task, they make space for some flexibility. Each phase gets its backlog, but only the first one is firmly defined.
The phases can run in sequence or in parallel, provided there are no dependencies. Waterfall has earned its name due to processes following each other in a cascade. In contrast, hybrid allows overlapping phases, without procedurally having to wait for the previous one to finish. If a task can start, it should start.
The phases are then split into several sprints. The outcome of each sprint modifies the input to the following sprint, as the team has gained new knowledge and the product owner has made some changes in the requirements, so the next sprint gets readjusted. And if everything went according to the initial plan, then the next phase is ready to go as it was already outlined at the start. This way the team understands the goals of each phase before starting it, but can adjust the plans at the end of each sprint.
The hybrid sprints commonly last between 4 and 6 weeks. Thus every 4 to 6 weeks adjustments or termination can be done if circumstances demand so, before too much time and resources have been spent.
But hybrid has to have cons too, right?
Well, depends how you look at it.
In a way not really, because hybrid aims to shift the perception of making a choice of methodology from “pick one from the set” to “find your special place under the sun on the scale from waterfall to agile”. It proposes you optimize the agile-waterfall ratio to best suit your needs, and if you are working on, say, a two month software project, then, well, zero waterfall it is.
Hybrid is all about compromise.
For someone who comes from waterfall environments, the downside may be that you’ll have to give up a level of certainty in exchange for agile’s flexibility, and inversely, someone who comes from pure agile might think it a downside that you’ll be required to have your freedom a little limited in order to reap some benefits from waterfall’s budget and schedule planning.
In structured agile, communication is even more crucial than in other approaches, as it requires project managers and scrum masters to join forces in a common endeavor.
Who manages the team?
Overall project responsibility is given to a Project Manager using WBS methodology whereas the sprints are run by Scrum Masters. The PM also assumes the role of the product manager, and is considered the business owner of the project. He or she is mainly concerned with the front end of the project flow, including requirements, customer feedback, components definition and WBS, while Scrum Masters have a hold on the back end, managing backlogs, sprints and releases. The project manager gathers the scrum masters, who in return form their own teams.
There is no need for a formal project management office (PMO), as this would add a layer of bureaucracy and possibly delays and expenses. And if there is one, the role of the office changes quite a bit.
Needless to say, the whole team needs to collaborate continuously with ongoing reporting, analysis and reviews.
Who can use the hybrid framework?
Hybrid is compatible with all industries and teams of all sizes, although for very small projects agile is still the recommended way to go. As projects grow in size and duration, they will benefit more from adopting structured agile.
This approach has gained some momentum recently, as it appeals to larger enterprises and those looking to transition to agile, but fear such cut would be too sharp. It is not unreasonable to fear that transferring a project from one management framework to its opposite could be detrimental to the project’s success, especially if the team has worked long years accustomed to standard methodology. But switching to hybrid should allow for a smoother cultural shift.
Lauri Bingham, Director of Technology PMO at T-Mobile, responsible for managing over $100M across a diverse, high-profile portfolio of national programs and projects says that over a third of her projects are run on hybrid.
Xplace, a freelancer hosting startup, gathering people across three continents, report 25% saved on product delivery time and 18% less bugs after switching from waterfall to hybrid, as it allowed them to better pinpoint the critical development path and still complete tasks in sprints.
A number of banks employ this blended approach too.
Hybrid works well for reusing software code in several similar endeavors, while having to take into account the quality of future products. This provides the flexibility and speed of delivering while staying abreast of the final product quality level.
With agile originating from software development and waterfall coming from the manufacturing world, in a project that involves both software and hardware development, they are often employed so that they cover their respective fields.
After all, hybrid is not exactly prescriptive, but sort of covers a spectrum. One can add a bit of agile into waterfall to taste, or a bit of waterfall into the agile soup, and these relative contributions may vary. For each project, we should analyze what makes sense for that specific situation, perhaps not trying to label that management approach and fit it into some prescribed frames.
It’s easy to get pressured by the popularity of agile approaches (with Scrum and Kanban at the head), but be aware that there are alternatives that might actually work better for you.
The flavors of hybrid: Wagile and Agifall
People have come up with the Wagile and Agifall portmanteaus to signify whether the approach leans more towards waterfall or agile.
Agifall introduces more robust stages of research, strategy and planning phases into tasks and proceeds with sprints to complete them. So it’s basically an agile project with more information up front.
Interestingly, the term Wagile has a negative connotation. It implies that some agile practices have been adopted but the project has been slipping back into waterfall. Such badly managed agile can transform eight 2-week sprints into a series of eight time boxed waterfalls. Basically, wagile is thought of as waterfall masquerading as agile through daily standups and short iterations, but without principally stepping away from the traditional model.
What skills do I need to be a hybrid agile manager?
Out of all those traits that characterize a good project manager in general, working with hybrid framework puts an emphasis on the following:
- A broad range of knowledge covering traditional management as well as agile methodologies and the ability to leverage the two: be good at defining project scope and schedule while focusing on frequent and timely delivery of value.
- The ability to take on the product owner role and manage customer expectations for project deliverables.
- Exceptional communication skills to cooperate with members of the diverse team and make sure they are fully engaged in a meaningful task. Since hybrid approach is more likely to be adopted by large companies, the chances are the team is going to contain a lot of people with rather diverse backgrounds and skill sets.
- Writing skills to report and document progress.
- Analytical, planning and organizational skills with the right blend of flexibility and adherence to plans.
What software can I use for hybrid project management?
Binfire was designed from the start to be used as a tool for managing projects using the hybrid method. They claim their task manager provides all you need to combine Kanban and waterfall, and that the learning curve for those who used either is very short.
Another option is codeBeamer ALM by Intland Software, or ProjectManager.com that also support both agile and waterfall processes.
Although primarily providing tools for agile management, Atlassian also offers support for hybrid methodology through onepoint PROJECTS. It integrates formal, agile and JIRA projects into a single project portfolio and resource utilization database.
With many of it’s recent improvement Teodesk has become the leading software when it comes to the implementation of hybrid methodology. It’s flexible, yet structured enough to be a perfect fit. All our work to fully understan this methodology were recognized at the 2019 edditon of the PMI Summit held in Sofia, Bulgari where we held the first lecture on the subject.
The more fluent you are in various project management “languages”, the easier it will be for you to adapt to any project/portfolio management tools.
Happy blending!
References
[1] McConnell, S. (1998). Software Project Survival Guide: How to be sure your first important project isn’t your last. USA: Microsoft Press.
