I don’t even remember how long it has been since I first read Robert Sternberg’s Successful Intelligence, mainly because I’ve reread it more than a few times and it’s one of my top five recommendations. There is a lot of good in that book, but one part that really got to me is a very small section dedicated to haste and how it relates to intelligence.
The author conducted a survey asking people from around the world what they think is a sign of someone being intelligent. To his surprise, Americans replied with words like “fast”, “quick” and “speedy” 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 fast they can do their work or solve a problem, but rarely do we measure contemplation, insightfulness, or wisdom.
There are few words more apt to describe IT than “fast”. Project managers and developers write code at breakneck speed trying to get their product out the door as fast as humanly possible. It’s so ingrained in our culture that we even have concepts for the consequences of hasty development (technical debt, anyone?).
Unfortunately, that’s the nature of the beast. No one likes all-nighters and stress-inducing timelines, but developers aren’t leaders, we are chasers, we chase a market that moves way too fast and we chase technology that’s growing and changing with every minute. You either run or you get left behind.
Agile Teams: A Vaccine or a Band-Aid?
For the longest 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 issues that come with the model.
On the developer side, the waterfall requires a work benchmark structure (WBS) which means, “don’t take a step without a plan”. That can lead to long delays and what I like to call “this meeting could have been an email” syndrome where teams spend more time arguing about a change than actually implementing it.
On the client-side, waterfall is like a black-box, you give a set of instructions, get a few phone calls every couple of weeks telling you that things are coming along, and finally, when it’s time to implement, you get a product that may or may not be what you had in mind.
In both cases, rigidity is the main issue. Under this paradigm structure is important to the development process, but it can also be a straightjacket. Linear models worked back in the 70s because markets were slower back then (you literally had to travel to your client’s office with tapes or floppy disks in hand).
In contrast, the speed of the 21st century requires something different, which is why so many developers have adopted the agile team paradigm, as in, a small group of highly independent people with an ample set of skills and a skeleton framework plus an iterative development process.
Agile’s motto is “fail fast”, deploy as fast as possible, and hope that your project fails spectacularly so you can fix it. It sounds sloppy, but it’s anything but. The paradigm just assumes that A. quick deployment is a necessity of the times and B. every software will inevitably fail, but a small problem is quicker to fix than one that might go unnoticed until full deployment.
Clients are more involved in agile development, constantly testing the software, and giving feedback as they try out different builds. In a way, they are active participants of the process. That is if the client has the time to work side by side with the agile team.
Of course, agile also has its fair share of issues. Without a clear framework, you open the door to scope creep and changes to the backlog. Also, if the client doesn’t have a clear goal in mind, constant revised feedback may end up muddling 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 odds of things spiraling out of control increase until you reach a point of no return. Which is why agile teams aren’t always the best choice for a dedicated development team.
Learn more about Dedicated Teams for Software Development
Hybrid Teams, the Third Way
Aristotle, one of the greatest greek philosophers, proposed that virtue is the means between two extremes. As in, finding the right balance between two opposing forces. So is hybrid project management, a middle way between the structure of the waterfall model and the looseness of the agile model. Going back to my original argument, you can be fast as well as contemplative resulting in more “intelligent” development.
Let’s make a quick rundown of the roles:
- Hybrid teams have a project manager who also serves as a product manager. They survey the client, set up a WBS, and assign overall roles to the teams. In contrast with the waterfall method, the PM isn’t a manager in the traditional sense, decision-making doesn’t have to go through them unless it would radically change the WBS.
- Since the project manager is dealing with the frontend of the project, other team members get assigned the role of Scrum masters, leading development during sprints, they manage the backend while the project manager stays in touch with the client.
The development process goes something like this:
- Analyze: The project manager surveys the client and builds a list of requirements for the project.
- Plan: The PM gets together with the team and creates a WBS with an approximate timeline of the project. At this point the first scrum master is formally appointed.
- Design: The design phase begins and the first sprint session is planned ahead, laying down objectives and the groundwork of the development process.
- Sprint: The Scrum master takes over and the coding begins. The process usually lasts between 4 and 6 weeks as a test product is prepared for the client.
- Testing: The client tries out the product and gives feedback to the PM to bring back to the team
- Sprint: A new Scrum master may be appointed as the second sprint phase begins incorporating the feedback from the client. Keep in mind that at this stage the sprints are no longer planned ahead as was the case with the first one. Here, the team is acting as an agile team.
- Iterate: Keep going between sprint and testing until you reach the end of the project.
As you can see, the idea behind hybrid teams is to create a strong framework from the beginning while keeping a loose structure with as little bureaucracy as possible. Of course, that means that a hybrid team, much like an agile team, is at it’s best when the team members are on the same page. Fortunately, the original planning phase helps to get everyone on a common mindset.
At it’s best, a hybrid team has the underlying structure to take on big projects with the flexibility to adapt and change as the project moves along. Think of it like sailing in the old days: the WBS is the pole star, always pointing to your north. You can take any route you like or need (flexibility) as long as you don’t lose sight of your guiding star.
Are there any downsides to hybrid teams? Of course, no system is perfect. As a mesh between two paradigms you can end up facing the same challenges of each of its parent paradigms. Luckily, the method is specifically built so the issues that may arise from one side can be compensated with the strengths of the other side.
