Luke Hohmann

Luke Hohmann

Managing Small Team Web Development

April, 2001

This is a draft of a paper scheduled to appear in the July 2001 issue of the Cutter IT Journal devoted to Web Engineering. Thanks to Roger Pressman for his feedback prior to publication.

Introduction

CIOs and IT managers are faced with the challenge of building web applications in record time. Unfortunately, some of them are throwing out established software engineering practices in the process, thinking that these practices somehow unnecessarily slow down progress. A more sensible approach is to modify traditional software engineering practices so that you can meet your delivery schedule without sacrificing the quality (both architectural and as perceived by the user) of the resultant system. This article explores how the application of several (mostly) hi-touch, lo-tech project management approaches can produce excellent results for any kind of system development. These approaches and the deeper management principle upon which they are based are summarized in the following table:

Practice Principle
Small Teams Minimize wasted intra-team communication overhead
Dedicated Customer Shorten feedback loops
Standardized Technology Base Don't waste time making decisions you don't have to
Dedicated Project Room Provide the team with continuity
Lo-Fi Design Use tools that support rapid change and feedback
Sticky Note Schedules Keep the plans visible but easily changeable
Project Dashboard Keep everyone on the same page

Small Teams

The first and most important practice is to limit the size of the team to 7-10 developers. This is the number of people that a good hands-on manager can comfortably direct. The small size of the team will naturally limit the amount of work undertaken in this project (repeat the following three times: A successful first release DOES NOT need as much functionality as originally requested).

Although nearly any organizational structure is appropriate for such a small team, there are some important characteristics that must be present. One person must be given the authority to break technical decision deadlocks. This person must be experienced in the technology base. If you don't have such as person, hire a consultant.

The team must be composed of developers who inherently believe in the project and the manner in which it will be managed. It doesn't matter if the team wants to pursue more structured or less structured approaches. What does matter is that they approach these tasks in unison. A team with two opposing factions, one pursing older-style methods such as waterfall and strict code reviews while another is pushing for rapid, iterative feedback and pair programming is going to fail.

The manager must be hands-on. By "hands-on", I mean that the manager must be capable of understanding the technical details of the project and actively able to contribute to its solution. They may or may not participate in coding the solution but they must be able to participate as an equal in technical discussions. Most importantly, they must have the proven skill to organize tasks so that daily and weekly progress can be openly measured.

A best practice is to devote one person solely to technical documentation. This person manages the group's web site, records all whiteboard designs and associated technical decisions, makes certain diagrams are clear, produces technical documentation by running such tools as JavaDoc or doxygen on the source code, and so forth.

Dedicated Customer

A key element of building things fast is immediate access to someone who truly understands the problem domain. Secure either a real customer or a suitable customer proxy (such as a product marketing manager). The team must have full access to this person. The team can interrupt this person anytime they wish, which means that they must be located near the development team. An ideal location would be sitting next to the technical publications person. The team must be able to trust this person's answers. While not every answer is going to be correct, the team must assume that the answer is correct. To do otherwise will result in a costly--and slow--search for the "right" answer. Ideally, whenever a question is asked the dedicated technical documentation person is present to capture the answer.

Unfortunately, some organizations resist providing a dedicated customer to work on the project. The primary reason for such resistance is the belief that a dedicated customer is too costly. Before you fall prey to this line of thinking you should know that recent research from the Product Management Development Association (www.pdma.org) demonstrates that immediate access to customers throughout the project substantially reduces total development time and costs. These benefits are most pronounced in the early stages of new product development.

Standardized Technology Base

You can't move quickly if you try and invent all of the infrastructure that is associated with a web application. Fortunately, you don't have to. Arguably the single most important technical trend over the past few years is the emergence of high-quality, over-arching technology bases that minimize the number and complexity of technical decisions required of the development team. The two most important of these architectures are J2EE and .NET.

It is easy to become concerned that adopting one of these technology bases will result in a system that is larger or more complex than you need. This is a valid concern. I've recently been involved with a project that chose J2EE as its technology base and decided to implement nearly every highly scalable feature. Unfortunately, these choices were inappropriate and the overall project is a failure. A quick analysis of the user population revealed that we could expect loads of between 10-50 users. The system was designed to support upwards of 2,000. Instead of using simple HTML forms, the team spent six figures with a graphics design studio to create finely detailed and completely non-standard user interfaces. While the screens are chic, the time and money devoted to their construction would have been much better spent producing a simpler version of the system that made its way to customers hands more quickly.

The best way to resolve this problem is to make certain that your chief technical person is in close contact with your dedicated customer. By providing seasoned judgment on the expected profile and number of the "average user", your team can be certain that they are building a "just enough" system. By building in the technology base of J2EE or .NET you're adopting a technology base that can grow with the demonstrated needs of your system. Both J2EE and .NET provide more simple initial implementations that can start simply and be extended over time into more scalable systems as needed.

After the initial version of the system has been completed and released to customers and before the start of the next major version (or iteration) I recommend a thorough architectural review by a senior external consultant. This consultant, who should have implemented at least three systems in the technology base chosen by the team, can give the team impartial feedback on how their system adheres to the standards and preferred implementation styles associated with the technology base. A timely checkup by such a consultant can help the team make minor adjustments to improve their system before the system requires extensive repair.

Although the technology base is the single most important technical decision you will make, don't lose sight of the other tools and associated technical processes that are needed for proper and effective teamwork. I've watched web development teams fail themselves by allowing each member of the team to pick their own development environment and then run into subtle integration problems because of differences in Java virtual machines. To move fast you still need a coding standard, a reliable and well-known configuration management system, common and shared development tools, and daily integration builds with automated regression tests.

Dedicated Project Room

