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.

Ideal Skill Ratios in Pods

So are, we have talked about pods, ideal team Agile team structures, and the proper mix of developer skills in the pod. In this post, I would like to describe the needs for other skills in the pod.

An ideal pod would contain:

• 4-6 pairs of developers (8-12 total)
• 2-3 business analysts
• 2-3 testers
• 1 ambassador (aka project manager or iteration manager)
• 1 customer or customer representative (rotating on need)

So adding to our pod formulas:

Analysts + Testers + Managers + Customers = 80% (Developers)

So if I calculate how many programmers a project should need, I add another 80% to cover the other roles. So between this ratio and the productivity uplift I give to the programmer skills (5:2:1 for Masters, Journeymen, and Apprentices), I have the tools for doing my Agile project plans for a pod. Of course, this is just the starting point for the plans. I adjust skills constantly throughout the project.

For example in the first release of the project I am currently working on, we ran it successfully with 3 pairs of developers, two analysts, a single tester, and a single project manager. The next release had the same 3 pairs of developers, but only a single analyst and a single tester; metrics showed we should have had a second tester, however. Overall, however, the project is successfully running light on non-developer resources.

On the other hand, an early project on which I worked at ThoughtWorks ran its last release with one project manager, one combined customer/business analyst, 3 pairs of developers, and over a dozen testers! The customer was writing the stories herself, perfectly able to keep work flowing to the developers. The developers were a Master-heavy mix, and produced accordingly. This high productivity drove the need for up to 17 testers at one point; no investment in automated acceptance tests had been made.

Despite these examples to the contrary, I like the above ratios for planning. It is my starting point, and I adjust accordingly.

Pods -- Ideal Agile Team Structures

I described in a previous post that you probably have the wrong team working on your Agile project. It is wrong because you can't find the ideal team members initially, it is wrong because the needs of the project change as the project progresses, and it is wrong because the members of the team themselves will grow and change. The core recommendation from that post was to constantly tweak your team.

Typical, productive Agile teams seem to conform to a certain shape. This observation is borne from my experience in almost a decade of Agile projects, and is reinforced by colleagues at ThoughtWorks from their experiences. I am calling such ideal Agile team structures pods. I offer yet-another-term for several reasons:

• The term team doesn't convey enough,
• I haven't read of an alternative term,
• Several other good words are already in use,
• I like the collocation connotation of pod,
• I like the self-contained connotation of pod (i.e., all the needed skills are collocated)
• It provides an organization unit for broader people-oriented discussions
• There is a quirky sci-fi angle I can't resist

I will be exploring many aspects of pods in a series of posts. Let me quickly summarize where this is going:

