V Team composition

The previous chapter outlined some heuristics for managing teams and discussed the team as a stable unit of production. This chapter will continue the elaboration of those heuristics by looking inside the team.

Next I want to look inside the team try to answer two questions:

• What roles should be found on the team?
• How many people should be on the team?

In order to answer these questions I first need to discuss team composition and put some preliminaries in place. Once these building blocks are in place discussion of teams can take place. If however you want to know the answers and aren’t interested to know how I reached those answer simply skip to the end of this chapter.

34. Who is on the team?

The answer is: Everyone required to deliver the product and generate value. The team exists to do the work, not to manage the work and not to make requests on others.

The teams should be staffed to deliver business benefit. The team needs all the skills to do the work they are responsible for - including identifying new work and measuring benefit delivered too. Dependencies on other teams should be minimised.

The closer the team is to being able to recognise business benefit without having to depend on other teams or individuals the greater the chance of success. A tight feedback loop is not only good for understanding customers/users and addressing business benefit directly. It is also motivating for individuals and teams. When people can see the difference their work makes they invest more of themselves in the work and feel greater achievement when they see the benefits of their work.

At a very minimum this means: all the technical team. Coders most certainly, tester (if test specialists are being used), requirements people (again if specialists are being used), and if necessary operations people, analysts, subject matter experts, and and and, the list could go on.

If specialists like software testers and requirements engineers (business analysts and/or product managers) are not employed then the people on the team need the skills, authority and time to undertake these roles as necessary.

The general rule is: minimise dependencies outside the team by putting the skills and authority inside the team.

Ideally - and there are a a few companies actually do this - the team is not just the technical people but the business too. Not just a Product Manager but the actual people in the business who will use the product, or the people who will market the product

I once saw a photo of a team at Redgate software in Cambridge. The photo showed a whole team in their office area. The team included programmer, testers, the product manager, the product marketeer, the website designer and some operations people too. All sat together and all fitted easily in a photo.

As said earlier: the team is the production unit, they are attempting to deliver benefit to the company. The team is a whole.

Another way of thinking about these teams is as Object Oriented Teams. They contain the data (knowledge) and functions (capabilities) to do the work needed. Rather than constitute teams along functional or hierarchical lines - akin to layers of procedural code - teams are objects. Each object, each team, delivers a service.

Managers can reason about teams, not individuals - a bigger unit of capacity. The internal workings of the team may be opaque, as long as the team delivers the service they may organise themselves as they feel fit.

Sooner or later this logic may find a limitation. Would it make sense for a team to include 50 call centre operators? I don’t know but I do know that if they are outside the team there needs to be regular and open communication. Of course there may be teams within teams in the same way that I can be both English and British (and even European) sub-teams may be nested as long the aims are common.

Consider hypothetical retailer team shown in the diagram. This hypothetical mail-order retailer is one team. This includes a large call centre team - taking orders and dealing with customers issues; an outbound marketing team (advertising, PR, etc.); a logistics team to manage the warehouse and get products to customers and of course technical teams to develop and operate the software customers and the other teams use.

In one sense this is one team with shared aims. But there are also sub-teams with their own aims which need to build to the overall aim. There needs to a shared understanding, a shared vision and a shared belonging. In a small retailer - an embryonic Amazon - all these people may sit in one room. The challenge, as teams and companies grow, is to maintain that which is shared.

Technical teams specifically need to be fully staffed with all the skills they need. When they share staff dependencies creep in and priority conflicts emerge.

And it makes sense to fully staff the team from as early as possible. If the team needs a professional software tester that person needs to be involved earlier rather than later.

Having said that, there is one occasion when this rule is broken: in the very beginning, when a truly new team is being formed. A full discussion of Minimally Viable Teams (MVT) must wait.

Finally, the more a team can be cross functional, the more it can contain all the skills it needs, and the less it needs to call out to other teams then the more effective work will flow through the team. Each time a team stalls because of a call out then it is a sign of where the team could be better.

Cross functional teams do not come into being by management edict. Few teams start off cross functional. Becoming a cross functional team has cost. In the long run those teams which consciously decide to become more cross functional will see benefits.

35. Developers are not the only fruit

There is a tendency among some managers to see programmers as the only people who matter on a team. This leads to unbalanced teams with many developers but no other specialists. However, there is some legitimacy in this point of view.

