Team
Tweet
I’ve had some pretty terrible group projects in school. Teammates are stressed and busy, few people feel committed to the group, and drama is always present. There are a lot of elements that go into making a good team, and a lot of things that could go wrong. This post will talk about teamwork in the context of web projects, and provide a few of the tools that are used as complications arise.
In a perfect world
When we think of a perfect web development team, there are a few key elements that appear universally:
- Talented team members
- A small team
- Lots of communication
- Full-time dedication
In the ideal world, the designer, architect and one or two developers work closely with the client to create a great website or web app. The project runs smoothly and does not need much process structure, since the team members are talented and motivated to do their best on the project.
Any project manager will look at this list and chuckle to himself or herself. It is incredibly rare that all of the planets align and projects have all of these elements. Usually at least one of these ideals is missing, and sometimes, none of these elements exist in a project.
Complication #1 - Limited Time
Time is a very limited resource, as this semester’s course load has continues to remind me. I have a lot of plates spinning at once, from personal projects to class and work on top of it. Multiply that by every member of the team, who also have families and home improvements, and divide the remaining time across the six or seven websites that are being built at any given time, and you begin to realize the difficult constraints agencies have to work under.
A consistent traffic system can help with making time more effective when it’s available. Expectations and estimations of time need to be communicated clearly in order to guard against losing precious time. At LaneTerralever, we have an internal resource trafficking system for project managers to vie for time and block out a developer’s schedule so that he or she can just focus on one task.
Personally, I find the major time constraints to be very difficult to deal with, but lately there have been a few tools that I’ve used to better utilize my time. The first is pen and paper, with the creation of quick to-do lists that help prioritize my schedule and focus on doing rather than remembering. If you’re not a paper fan, I also use Google tasks, Evernote reminders, and GitHub checklists.
Complication #2 - A Larger Team
In order to cope with this limited availability of core members, the core team usually needs to grow. That is where the second problem arises.
The phrase “Too many cooks in the kitchen” comes to mind when thinking of over-staffed web projects. I’ve worked in a dining hall, and have seen things turn to hysteria when too many people try to work in the kitchen. There is miscommunication, dishes are prepared in the wrong order, and the lead chef is too busy to check every dish that goes out, or even do any cooking of his or her own.
If not carefully monitored, web development teams can definitely grow out of control like a busy kitchen. Code conflicts occur, more than one person work on the same bug, and some developers sit on their hands while the lead developers run around trying to remove the blocks for them.
As the size grows, communication is key, and I use a number of tools daily when communicating with team members. Besides general GitHub comments, I’ve also used gitter for chatting around GitHub projects. At work, my friend Dennis and I use Skype chat, mostly due to animated emoticons. I’ve also enjoyed using Slack and HipChat for class projects, but don’t know how effective they are at scale.
Complication #3 - Bug Slips
When your development team begins to get very large, there is a high propensity for bugs to appear in the code, and unless the team is writing very thorough self-tests, some outside quality assurance will probably be needed.
At LaneTerralever, we have a large and highly competent quality assurance team, with a well documented process for performing aesthetic and functional tests on every thing we show to a client. The process is in place to catch bugs quickly and get them fixed before any code is shown to a client.
At scale, it becomes a difficult problem to test every project efficiently and intelligently. Bugs could be logged twice, or fixes for one bug may have uncaught consequences on another feature. In order to keep things organized across the team, we use a tool called TargetProcess for managing project bugs, but I’ve heard a lot of people use Basecamp for project management and enjoy it a lot.
Bonus: Complication #4 - Integrating Teams
When there are a lot of moving parts in a single team, from QA to designers, and from database developers to user interface developers, there have to be good checks and balances to ensure that each team member has clearly defined responsibilities and knows how to work with each other. We have specific requirements on the mock-ups that user experience architects hand over to designers, who then hand over well-defined PSD’s to the development team. The quality assurance team double checks these intermediate deliverables to make sure those hand-offs work as expected.
Right now we’re trying to figure out a more clearly-defined relationship between back-end developers and front-end developers. A major complication at times can be front-end developers creating presentation code from a design that is not prepared to handle the requirements that back-end developers have for easily integrating the presentation with the server-side data. It will be an interesting problem, and I’m sure I will be writing more about it in the future.
What kind of systems do you have in place to handle scaling teams from small dedicated groups to distributed busy individuals? What is your ideal development team? Let me know on Twitter, write a comment below, or shoot me a Facebook message!
Tweet