Over the past few years, companies have been changing their approach to management from classic to agile. Many of them are finally using a blend of the two, called the hybrid approach. What are the main features and differences of these approaches? Let’s find out.
How to do it “the olden ways”?
In the contemporary product portfolio management world, it’s possible to pinpoint two eras: before and after the publication of the Agile Manifesto.
The pre-Agile Manifesto era featured the use of the classic or waterfall approach. It arranges workflow in an understandable, straightforward, but non-flexible way. Work goes step by step, without much room for improvisation or adapting to sudden changes. It looks, more or less, like this:
Waterfall, or it’s hard to swim upstream
As you can see, the classic methodology is easy to understand, use and implement. Each step is visibly detached from others, which means no diffusion between specific chunks of work. This prevents errors caused by the fluidity of work and forces managers and their teams to be sure that each step is executed flawlessly.
This, in turn, leads to the main flaw of the waterfall approach. It leaves no room for sudden changes, pivots, or errors on any of the steps involved, meaning that potential hiccups on early chapters can mount with each step, possibly threatening the success of the whole operation.
This approach relies heavily on proper documentation – producing a massive amount of files and reports is essential to understand what was done in a specific step and guides users to another chapter. Everything is described, but it requires managers to delegate part of their employees to focus solely on documentation instead of bringing value to the deliverables.
Classic approaches are easy to follow but rigid and stiff. When the projects get bigger and more complicated, some recommend using waterfall methods solely for relatively simple initiatives, with clear and fixed goals, and extended documentation.
Agile, or going through changes
Exactly 20 years ago, a new type of approach emerged. A group of representatives of different software backgrounds spent a weekend in the Snowbird ski resort. It wasn’t a typical holiday, as they debated about how to get things done better, with fewer resources and in a more flexible way. That’s how Agile was officially born. Its principles were written in the manifesto which states the following:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
As seen, classic and Agile approaches are like day and night – when one isn’t change-welcoming, the other embraces it. Classic relies on documentation; Agile prefers focusing on the value brought to the customers and working with them rather than meticulous reporting. It relies on iterations, constant testing, fluid barriers between each project stage, and responding in real-time to potential errors. The keyword is “increment,” and teams are focused on creating a product that can be continuously presented and delivered to the customer.
Ready for something new?
Sounds lovely, doesn’t it? It certainly does, but the agile approach is also demanding. It relies on the cooperation of many people and departments, requires quick feedback, and constant resource juggling to satisfy every sudden need or solve a problem. Nonetheless, it’s getting more and more popular within across industries and organizations. A flexible approach is tempting, and it’s more failure-proof. According to the 2011 CHAOS Manifesto from the Standish Group, agile initiatives have a success rate three times higher than classic ones. Too good to be true, right?
One might think that this binary choice is all. Yet, there is a third way that connects these entirely different approaches and for many organizations turns out to be the go-to option. Most mature organizations operating at scale neither can nor want to apply agile in all of their functional areas. That’s because agile is not a silver bullet. It works great in product development teams, in R&D etc., but in teams such as, say, Customer Support, would most likely bring chaos. That’s where the hybrid approach steps in.
Hybrid, or how to choose the best from both worlds
Most organizations do not rely on a “pure classic” or “pure Agile” approach. Usually, because it’s challenging to shift the whole company from one methodology to another, the interested parties start to look for a compromise. Its result is a hybrid approach. As explained in the Hybrid project management manifesto:
“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 the speed and lean benefits of Agile for a new project management method that is both detailed and fast. Most projects benefit from using the Hybrid project management method. Only very small projects don’t require a hybrid method”.
Teams gather requirements and analyze them. They divide work into phases, just like in classic methodologies, but these phases can be iterated internally, like in the Agile approach, and effects can be presented to clients, providing instant feedback. Effectively, the chaotic, ad hoc workflow is tamed by each chapter’s structures and initial planning. Most importantly, the purity of the approach is not the primary concern, but creating the functionality as fast as possible.
Don’t get too radical
The hybrid approach is highly compatible and can be adopted by many different industries and teams. Its nature lies in compromise and the possibility to smoothen the cultural shift in companies that want to rely more on agile methodologies instead of classic ones. Their number is still growing.
At BigPicture, we believe that the hybrid approach is the most proper approach. For us, the agile transformation isn’t a full transition from a pure waterfall approach to a pure agile approach. It’s more about getting to the degree of agility that works best for a particular organization. Purity can never outshine pragmaticism.
That’s why it’s worth noting that many companies will never entirely resign from classic methodologies, primarily because of planning, budgeting, and contract-demanded deadlines. The need for a hybrid approach will never expire, and BigPicture meets up that need.
BigPicture – a transition tool and more
BigPicture is a proper tool for every company that wants to plan and supervise their projects before, during, and after Agile transformation. Here are the key reasons why it’s so helpful:
- It integrates with tools that teams love, like Jira and Trello, meaning there is no need to change their work drastically.
- BigPicture facilitates roadmapping, capacity allocation planning, dependencies, and risk identifications with a handful of reporting capabilities regardless of the approach used: Agile, hybrid, and classic.
- Allows managers to supervise and plan work, no matter the chosen approach.
- Presents the helicopter view on one screen and from the perspective of both Project and Portfolio Manager.
- It is an umbrella app – allows to oversee different approaches within configurable templates adjusted to the framework used and lets managers build and manage diversified portfolios of initiatives.
- Allows to both see the big picture and more minor details.