And there is a tendency among another group of managers to see programmers as a small part of the overall team. In these places multiple analysts and other requirements people and several layers of project and programme managers all conspire to ensure the few actual programmers are insulated from any actual users and kept well away from any decisions about what should be written. Such teams are also unbalanced and very expensive.

In an organization which develops software all roles except programmer are optional. Sometimes programmers are hidden - outsourced, off-shored, employed through opaque contracts - but if no code is written the organisation does not develop software.

One can object to the idea that all non-programming roles are option in principle but in practice programmer only teams do exist. Whether it is a good idea to staff a team with only programmers is another question. Some are very successful, some are utter disasters.

Larry Maccherone has collected data which shows that teams without can deliver the better quality than teams with testers and even teams with a high ratio of testers to coders (Maccherone 2014). However, teams without any testers are also shown to deliver the lowest quality. According to these studies teams without testers can also be highly responsive and productive.

This may sound confusing at first until one remembers these studies look statistically at many teams. The data shows a correction to a causation. One explanation is: average programmers teams without testers will perform badly, but elite developers may deliver better quality and service without testers.

I have seen without testers. Sometimes programmers can double up as testers. Sometimes they adopt practices to improve their quality and minimise the need for testing. And sometimes they just ship poor quality, buggy, software. I have seen all three models for teams without testers - and there are probably some more.

And I have seen teams without specialist requirements people - without product owners, product managers, business analysts and requirements engineers. Without a requirements specialists programmers might talk to the customers and stakeholders directly, they may work from a big document, they may invent what they think is needed, or they might create software which is unsuitable for the desired purpose.

I could continue by examining other roles which are often found in software development environments but the point is made. Without coders there is no software.

Having said that one needs to ask the question: how do these other roles help software programmers? How can other specialists help make for more productive teams?

This boils down to a question of scale.

On very small teams - micro-teams, less than two full time staff - it only makes sense to have a programmers. Hopefully talented programmers who can keep quality high, do a bit of testing and talk to customers directly. Having one business analysts for one programmer is not only expensive but likely to lead to too much emphasis on “what might be built” over “what can be built.”

Other management roles tend to fall into the same trap. There is an organisational smell when individuals are managed by more than one person and when organizations count fewer programmers than they do managers and analysts. As a general rule there should be more programmers than those who do not code or test.

Unfortunately it is not uncommon in corporate IT to see a small groups - hardly teams - of programmers and testers out numbered by non-producing roles. For example, at an American bank I observed an effort by two programmers in a remote location answering to a technical lead, with a tester in third location, answering to a test lead, they were managed by both a development manager and a project manager, in addition there a business analysts and architect were assigned to work part-time on the project. In other words: three active workers carried six non-coders. If this was not enough the bank added an Agile Coach to help “the team” improve their performance.

When this smell arises it is usually because the organization sees so little return from coding that they are fixated on “doing the right thing.” All these non-coders are there to ensure the limited resources are used to the greatest effect. Such organizations would undoubtedly be better of employing more coders and few non-coders, even accepting that some code would be “wrong” or “wasted” but with more coders there would be more right code.

Having a ratio of one tester for every programmer is a pretty damming endowment of the code quality. Organizations who find they need to get to this test to developer ratio - or even more testers than programmers - have a serious, and expensive, quality problem and would be well advised to invest in other mechanisms to improve quality. For example, training the programmers, instituting code reviews and introducing automated testing and unit and acceptance levels.

As a general rule one should expect the number of programmer on a team to be greater than any one other group; and on a health team the number of programmers may well be the greater than the sum of all the other roles on the team.

36. Ratios

Experience has taught me two ratios which I use as a rule-of-thumb when examining teams. Armed with these rations sizing team becomes for easier - a subject that will be examined in another chapter.

Requirements to programmers

1 Requirements specialist to between 3 and 7 programmers

Whether the requirements specialist is a business analyst, product manager, product owner, systems engineer, product specialist, requirements engineer or some other title there should be one of these for every three to seven programmers.

When a product is well established, the market is known and slow moving, and when the programmers know the domain - maybe even have direct customer contact, then, one requirements specialist may support seven programmers, hence 1:7.

