Combining the best of agile and traditional methods, hybrid project management is a new trend that balances structure with flexibility
I can't even remember how long it's been since I first read Robert Sternberg's book Successful Intelligence , mainly because I've reread it more than a few times and it's one of my top five recommendations. There are a lot of good things in this book, but one part that really impressed me is a very small section dedicated to haste and how it relates to intelligence.
The author conducted a survey asking people around the world what they think is a sign that someone is intelligent. To their surprise, Americans responded with words like “quick,” “quick,” and “swift,” while Europeans opted for words like “contemplative,” “insightful,” or “creative.” He goes on to argue that in life we tend to test people on how quickly they can do their job or solve a problem, but we rarely measure contemplation, insight, or wisdom.
There are few words better suited to describe IT than “fast”. Project managers and developers write code at breakneck speed, trying to release their products as quickly as possible. It's so ingrained in our culture that we even have concepts for the consequences of hasty development (technical debt, anyone?).
Unfortunately, that is the nature of the beast. Nobody liked all-nighters and stress-inducing schedules , but developers are not leaders, we are hunters, we chase a market that moves very fast and we chase technologies that grow and change by the minute. Either you run or you stay behind.
Agile teams: a vaccine or a band-aid?
For a long time, development followed the trend of traditional methods, more specifically, the waterfall model. We all know the steps by heart: Requirements, Design, Implement, Verify, Maintain . And we are also well aware of the risks and problems that come with the model.
On the developer side, waterfall requires a work benchmark framework (WBS), which means “don't take a step without a plan”. This can lead to long delays and what I like to call “this meeting could have been an email syndrome” where teams spend more time discussing a change than actually implementing it.
On the customer side, waterfall is like a black box: you give a set of instructions, you get a few phone calls every couple of weeks letting you know things are happening, and finally, when it's time to implement, you get a product that can or not be what you had in mind.
In both cases, stiffness is the main problem. Under this paradigm, structure is important to the development process, but it can also be a straitjacket. Linear models worked in the 70s because markets were slower back then (you literally had to travel to the client's office with tapes or floppy disks in hand).
In contrast, the speed of the 21st century demands something different, which is why so many developers have adopted the agile team paradigm, as a small group of highly independent people with a broad skill set and a basic structure, as well as iterative development. . process.
The motto of Agile is “fail fast”, deploy as quickly as possible, and hope your project fails spectacularly so you can fix it. It looks sloppy, but it's anything but. The paradigm just assumes that A. rapid deployment is the need of the times and B. all software will inevitably fail, but a small problem is faster to resolve than one that can go unnoticed until full deployment.
Customers are more involved in agile development, constantly testing software and giving feedback as they try different builds. In a way, they are active participants in the process. That is if the client has time to work side by side with the agile team.
Of course, agile also has its fair share of problems. Without a clear structure, you open the door to scope creep and backlog changes. Additionally, if the client doesn't have a clear goal in mind, constant, revised feedback can end up derailing the project.
Perhaps most importantly, agile isn’t good at scaling – it’s chaos theory at its best. It works perfectly when there are few variables, but as the project increases in size, the chances of things getting out of control increase until reaching a point of no return. This is why agile teams are not always the best choice for a dedicated development team.
Learn more about Dedicated Teams for Software Development
Contact us
Hybrid Teams, the Third Way
Aristotle, one of the greatest Greek philosophers, proposed that virtue is the mean between two extremes. How to find the right balance between two opposing forces. The same is true with hybrid project management, a compromise between the structure of the waterfall model and the looseness of the agile model. Returning to my original argument, you can be quick and also contemplative, resulting in more “smart” development.
Let's do a quick summary of the functions:
- Hybrid teams have a project manager who also acts as a product manager. They research the customer, set up a WBS, and assign general roles to teams. In contrast to the waterfall method, the PM is not a manager in the traditional sense, decision making does not need to go through them unless doing so radically changes the WBS.
- As the project manager is handling the front-end of the project, other team members are assigned the role of Scrum Masters leading development during sprints, they manage the back-end while the project manager remains in contact with the customer.
The development process goes something like this:
- Analyze: The project manager researches the customer and creates a list of requirements for the project.
- Plan: The PM meets with the team and creates a WBS with an approximate project timeline. At this point, the first scrum master is formally appointed.
- Design: The design phase begins and the first session of the sprint is planned in advance, establishing the objectives and foundations of the development process.
- Race: The Scrum master takes over and coding begins. The process typically lasts between 4 and 6 weeks while a test product is prepared for the customer.
- Testing: The customer tries the product and gives feedback to the PM to bring back to the team
- Sprint: A new Scrum master can be appointed when the second phase of the sprint begins, incorporating customer feedback. Keep in mind that at this stage sprints are no longer planned in advance as was the case with the first one. Here, the team acts as an agile team.
- Iterate: Continue between sprint and test until you reach the end of the project.
As you can see, the idea behind hybrid teams is to create a strong structure from the beginning, while maintaining a flexible structure and with as little bureaucracy as possible. Of course, this means that a hybrid team, like an agile team, works best when team members are on the same page. Fortunately, the original planning phase helps get everyone into a common mindset.
At best, a hybrid team has the underlying structure to take on large projects with the flexibility to adapt and change as the project progresses. Think of it like sailing in the old days: the WBS is the north star, always pointing to your north. You can follow whatever path you want or need (flexibility), as long as you don't lose sight of your guiding star.
Are there disadvantages to hybrid teams? Of course, no system is perfect. As a mesh between two paradigms, you may end up facing the same challenges as each of the parent paradigms. Fortunately, the method is specifically constructed so that problems that may arise on one side can be offset by the strengths of the other side.
Source: BairesDev
