Why do you need to scale?
Well, that's an obvious question. You can't do everything yourself. Even if you're one of those "can't let it go, so got to do it myself" developers, then still you might have colleagues that actually want to do some work on that cool product you're working on or use that cool technology you've introduced. However hard this can be in the beginning (and trust me, I've been there), you should start to let go and trust other developers with your code. Eventually this will pay off.
Besides letting go, what's the issue?
A simplistic approach to managing a team that needs to produce something faster, is to just throw in a couple more people. It doesn't work that way. Especially when you're doing new things and/or working on a large code base, you can't just expect a developer to walk in and start working on it.
If a new technology is involved the new developer needs to get familiar with what that technology is all about. Changes are some new tools need to be installed, some tutorials need to be followed to get a feel for the technology and then can they start and look at how this technology was applied in this particular project.
Also, if there is already a fairly large code base, then there are most likely a lot of concepts and principles that are being used in the design. A developer that has actually worked on this code from the start has gradually encountered them over time, but a developer just getting started on this code, will need to take time to get to grips with all the thought that has gone into it. For that he or she also needs someone to go over these concepts and explain how they work.
One thing I'd like to point out to the developer that gets assigned to an existing project that is on a tight schedule, stop asking "why didn't you use A instead of B?". It's irrelevant. A choice was made, most likely with a good reason and even if A was better then B, there is no time to change it. So if you're assigned to a project in progress, stop asking "why" and only ask "how".
Communication
Another issue, which is actually documented very well, is team communication. As soon as you add a person to a project, there has to be communication between the existing members and that new team member, in order to coordinate the work. That communication takes time as well. So if you're adding a person to a team, that person will spend some of it's day in communication with others and some team members will have to spend some of their day's in communication with the new team member. It really adds up as you add more team members.
One thing to do to reduce this effect is to prevent a model where everyone is communicating with every other team member. To reduce the effect, there should be someone overseeing the entire project who coordinates the team in such a way that they only need communication with either the coordinator or with a team member or two that work on adjacent parts of the project. This way you take out a lot of the pain already.
Another possibly powerful tool (if used correctly) is a stand up meeting. A concept introduced by Extreme Programming, it means you take about 5 to 15 minutes a day (depending on team size) to meat with everyone at the same time, to discuss any issues that may have occurred in the past day. This way action can be taken right away. The right people can be put together to take care of the issue.
General rules on scale
Some general tips on scaling a project:
- Don't scale to early. If a project is still half in it's design stage or is still being innovated on a lot, then wait.
- Don't scale to quickly. Once design is done and the innovation is starting to slow down, don't just through in five developers at the same time. Adding them one by one makes much more sense.
- Balance the team members. Don't just throw in all the best developers you have and think it'll work out fine. On most projects you need some people that are great at designing software and you also need developers that are going to write bulk amounts of code.
- Make sure early team members can work full time on the project. There is nothing less efficient than having to keep switching between projects, even if it's only for a question or for rework. Take the amount of time it takes to do something on an old project and multiply it by three. That's the time lost by switching.
- Don't scale up close to a deadline. What's close to a deadline depends on the projects scale. Because of the effort it takes, scaling up to close to a deadline will cause the project to go late, no matter what.
Posts
No comments:
Post a Comment