This is the thirteenth article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the thirteenth chapter.
What if you have lots of little projects to get done? How should you allocate those projects to the programmers? What if you have one really huge project to get done?
Does it blend?
It makes no sense to tell a programmer to devote half of their time to project A and the rest of their time to project B, especially when the two projects have two different managers, different business analysts, different programmers, and different testers. How in Hell's kitchen can you call a monstrosity like that a team? That's not a team, that's something that came out of a Waring blender.
The Gelled Team
It takes time for a team to form. The team members start to form relationships. They learn how to collaborate with each other. They learn each other's quirks, strengths, and weaknesses. Eventually, the team begins to gel.
There's something truly magical about a gelled team. They can work miracles. They anticipate each other, cover for each other, support each other, and demand the best from each other. They make things happen. The team should be composed of programmers, testers, and analysts. And it should have a project manager.
Fermentation
It takes time for a team like this to work out their differences, come to terms with each other, and really gel. A gelled team will plan together, solve problems together, face issues together, and get things done.
Once this happens, it is ludicrous to break it apart just because a project comes to an end. It's best to keep that team together and just keep feeding it projects.
Which came first, the team or the project?
Banks and insurance companies tried to form teams around projects. This is a foolish approach. The teams simply cannot gel. The individuals are only on the project for a short time, and only for a percentage of their time, and therefore never learn how to deal with each other.
Professional development organizations allocate projects to existing gelled teams, they don't form teams around projects. A gelled team can accept many projects simultaneously and will divvy up the work according to their own opinions, skills, and abilities. The gelled team will get the projects done.
But how to manage that?
Teams have velocities. Velocity is the amount of work it can get done in a fixed period of time. Some teams measure their velocity in points per week, where points are a unit of complexity. They break down the features of each project they are working on and estimate them in points. Then they measure how many points they get done per week.
Velocity is a statistical measure. Over time this will average out. Management can set targets for each project given to a team. Aside from having a gelled team working on your projects, the advantage of the scheme is that in an emergency the business can say, "Project B is in crisis; put 100% of your effort on that project for the next three months".
The Project Owner dilemma
One of the objections to the approach I'm advocating is that the project owners lose some security and power. If projects are given to gelled teams, and if those teams take on several projects at the same time, then the business is free to change priorities on a whim. This can make the project owner insecure about the future. The resources that project owner is depending on might be suddenly removed from him.
Conclusion
Teams are harder to build than projects. Therefore, it is better to form persistent teams that move together from one project to the next and can take on more than one project at a time. The goal in forming a team is to give that team enough time to gel and then keep it together as an engine for getting many projects done.
Top comments (0)