• There is a particular mix of developer skills in a pod (a mix of Masters, Journeymen, and Apprentices;
• There is a particular mix of team skills (analysts, developers, testers, management);
• The team is self contained and collocated;
• The team is empowered, making decisions in its areas of competence;
• The team is self-managing (including self-apprasing);
• Team metrics provide insight into the effectiveness and composition of the team; and
• The team is semi-permanent, spanning project life cycles.

Much of this is common sense. Much of this is obvious to practioners of Agile. But much like the practices of XP, the total is greater than the sum of the parts. I still strive to create the perfect pod for projects on which I work, but I haven't yet achieved it.

Do you have specific characteristics for your ideal Agile team?

You Have the Wrong Team

As a project manager, you have just staffed your project. Sorry to be the bearer of bad tidings, but you have the wrong team. If you an experienced project manager, you already know this. But you did the best you could from the resources you had available. It is the wrong team because:

• You are missing the experience you need in some key areas, and
• The team members don't necessarily work well together.

Agile practices help here, particularly the practices of collocation (and you do sit with your team, don't you?) and pair programming. If you are missing experience, collocation and pair programming lets you grow that experience by judicious pairing. Knowledge transfer is quite rapid and efficient in this environment. Collocation also dampens down the "finger pointing" that often plagues teams. ("He doesn't understand!", "She is so stubborn!", and the like.) It is much more difficult to talk behind someone's back when she is sitting in the room with you.

If team members still have difficulty working together, your being in the room provides insights to the solution. Is it a matter of tone (challenging, dismissive, personal rather than business)? Then coach on interaction style. Is it disagreement on technical matters? Ensure swift resolution before it becomes personal.In this area, Agile practices can be a disadvantage:collocation and pair programming will exacerbate negative relationships. Whereas you might be able to ignore or defer action when each team member sits in their own cubes, such deferrals are quite destructive in an Agile team with its close proximity.

Net-Negative Producing Programmers (NNPP)

Agile luminaries have coined the term NNPP to identify team members whose overall impact to the project is negative. That is, the work they do is less than the harm they do to their colleagues' productivity. An NNPP may be productive outside of an Agile environment. In a cube, their griping has no listeners. There challenging, terse tone goes unheard. But given their visibility in a collocated environment...

I recently saw on the Web a report purporting to show the impact of one bad apple on the rest of the team. A single individual typically can negatively impact other team members numbering in double digits! So indeed, one bad apple can spoil the whole bunch.

There are several ways to identify such individuals:

• Observe. Being in the room, you can see the behavior. Even more important, you can see the impact on overall team. The situation can be corrected by coaching, or ultimately, removal.
• Ask the team. The team knows who is acting incorrectly. Borrow a lesson from Survivor, and let the team vote someone off the island.
• Who gets picked last? If pairing is practiced, who is the person no one wants to pair with?

If you fail as a project manager to act quickly on identified NNPP, morale issues will quickly ensue. Your inaction, in particular, will be glaringly obvious to the team. Your leadership, dedication, and even competence will come under question.

Once more for emphasis: Failure to address an NNPP problem will rapidly destroy team productivity.

The Continuing Issue

The real fatal flaw in staffing projects, and Agile projects in particular, is not realizing that the project staffing needs change throughout the project. Projects that acquire their staff, and then stick with that staff throughout, will incur excessive costs if not fail outright. Staffing must be adjusted throughout the project.

A few years back on an eight-month Agile project, I made 10 staff changes in the first 6 weeks. The core development team had 16 different participants, but only 4 were on the project for the entire time. Rather than being a disaster for such team instability, the project set high water marks for productivity and quality that have yet to be touched.

Why does staffing need to be adjusted throughout a project? It is for several reasons beyond staff quitting and needing to be replaced:

• The needs of the project change throughout the project. DB tuning will be important at some stage, but not others. Knowledge of systems with which the project much integrate will be needed at some time. The general load of analysis, development, and testing will drift during the project.
• Team members will grow during the project, particularly on projects lasting more than six months. Exploiting this growth is part of good team management. Again from the above example, I reduced the number of developers to six toward the end of the project. They produced so much code, however, it took 17 testers to keep up. The developers skills had increased that much.
• An inbred team will cease innovating. Studies of innovation reveal a significant drop in innovation in a team that has been together for as little as six months. New blood is needed, even if only to challenge the patterns of current thinking.

As a project manager, you must constantly be alert to tweaking the team. You may raise eyebrows by constantly shifting your team composition; ignore them. When the need for an expert has passed, roll her off the project. Bring in a specialist when the need arises; exploit collocation and pair programming to harvest the knowledge and release the specialist. Perhaps that resource you really needed was not available at the start of the project. Bring them on board when they are available.

Successful team tuning requires building a strong relationship with two groups. First, be willing to share your experts with your colleagues. Hopefully, they will reward your good will with the loan of a needed expert of their own. Don't hoard resources when the need has passed; rather, release them to reduce your costs and maintain the morale of the resources. Second, build great relationships with your staffing or resource management team. Send them flowers or buy them a case of beer (or both); they will start to call you when a resource becomes available that you might use.

Application development is chaos; react or face corresponding chaos in your team.

All Programmers are NOT Created Equal

All programmers are not created equal. There. I have said it. It is our equivalent to saying, "The emperor has no clothes."

There is much evidence that, indeed, all programmers are created equal. My exhibit for this: hundreds of thousands of spreadsheets built by project managers. Okay, maybe I will count that as hundreds of thousands of exhibits. I have even contributed at least several hundred of them myself. It doesn't make it true, no matter much it makes the spreadsheet easier to use.

Okay, so it may not be true that all programmers are equal. But it is it approximately right? In my experience (many, many years) on real projects with real delivery deadlines, there is an order of magnitude difference between programmers (that is, 10x difference). Even after throwing out the incompetent programmers (who produce zero), the really good programmers are ten times better than the really mediocre programmers. So even in approximate terms, all programmers are not equal.

Ask a programmer you know about this. (You may be a programmer yourself.) Do they know a really good programmer? How good is she/he? You will likely hear of legendary feats, impossible tasks done in a weekend, feats of heroism worthy of superhero status.

So as a project manager, you should seek these resources out. The "one" on your spreadsheet can become a virtual "ten". That is contingency, risk management, and a cheap insurance policy, all rolled up into "one".

How do you find these programmers for you project? Sorry, more bad news here for the project manager: These resources don't automatically correlate to most of your company metrics.

• Some correlation with experience: Look for years programming; discount years of being an architect or any other non-programming role that doesn't involve personally writing code.
• Negative correlation with years since directly writing code for the job.
• Slight correlation with title/level: Does your organization have tiers of programmers (Dev 1, Dev 2, ...)? Higher levels are more likely to be stronger programmers. If your company has a true meritocracy (versus pure seniority system), a top-tier programmer must have been good at some point to be promoted. So there is a bit better chance that it is still true. Caveat: Negative correlation with years since directly writing code for the job.
• Negative correlation with non-programmer titles: Speciality titles are signs that (1) the skill is now gone, or (2) "Those that can't program, [fill in your favorite job title]". Be wary of architects, particularly if they come with adjectives (web-services architect). Designer titles are a little less risky, but have the same flaws. Ask the key question, "Do you write code?" Run away from any answer like, "I am past that" or "I leverage others".
• Some correlation with salary: The better programmers are probably paid more. Someone has recognized that they are worth holding onto. Most organizations are not as dumb as we think about matters of survival.

So, if all these indicators are not so good, how do I as a project manager know I am getting at least my fair share of these super-programmers? Easy. Ask the programmers. You may not recognize their legendary feats, but they know about them. You may need to prod them a bit; you may need to tolerate some geek-speak. Nod knowingly, and listen for the names. Another way to prod: Ask them, "If you were marooned on a island with the natives that are cannibals, and you had to program your way off the island, who whould you want to be there to help you?"

How many of these super programmers do you need? As many as you can get. What happens if you don't have them? Well, that is a topic for another day.

[This is part of the People thread of this blog. See The 3 P's of Agile: Process, People, and Pods for the overview.]

The 3 P's of Agile: Process, People, and Pods

This is the first post on the topic of Process, People, and Pods. This series of blogs will explore Agile programming beyond the traditional boundaries of "an alternative to waterfall".

So where does this name come from?

Process refers to the Agile alternative to a phased process (aka waterfall). But the process discussion will go beyond that. Agile has its roots in the Just-In-Time (JIT) manufacturing process; Lean is the more popular name for these techniques as this thinking explodes past the manufacturing sector. So Process will also address management techniques that promote Agile versus traditional engineering techniques like Gantt charts that cripple Agile productivity.

People addresses the different way to think about the most important component of software development: The people that conceive it, create it, and make it available for use. Let me summarize how radical the Agile thinking should be here. If you don't believe that waterfall is the right methodology, what do you think about people that are titled after phases of waterfall? In People discussions, we will expose the flaw in thinking of about people as architects, analysts, designers, developers, and testers. Not only is Agile productivity rooted in breaking this thinking, there are positive moral benefits to be gained.

Pods takes the people point to the next level. If the job titles are wrong, what about how we organize departments around these titles? Pod refers to an ideally structured Agile team. If the name invokes B-grade sci-fi flicks, you have caught a bit of the roots of the name. It also comes from thinking of the synergy of a bean pod full of seeds. In Pod discussions, we will discuss ideal Agile organizations. What about the career tracks we define? I would suggest that Agile teams are organized differently. Agile teams should act differently, be trained differently, and be appraised differently.

I look forward to feedback on all of this!