Since the programmers are well versed in the product and the market - and therefore the needs of users - and change is slow, they will need less guidance and information from requirements specialist. Indeed the programmer may be minor experts in the domain themselves.

Still this ration may be higher than is commonly observed. I would justify 1:7 on the ground that building the wrong thing is very expensive. Therefore rather than employ an eighth, ninth or tenth programmer I would rather use extra requirements capacity to reduce demand and/or focus development on higher value work.

At the other end of the spectrum: when a product is new, when the market is fast moving, when customers are being added rapidly and when programmers are unfamiliar with what is needed - and the customers - then there is a greater need for requirements specialist. Therefore one specialist might work with just three developers.

In the extreme, in new teams or really rapidly changing environments this ratio may go lower, 1:2 maybe. However, once it gets so low the overhead in communication becomes difficult to justify.

If there are only two people working on a product it is probably better to have people with more varied skills and abilities and ask them to engage in requirements elicitation and implementation. When the team expands the third role may be only a programmer in preparation for when one of the first individuals becomes the specialist.

37. Tester to programmers

Use 1 Tester for between 3 and 7 programmers

The same ration applies, although for different reasons to the other side of the development pipelines.

When a team contains three full time programmers there is enough code produced to justify a dedicated tester. Since there are three individuals working the capacity for misunderstanding exists. The three individuals have probably divided the system into particular modules for each person and hence integration problems exist. So it makes sense the add professional testing of the overall product.

And if there is a user interface of any kind then there is always a need for for exploratory testing.

Therefore when a fourth person is added to a team of three that person should be a professional tester.

If further expansion is anticipated, or the work is expected to run for a long while, then delaying the addition of a tester will create problems later on because the first tester needs to catch-up with the work done already. This is particularly true when automation testing is to be used. Leaving it too long before starting to automate tests may make it impossible to adequately retro-fit the tests. (Fortunately programmers are more able to help with catch up here..)

When teams employ automated testing - especially if they use automated unit tests written in a test first fashion - then they may be able to maintain high quality even on large code bases. When team institute other quality control mechanisms - code review, automatic code analysis, regular builds and more - then it is possible that one tester may support seven programmers.

A teams of less than three which feels the need to add a dedicated tester one needs to examine the quality practices. How can two people create enough work to keep a third busy? Chances are if a two person team needs a tester they are producing very poor code.

38. Solo programmers

I read somewhere - although I can’t find the reference so I can’t cite it as fact - that over 50% of all development “projects” operate with a team of one. Fairly obviously this isn’t really a team, its an individual.

Whether this statistic is true or not it is certainly true that in my experience many organizations run many software development projects with one person “teams.” I might even go as far as to say staffing a project with one person is normal in many places.

For me teams start at three people. Anything less than two (full time) team members I consider to be “micro work” - or a “micro project” when the language of projects is used. On very small work efforts the dynamics of work are very different.

I’m sure there are some good reasons why one person projects are useful but normally I see them as bad smells. They are a means of looking busy without actually delivering much.

In particular one-person work efforts have their own, unique, dynamics because there is only one person. It is not so much a discussion of work flow or process as the working preferences of an individual. Having managers or other expert apply Xanpan, Scrum, Kanban or anything else to a “team” of 1-person - or even 2 people - is probably pointless. The individual may decide to adopt ideas from one of these approaches but working at such personal level there is little others can do.

Indeed, it is arguably whether it is worth investing management time in optimising the work of one person. Management time would probably be better spent in actually doing the work with the individual. (Unfortunately micro-projects are also fertile ground for those who practice micro-management to interfere.)

Micro-teams might be a way of hedging bets, they may be a way of reporting lots of “work in progress”, they may even be a way of satisfying many stakeholders in the short run (“Bill, Jane is working on your project as we speak”) but one, or even two person teams have a lot of negatives:

