Ideal Developer Ratios for Pods

In the last post, I postulated that an ideal team structure exists for Agile, a pod. The pod is a collocated, self-contained team able to execute the project. Let's drill down into the structure of this "ideal" Agile team a bit more, focusing on the programming skills the pod should have. These observations specifically apply to a pod using OO programming techniques (see the secret assumption of Agile) to write code that is easily modified. It is a language independent assumption, whether using Java, C++, C#, Ruby, or any of their brethren.

I will describe the team composition using the skills taxonomy I introduced earlier, the Master-Journeyman-Apprentice model. Briefly, an apprentice is the typically trained programmer; the journeyman has acquired the vocabulary of objects, including principles and design patterns; the master readily crafts object solutions to business problems.

The first rule of thumb for the team is that apprentices when paired together are not productive. Indeed, such a pair can be negatively productive, developing code that must be re-opened and reworked before delivery. (Of course, you do pair within the pod; a solo apprentice is truly a destructive force in the code base.)

So the guideline against apprentices pairing together leads to the first rule of an agile team:

Masters + Journeymen >= Apprentices

Simply put, the number of Masters and Journeymen needs to outnumber the Apprentices so that the Apprentices have a more experienced person with which to pair. That keeps everyone on the team productive. It also provides the mentoring to move the Apprentice to a Journeyman (see Building a Better Programmer). With care, the Apprentices gradually become Journeymen, providing more pairing options or the ability to absorb additional Apprentices.Master programmers provide continuous architectural and design direction to a project. They recognize the need for new components to support emerging stories, and pioneer these new components themselves to ensure a sound base exists for the rest of the team. How many Master programmers do you need? Fortunately, not that many:

Masters >= 10% (Masters + Journeymen + Apprentices)

In my experience, you can get away with as few as 10% of your developers as Master programmers; it is safer if you can work that percentage up to 20%, particularly in the early project stages. That may be the same number of Master programmers, but just keeping the team smaller (with fewer Apprentices early as recommended above.)

Pitfalls of a Team Out-of-Balance

The most common destructive mistake for an Agile team is to have too many Apprentices. Not only do they not produce in pairs, the best you can hope for is that they didn't damage the code base today. As individuals, it is an almost certainty that damage has been done. But the damage goes further than the code base; an Apprentice who hasn't positively contributed to the project is going home not feeling good about themselves. That creates an unnecessary morale problem for the individual and the team.. I don't know of any programmer who goes into work saying, "Today I am going to create some bugs." That this happens is not a failure of the programmer, but in the team creating the situation. So bring on apprentices only at the rate they can be productive to the team; otherwise, be courageous and defer the staffing, ignoring what your spreadsheets are telling you.

Even if you can tolerate 50% Apprentices in theory, you should not start a project with that mix. The early few weeks are the time in which the initial application architecture and design become visible. Apprentices can rarely contribute to these efforts, and can feel useless. There is one exception to this guideline: An Apprentice who has domain knowledge is very valuable to this initial team; providing key insights in what will need to be done in the long run. So start your projects with few, if any, Apprentices, and stage them into the project as the rate you can productively absorb them.

If you are attempting a reasonable size project without Master programmers, you are running a great risk of failure. Master programmers are the key to building the application architecture and design incrementally. Agile works by having such talent embedded in the team. Without it, significant up-front architecture and design is required to provide the road map for the Journeymen.

Many Agile projects seem to start fine, then seem to hit a wall in a couple of months. It is almost like Agile is not working. Refactoring is common, and is being cited more and more often in stand-up meetings. This is actually a sign that the design is weak, a reflection of the lack of continuous guidance a Master programmer provides. So ensure you have sufficient Master programmers on the project, particularly in the formative stages.

The flip side of the Master programmer requirement is that they may not be required in small or enhancement projects. A small project for certain short-term benefits may not reach a crisis point before it is complete. Similarly, if enhancements are being made to an existing, healthy code base, Journeymen are fully capable to following the tracks laid down by previous Master programmers. So Master programmers are not required for small enhancement projects.