The team needs a dedicated project room[1] to conduct all meetings and display all project artifacts. The room should have several large whiteboards and be equipped with a high quality conference phone. It must be dedicated for the duration of the project, including its retrospective. The room should openly display any artifact that is needed by the team. Over the years I've worked in project rooms that displayed such things as:

Some people feel that this room should be locked, accessible only to the members of this project. Unless there is some compelling legal reason for this I recommend against it.

Lo-Fi Techniques

The team should be encouraged to use lo-fidelity/low-technology techniques in every phase of their work process. Simplicity, speed, and directness are the objectives, and quite often paper and pencil - and lots of sticky notes - provide everything you need. I've found that the following aspects of system development respond very well to lo-fidelity techniques.

User Interface Design

In lo-fidelity user interface design the developers take paper, pencil, and many erasers and prepares preliminary versions of the user interface. The process begins with an overall storyboard that captures the basic operational flow of the application. Following this key windows are designed in sufficient detail that they can be presented to customers. In many applications it is appropriate to expend a bit more energy and simulate the operation of these prototypes with the customer to get their direct feedback.

Lo-fidelity user interface designs have many advantages. They're fast to create and easy to change, so the development team can produce many alternatives without feeling that they have to implement the first design considered. Lo-fi designs can begin before other requirements and analysis techniques have been completed, and in fact often aid the team in more carefully defining use cases and analysis models. Finally, by adopting the approach that the team will only add data that is essential the system remains lean and focused. (A more complete description of the managerial processes associated with lo-fidelity user interfaces can be found on my web site, www.LukeHohmann.com).

Sticky Note Schedules

Pitch MS-Project for small projects. It is overkill. Instead, use Post-It notes. The process is quite easy: identify tasks whose granularity is roughly 1-2 days and write them down, one task per Post-It note. Assign each note to a developer with clearly defined milestones. Color can be used to identify similar kinds of tasks or the developer assigned to a task. Keep organizing the notes as a team until the result makes sense and then track progress daily. Try to establish a weekly or bi-weekly rhythm to the project.

To make certain the milestones are razor sharp, only accept milestones that represent a completely operational system (albeit with one or more features not fully implemented). To keep the team truly honest, make certain your dedicated customer reviews each milestone as well as each delivered system. (Consider making this a fun ritual, present at every milestone). Organizing the schedule review and creation processes in this manner creates a virtuous cycle that energizes the team during each week of the project.

Project Dashboards

Project status information can be tracked using a whiteboard organized for this purpose. To illustrate, for several years now I've used a "QA Dashboard" to provide me with status information on the final QA activities leading to a release. Elements of this dashboard include:

This dashboard, posted in a conspicuous location, provides everyone on the team, as well as anyone who happens to walk by, with a clear understanding of the status of the project. Like the other lo-fidelity techniques described above it can be managed with an absolute minimum amount of effort.

Big Printers

Although the benefits of lo-fidelity techniques are very real, many projects have to use a variety of tools to create models that help the team cope with the complexity associated with their system. ER/Win, for example, is a great tool for creating and managing database schemas. Visio is a useful for everything from creating deployment and upgrade networks to a UML diagrams.

Many of these diagrams are simply too large to fit on a standard 8.5"x11" or A4 paper. Because people find taping together small sheets of paper such a pain they simply don't do it. And because they can't see the big picture they make mistakes and sub-optimize. In the past I used to argue that architectural designs should fit on an 8.5"x11" sheet of paper. I WAS TOTALLY WRONG! Now one of the first things I do when I join a new organization is purchase one HP 1050C LARGE format printer (capable of printing diagrams 3'x150') for every physical development location. On one piece of paper you can see:

Large format printers and their associated costs (big paper) are cheap (~$10K for the printer; $50 per roll of paper). Miscommunication isn't. Large format printers pay for themselves in a few months, if not sooner. In one job the printer paid for itself on the first day it was installed when it enabled three different teams to make substantial improvements to their database schemas. For the first time the team could "see" the entire schema. Change your wallpaper, for the better.

Scaling Up

If you're managing a larger development team, you may be wondering which of these techniques apply to you. Before doing this, I urge you to consider how the project might be restructured to deliver less functionality, earlier, with a smaller team. Creating a system in any new technology environment (such as the web) is not an easy endeavor. The larger the team the more difficult it becomes to remain agile in the face of the new learning's and experiences.

If you can't find a way to begin with a smaller team, see if you can structure the work so that smaller teams can effectively tackle self-contained "subsystems" associated with the overall project. If you attempt this structure make certain that you have defined a process for integrating the work products of these smaller teams. This process should accommodate the larger team coming together on at least a quarterly basis to share progress and maintain alignment to common objectives. Teams organized as subsystems also need substantially more care in managing the communication overhead naturally inherent in larger numbers of people. In addition to a dedicated project room, you'll need subsystem centric email lists, dedicated intranet sites that facilitate collaboration, and more formal end-game processes regarding QA. Attacking the communication issues associated with larger teams is arguably the single most important task facing the project manager.

Some big projects can't be structured in terms of independent smaller teams. For example, I once consulted on a 250+ person embedded missile project. Although the individual groups were as small as possible, the overall work could not be tackled as "self-contained" subsystems. If this is your situation I do not recommend the lo-fidelity, lightweight project management and communication structures proposed in this article. Larger teams require more formality with respect to communication structures, more rigidity in the number and kinds of checks and balances, more extensive project and program management infrastructures, and so forth. There is a limit to "lightweight" approaches to project development. Going past this limit will result in certain failure.


[1] This kind of room is sometimes referred to as a "war room", a term I find objectionable: You're building a software system, not going to war.

© 2007 Luke Hohmann