• Variability: when one person works on a development effort it will suffer from significant variability. If the one person get stuck on an issue, gets dragged off to consult on another project, falls ill or, heaven forbid, takes a holiday then the amount of work, and progress towards any given date, will be significantly effected.
• Schedule risk: obviously following on variability is risk, specifically schedule risk because of the influence of variability. It is very easy for a piece of work to be delayed, far harder to make up time or get ahead of the schedule.
• Knowledge risk: developers are normally quick to point out the “bus factor” when a piece of work is dependent on one person. In truth development efforts are surprisingly resilient to the loss of key individuals and bus accidents are rare. However I stopped laughing at “bus factor” claims the day I met a development manager who had lost a key member of staff in a bus accident. Resilience comes at a price: delay, lost schedules, lost targets and lost benefits. Very rarely is all capability lost but cost-effective capability is lost far more often than bus accidents.
• Quality and sounding boards: when an individual works alone they have nobody to consult about their work, no one to review their work, no one to bound ideas of, no one to keep honest when they decide to cut-a-corner and no one to share the pain when something goes wrong.
• Solo working efficiency: One might also consider the efficiency of one person working alone. Sure some programmers are solo individuals but on the whole people are social animals. They enjoy working and sharing with others. Everyone has days they are down and when you work alone there is nobody to help pick you up. When you work with others there are people to break your mood, even if you don’t want them to. And there are people to help cheer you up when accidents and problems hit.

Finally perhaps the most significant problem with micro-teams is simply:

Small teams reduce cash flow and return on investment

A later chapter will consider in more detail the financial implications of different teams sizes. Specifically it will examine the effects on cash-flow and return on investment of using multiple micro-teams against larger teams working on sequence projects. This analysis shows that:

Larger team which deliver products sooner improve cash-flow thus producing higher return on investment - calculated as net present value or internal rate of return.

In my view relying on one person micro-projects is a failure mode used by managers who cannot manage teams effectively. A far higher return on investment can be had from directing a larger team to a development effort, completing the work and recognising benefit and then advancing the team to the next effort.

39. Programmers

It may seem unfair to put programmers centre stage but as explained previously: programmers are the one constant in a development effort. Thus it makes sense to reason about team sizes based on the number of programmers in the team.

Once the number of programmers on the team is know then it is a lot easier to calculate how many testers and requirements specialists are needed by using the ratios already given.

Besides, most managers tend to reason about the number of programmers on a team first and only later, if at all, think about other roles. Which is a shame because I am not the only observer to have noticed that bottlenecks in development are more likely to be caused by a lack of testers, or even requirements specialists, than they are by a lack of programmers.

As already noted micro-teams exhibit a number of problems, therefore it makes sense to have more than one programmer on a development team. With two programmers the individuals can discuss solutions and approaches, they have a second pair of eyes to look at problems and, more importantly, there is now someone to review their code.

With two people on the “team” pair programming becomes an option. Although with just two the social dynamics will prove difficult as the two individuals will spend a large part of their working day in close conversation with each other.

With just two on the team it is questionable whether it is worth dedicating a requirements specialist or tester. Are they doing enough work to keep these people busy? If the tester and analyst roles cannot be kept busy then most organizations will seek to split their time with another piece or work. When this happens the individuals must engage in multi-tasking, so their performance falls, conflicting priorities will appear and delays will quickly develop.

Putting three developers on the team addresses these problems but it also means there is a step change. At two programmers analysts and testers will most likely not be dedicated, so the team size is probably two plus two halfs (one full time equivalent if your organization uses that terrible term.) But add a third and suddenly a dedicated tester and analysts make sense so the team jumps to five. Suddenly costs go up.

Even at 3+1+1 the additional roles may not be fully utilised and conflicting work may be added.

At three programmers there is more variety in discussions, more people to discuss design options and three possible pairing combinations to ease the social dynamics. Although pair programming become easier it still has problems. There is a not much variety in partners and at any time at least one person would be working.

In general the bigger the team the easier it is to justify dedicated specialist roles.

Four programmers looks like a much better position to be in. It is easier still to justify dedicated test and analysis people and there are now six pairing options, there is enough variety to make the social dynamics work.

It now become possible to think in terms of standard team sizes. As the number of programmers increases so to do the specialist roles - specifically testers and requirements specialists (analysts.) This graph shows the hypothetical model.

The next question is: how many programmers?

Before this question can be answered some more factors need to be considered so I must defer answering this question until a later chapter.

40. Pair testing? Pair analysis?

Having made the case for pair programming it is only fair to ask: if pairing is good for programmers wouldn’t it be good for testers and requirements specialists?

