Hybrid Project Management: The Best of Agile and Traditional Methods

Few words are more fitting for IT than "fast." Project managers and developers write code at breakneck speed, trying to get their product out as quickly as possible. This is so ingrained in our culture that we even have notions about the consequences of rushed development.

Unfortunately, that's the nature of the beast. Nobody likes night shifts and tight deadlines, but developers are not leaders—they are followers, chasing a market that moves too fast and technologies that grow and change by the minute. You either run or get left behind.

Agile Teams: Vaccine or Band-Aid?

For a long time, development followed traditional methods, specifically the waterfall model. We all know its stages by heart: Requirements, Design, Implementation, Verification, Maintenance. And we are also well aware of the risks and issues associated with this model.

From the developer's side, waterfall requires a reference Work Breakdown Structure (WBS), which means "don't take a step without a plan." This can lead to long delays and a syndrome I call "this meeting could have been an email," where teams spend more time arguing about changes than actually implementing them.

From the client's side, waterfall is like a "black box": you give a set of instructions, get a few phone calls every couple of weeks telling you everything is on track, and finally, when deployment time comes, you get a product that may be nothing like what you envisioned.

In both cases, the core issue is rigidity. Within this paradigm, structure is important for the development process, but it can also constrain it. Linear models worked in the 1970s because markets were slower back then (you literally had to drive to the client's office with tapes or floppy disks in hand).

The speed of the 21st century, on the other hand, demands something different, which is why many developers have shifted to the agile team paradigm—a small group of highly independent people with a sufficient skill set and a skeletal structure, plus an iterative development process.

Agile's motto is "fail fast"—deploy as quickly as possible and hope your project fails spectacularly so you can fix it. It sounds sloppy, but it's not. The paradigm simply assumes that A. rapid deployment is a necessity of the times, and B. any software will inevitably break, but a small problem is faster to fix than one that might go unnoticed until full deployment.

Clients are more actively involved in agile development, continuously testing the software and providing feedback as they try different builds. In a sense, they are active participants. This works if the client has time to work side by side with the agile team.

Of course, agile has its own issues. Without clear boundaries, scope creep and backlog changes become possible. Also, if the client lacks a clear goal, constant re-evaluation of feedback can muddy the project.

And perhaps most importantly: agile does not scale well—it's chaos theory at its finest. It works great when there are few variables, but as the project grows, the likelihood of things spiraling out of control increases until a point of no return is reached. That is why agile teams are not always the best choice for a specialized development team.

Hybrid Teams: The Third Way

Aristotle, one of the greatest Greek philosophers, believed that virtue is the mean between two extremes—finding the right balance between opposing forces. Similarly, hybrid project management is the middle path between the structure of the waterfall model and the freedom of the agile model. To return to my initial argument: you can be both fast and thoughtful, leading to "smarter" development.

Let's briefly review the roles:

• In hybrid teams, there is a project manager who also acts as a product manager. They interview the client, create the WBS, and assign general roles to teams. Unlike the waterfall method, the project manager is not a manager in the traditional sense; decisions should not have to go through them unless it leads to a radical change in the WBS.
• Since the project manager handles the front end of the project, other team members take on the role of Scrum Masters, who guide development during sprints and manage the back end, while the project manager stays in touch with the client.

The development process goes roughly like this:

1. Analysis: The project manager interviews the client and compiles a list of project requirements.
2. Plan: The PM meets with the team and creates a WBS with a rough project timeline. At this stage, the first Scrum Master is officially appointed.
3. Design: The design phase begins, during which the first sprint session is planned, along with goals and the foundation of the development process.
4. Sprint: The Scrum Master takes over and starts coding. This process typically lasts 4 to 6 weeks, during which a testable product is prepared for the client.
5. Testing: The client tries the product and provides feedback to the manager, who relays it to the team.
6. Sprint: A new Scrum Master may be appointed as the second sprint phase begins, incorporating client feedback. Note that at this stage, sprints are no longer planned in advance like the first one. Here, the team operates like an agile team.
7. Iteration: Continue moving from sprint to testing until you reach the end of the project.

As you can see, the idea behind hybrid teams is to build a solid foundation from the start while maintaining a flexible structure with minimal bureaucracy. Of course, this means that a hybrid team, like an agile team, works best when members are on the same page. Fortunately, the initial planning phase helps align everyone's thinking.

At its best, a hybrid team has the basic structure to take on large projects and the flexibility to adapt and change course. Think of it like the good old days of sailing: the WBS is the North Star, always pointing north. You can take any route you like or need (flexibility), as long as you keep your guiding star in sight.

Are there downsides to hybrid teams? Of course, no system is perfect. As a bridge between two paradigms, you may encounter the same issues as each parent paradigm. Fortunately, the method is specifically designed so that problems one side might have are compensated by the strengths of the other.