The short answer is: Yes. Pair testing and pair analysis make sense. There are even a few cases on record of these activities taking place.

Sometimes the pairing is heterogeneous. According to Dan North in the early days of Behaviour Driven Development a business analyst and programmer would pair. The BA would write a BDD style test, pass the keyboard to the programmer who would then write code to pass the test and push the keyboard back. All the time the pair would be talking and exchanging information.

There are also stories of testers pairing with programmers. Though given that organizations often use testers as a check on programmers such examples aren’t very common.

I’ve even heard of a triple: programmer, testers and business analyst. Although since BAs and testers overlap when it comes to validation this might have been overkill.

Still, pair programming is more talked about than practices and other forms of pairing are in their infancy. Certainly, given the ratios set out here it is only large teams that would have the staff to be able to support such pairings.

As with pair programming I encourage you to try pairing other roles. However my gut feeling is that heterogeneous pairing - pairing different roles - may prove more effective when it comes to testers and analysts.

Other roles and ratios

Having observed that all software producing organizations employ programmers it is also worth observing that there is very little consistency in the other roles used.

Software tester is the only role which even approaches programmer in ubiquity but how they undertake their role, what their relationship is with the programmer(s) and when they do there work are completely variable.

On the pre-programming side there isn’t even consensus on what the requirements specialist role is called! Inside corporations and consultancies one commonly find business analysts have largely replaced the out-dated system analyst role. Software product companies (what used to be called ISVs) tend to use product managers although these roles are more common in Europe than the USA. Requirements engineering serves as an umbrella term for analyst and product manager roles but many of these people filling these roles would not consider themselves requirements engineers.

There is very little consensus on whether teams have software architects - or what the software architect role is.

While the software designers - who may be called Designers, User Experience Designers (UXD), User Interface specialists, or some other title - have become more common in recent years they are still more often notable by their absence then presence. Such specialists are never found in internal, corporate, development.

Nor is there consensus on the use of project managers - some project managers are analysts while others understand little about software. Some are administrators while some are omni-present.

Unfortunately the Scrum method has muddied the waters further by introducing the role of Scrum Master. Some Scrum advocates accept the Scrum Master as a type of Project Manager (e.g. Schwaber 2004) while others reject the idea that Scrum Master maybe a project manager (e.g. Deemer et al. 2008). Certainly in practice many, usually large corporate, organizations view the Scrum Master as a project manager or project manager substitute. It is also true that many, usually small, organizations have rejected project managers in favour of a Scrum Master. And it is also true that many teams have neither roles.

While many Agile teams do have a dedicated role of Scrum Master, other Agile teams make do with a part-time Scrum Master (e.g. one who also works as a coder or one who works with multiple teams) while others make do without this role at all.

In my experience there is no clear advantage to having either of Project Managers or Scrum Master roles but the confusion over the roles does make conversation more complex! Indeed I am skeptical about the whole Scrum Master role. In the teams I observe I am more likely to see a need for Project Managers than Scrum Masters, and more likely still to see the opportunity to improve effectiveness by reducing the amount of project management undertaken.

Nor are the other non-manager leader and administrator roles - the roles I sometimes call Non-Commissioned Managers (NCMs) - consistent: team leads, technical leads, Scrum Masters, senior or lead developers and more are frequently absent.

Not only does one size not fit all but organizations don’t even agree on the standard sizes!

41. Finally

All the ratios and discussion above assumes each individual is dedicated to one team and one team only. Putting individuals on multiple teams leads to conflicts. It is better to avoid dividing individuals and forcing multi-tasking.

Companies must accept - if only as a matter of simple decency if not practicality - part time employees but it makes little sense to use full time employees as if they were two part-time employees.

As a general rule of thumb managers should favour short fat work endeavours rather than long thin ones. For example, it is better to use six staff work on project A and then move as a whole to a project B a few months later, than it is to have two staff troikas developer A and B in parallel over a longer period. This point will be discussed in more depth later.

42. References

Deemer, P., G. Benefield, C. Larman, and B. Vodde. 2008. “Scrum Primer.” http://www.scrumalliance.org/resources/339.

Maccherone, L. 2014. “The Impact of Agile Quantified.” In Lean Kanban UK. London.

Schwaber, K. 2004. Agile Project Management with Scrum. Microsoft Press.