II Teams Heuristics

As stated in Xanpan book 1:

Xanpan is team-centric: the team is the production unit, need goes in, working - even valuable - software comes out. This is the machine, the goose that lays the Golden Egg.

In a software development organization - and many others - the means of production is the team. Thus teams need to be considered in more depth.There are several heuristics which can be applied when thinking about team:

• Teams should stay together, teams need to be stable and enduring. A team may grow or shrink over time. Once in a while a team may be dissolved and occasionally a new one be created. Like successful sports teams the nucleus of the team stays together.
• Teams need to have a sense of purpose and responsibility for delivering towards that purpose. When forming new teams they should be built around the purpose.
• Teams should contain all the skills required to do the work they are expected to do: every time they must “call out” for work to be done dependencies occur, delays arise, complexity rises and responsibility for doing the work becomes opaque.
• Devolving authority to the teams and team members will improve the flow of work through the system: decision can be made in a timely fashion by those who are closest to the work and who know the most about the details.
• Team members may have specialisms but are encouraged to work outside of specialism on the highest priority item. The more team members are able to cross specialisms the better the work will flow. Yet when deep technical knowledge is needed specialists are needed - this might be a reason to avoid such technologies.
• Specialists - in particular Software Testers and requirements experts (be they analysts, product managers or others) - should be embedded in the team. These are first class members, no team members should be considered second class (as unfortunately happens sometimes with software testers.)
• Flow the work to the team: the team is the unit of production, teams can work on more than one stream of work, or project, at a time as long as priorities between the competing streams can be reconciled without introducing delay.
• Align teams with business lines (products and services): it is no longer just software product companies which live or die by the quality of their software. Increasingly companies offer products and services which are dependent on software. Without the software the company has nothing. Every company is a software company.
• Teams should be sized and staffed according to business priorities and strategy rather than the effort required to do any particular piece of work.

The days of managers allocating individuals to work, and occasionally intervening to move individuals from Project X to Project Y, should be history. Managers are busy people, too busy to be involved in details like who’s doing what. Team members will be more motivated if instead of being assigned tasks they have a part in both deciding what the tasks and deciding which tasks they will work on.

Managers need to deal with bigger concepts. They form the teams, teams are given a goal, managers leave the teams to do what needs to be done. Sure they review work - a portfolio review or similar - but that doesn’t happen every week and they review complete work, not small pieces. Once in a while they may become involved to rebalance teams as company priorities, objectives and strategies change but that doesn’t happen every month.

The rest of this chapter, and the following chapters will expand on these heuristics.

9. Teams over projects

Xanpan is project agnostic. There is a team, there is work to be done, the flow of work needs to be regulated and controlled so that the team can a) work efficiently, b) deliver with some degree of predictability. Teams and managers frequently use the language of projects and project management to describe ongoing programmes of work. This leads to confusion.

In the simplest model one team works on one project. In this case all the work undertaken by the team relates to the project. The team comes into being to undertake the project and is dissolved at the end.

A more common scenario is that a team exists and undertakes work on an existing and continuing product. While some of this work, and periods of time, may be assigned to a particular project this is an accounting convention. More likely than not the team and the product will continue to exist beyond this project, the work will simply be counted for under a different project label or a “business as usual” label.

Another common scenario is that a team exists to work on a project but must undertake ad hoc work for other projects or on other products. Rather than being dedicated to a single stream of work the team, or just individuals on the team, must slice their time between different streams of work.

Xanpan focus on the team and the flow of work through the team. Whether this work comes from one or more projects, programmes or business as usual (BAU) is unimportant. Part of the role of managing the team is to ensure that work is correctly accounted for and stakeholder expectations are managed.

Teams will be most effective when the variety of work is the smallest, i.e. all team members work on the same code base under the same project focus. This set up will also provide the greatest degree of predictability when forecasting deliverables and schedule. The greater the variety of work the less efficient and less predictable the work will be.

Organizations need to determine whether they wish to optimise work for effectiveness and predictability or for flexibility and responsiveness.

As a general principle, for projects and similar types of work it should be arranged as a sequence of short-fat projects rather than parallel streams of long-thin projects.

While team members completely fungible the aims of favouring short-fat over long-thin are:

• To deliver value early, i.e. the first short-fat project to complete can be released and start generating value which the second is in development.
• Remove bottlenecks when multiple parallel streams require the same resource, e.g. four streams complete at the same time and content for test resource.

10. Clear benefits and purpose

Teams need clear sight of how their work brings benefits to customers, users and the business. Team are organised along business lines rather than functionally. There is no database or user interface team. Teams deliver a product or service to the business. A saleable thing in its own right, or tools to support a line of business.

Businesses increasing deliver products and services which are inherently software dependent or which could not be delivered without software, as a result all businesses increasingly resemble software businesses. The business is software. Business folks need to learn more about IT and to work with IT people.

Think of teams like amoeba, they are the cells that make up the bigger organization. Indeed Kyocera has pioneered and approach called Amoeba Management (Inamori 2013).

Kyocera’s Amoeba management was invented for a different knowledge based industry: specialists ceramics research, development and production development but there are lessons here for software teams.

The amoebas also holds the key to growth - or shrinkage. Amoebas grow and expand in size up to a point where they split, cell-like, into two independent entities. (This topic will be discussed in more detail later.)

Many software teams - particularly in corporate IT departments - find themselves buried somewhere inside the organization without any idea - let a clear idea - of how their work benefits the wider organization. This is not good for morale. And it is not good for resolving conflicts and deciding trade-offs.

Kyocera’s amoebas produce their own efficiency reports showing profit and loss. Each amoeba - no matter how deep inside the company - is a stand alone profit centre. Each amoeba measures its own costs and revenue. The company has created a series of conventions that allow amoeba to be customers of one another.

This approach allows each amoeba to make decisions to optimise its own performance and gives all employees clear sight of how their actions impact profit - or loss. This does not mean Kyocera teams run in different directions, that the company lacks a strategy or the company sub-optimises. The company has other mechanisms in place for those things - largely based on a shared culture. But it does mean each amoeba takes on responsibility.

Teams, amoebas, need to have a sense of purpose, a sense that the team - and individuals on the team - make a difference. Therefore the team members need to be able to see the impact their work makes. At a very minimum this should be visible on a financial report, better still they should be able to see difference their products make.

11. Stability

Teams need stability. This does not mean people never leave a team or that teams don’t obtain new recruits but it does mean that these are occasional, not regular events.

At a mundane level team stability is needed to provide continuity in data. If a development organization is to be run in a rational manor then data on past performance, or rather capacity, will prove useful. If a team has never worked together there will be no data so it is not possible to assess what might be achieved. Only with stable teams can past performance provide the data required to product accurate forecasts of future work.

Many people will have heard of the Storming-Norming-Forming and Performing model (Tuckman 1965) which described the stages a team passes through when becoming productive. Before a team can get to the performing state time (and therefore money) must be expended. Thus new teams cannot be expected to suddenly meet and “hit the ground running”. Team start-up time and costs must be factored into any work.

(The “hit the ground running” metaphor must be one of the most poisonous ever invented. I fail to think of any animal, sport or military team which can actually do it.)

At the other end of the cycle disbanding a team makes little sense. Once a team is performing why break them up when there is more work to do? The organization which owns the team has paid the storming-forming-norming and performing price and now has valuable data on capacity so why dispose of these assets?

Frequently former members of team will find themselves sought by those now charged with maintaining software either to undertake work or to share their knowledge. Since software survives it makes sense to keep the creators together to service the software as need be.

When teams have been disbanded finding former members may be the only option available to those who need to make changes. Consequently past work has a habit of following people and disrupting their new work.

Knowledge is the reason why team member are sought. Teams may see documentation as a solution to this problem, they believe that leaving documents behind will allow the next generation to obtain this knowledge. But documentation is rarely done and when it is done it frequently fails to describe what is needed - why would it?

Those writing the document can only guess at what the future readers will want to know. Frequently documentation is left to the end of a team’s allotted time. Time for documentation is squeezed, few people are enthusiastic about writing documentation and what is produced may be of low quality.

Worse still documentation may be written before any code is cut, it describes what is expected and may consequently not represent what actually comes to pass. Sometime teams get stuck creating great documentation, perfect designs, rather than actually producing useful software.

Stable teams contain this knowledge. There is no need to pay the price of writing the documents, no need to hunt down members and no need to disrupt their current work.

When people join teams they bring their knowledge, they also bring baggage: knowledge of past work. When they remain in the same organization they may be hunted down for this knowledge, they may be asked to help those who have “replaced” them. Attempts to resist these requests - perhaps by ring fencing individuals or time - create conflict and tension - both for the individuals and their managers. And as mentioned above these requests disrupt the new work.

A team centric approach accepts these requests and works to service either directly (by doing the work, absorbing these responsibilities into the team) or indirectly (by helping the replacements). By tracking and understanding this work measures can then be taken to manage this work.

Individuals who move to new organizations will bring less direct baggage - the previous employer is unlikely to come asking questions. But mentally the individuals will bring much of their mindset from the previous employer.

Of course teams will change - people sometimes retire or get ill. And teams will need to add new members - if only to replace those who leave. However these changes should be gradual and over time. Rapidly adding people to a team - something I call “fois gras” recruitment - will undermine the teams productive capacity.

It is 40 years since Fred Brooks coined his famous law:

“Adding people to a late project makes it later” (Brooks 1975)

This may be generalised as:

“Adding people to a work effort slows it down”

Teams may at times need to expand to take on a lot of new work, and they may shrink when peak work is done. Such transitions need to be managed carefully. It may make sense to think of a core team which stays together and services a number of products and may, when necessary, expand to cope with more work. Time will tell if the team shrinks back to the same size when the work is done.

But rather than regularly changing team composition to cope with changing demands stable teams can look for other solutions. They seek mechanisms to reshape demand - perhaps by moving work from high demand periods to low demand periods. Or by shedding low value work. Or finding creative synergies in requests. Or some other technique yet to be invented.

Optimisation

Because the team continue to work together they can also optimise their thinking. This might be thinking around technology, application or processes. The team is the unit of production and they should seek to improve their productive capability, i.e. optimise themselves!

Because the team are staying together they have reason to improve their technology and processes and because they are staying together they will see the benefits form their efforts. If a team is destined to be broken up at the end of a piece of work why would it strive to improve their methods of working and productive capacity?

The closer a team gets to “the end” the less attractive it will be to invest any time in team and productivity improvement. Indeed it might be more sensible to for team members to impede their productive capacity in order to prolong the time they spent together.

When managers intervene to optimise a team by moving people around the result is often counter-productive. First it reduces the incentive for team members to improve their practices if they know managers will ride to the rescue with more resources. Second by removing responsibility from the team to solve their problems it also removes the impetus and authority to solve the problems.

Adding people to the team may increase capacity - after a lag - but it will not improve efficiency. And since those people need to come from somewhere other teams suffer as people are moved.

Expanding a team through recruitment will reduce productive capacity long before any new employee starts work. Decision makers need to be lobbies to agree recruitment, bob specs need to be written, approved and issues, resumes or CVs filtered, interviews conducted, etc. etc. Doing this work removes productive capacity.

When a recruit starts work they need help learning their way around. It can be several weeks if not months before they are productive.

It is not unusual to hear of recruitment taking three months, and that is often regarded as quick. Hiring new people is a time consuming process and reduces productive capacity for many months.

Camaraderie

Teams which work together over time develop a camaraderie - a friendship, an empathy for each other. They share success, they share failure, success for one is a success for all and when one has difficulty others will rally round to help. Building such camaraderie is part of the storming norming forming and performing process. But no amount of team building causes can substitute for years of shared experience, pain and joy.

When a team shares success each member also shares responsibility for bring that success about - and they share in the joy when success is achieved. This way team members can see how their work, and their relationships, make a difference.

Keeping teams together allows camaraderie to build and allows the team, and their wider organization, to benefit from these shared bonds.

Unfortunately team which are too stable and lack diversity can suffer from a phenomenon of group think. When this happens team members search for harmony leads them to stop raising objections. To some degree stable teams can offset this by encoring diversity in the recruitment process. Still, completely stable teams are probably not the best idea.

Flow the work to the team

If the team are considered stable, how can a company match the work to be done with the resource available to do work?

The answer is to flow the work to a team. Teams already exists, an organization may have several teams, work comes and goes, unlike a team work is transient. Therefore work needs to be directed to the team that will do the work. If a team is experiencing a surge in the amount of work it is asked to do then expanding the team can be justified. Equally if a team is not receiving very much work it might be shrink. And teams may merge and teams may split.

Since the team has an area - or areas - of speciality and responsibility - one hopes it will become obvious where work will flow to.

Think of a team as a sausage machine: sausage meat going in, sausages come out; requests for work go in, working software comes out. If pork meat goes in port sausages come out, if chicken meat goes in chicken sausages come out. Software teams specialise in certain products but they work they do at anyone time depends on the requests which go in.

12. Area of speciality

Teams should have an area of speciality. Preferably this area of speciality is related to a business function, i.e. a business capability that produces revenue for the business. As such the team will have some skills and knowledge related to the business domain they are working in.

Since software exhibits continuity the team will have experience and knowledge of the software products which service this business function. And thus the team will have knowledge and experience of the technologies that are used in those software products.

Business domain knowledge - sometimes called the application or problem domain - and technical knowledge - sometimes called solution domain - go hand in hand. The individuals on a particular team will have both and they will support each other in their knowledge.

New team members are often recruited because of their knowledge and experience of some subset of this knowledge, usually the solution technolgies. For example, a team working on an accounts payable system written in Java and Oracle SQL may be able to hire a programmer with Java and Oracle SQL knowledge. While they may even have some knowledge of accounts payable they will not have knowledge of the actual application and the existing code because this is unique. (Unless of course the team can hire someone who previously left the team!).

13. Area of responsibility

Hand-in-hand with an speciality goes responsibility. When a team specialise in an area they are also responsible for it. They know - because of stability - that they will be responsible for it next month, next year and into the future. Therefore they have a reason to look after the area, to improve it, to help the business benefit from it.

The area of responsibility is largely implied by the purpose of the team and benefits the team are entrusted to deliver. Together purpose and responsibility allow teams to have pride, to derive pleasure and self-respect from their work.

Teams may have more than one area of responsibility. The greater the similarities between the areas the more effectively this will work. Imagine our accounts payable Java Oracle SQL team. The same team may hold responsibility for the fixed assets part of the system too. It is going to be a lot easier to maintain this responsibility if fixed assets is also implemented in Java and Oracle SQL.

The greater the variance in technologies, differences in business domains and variety of users the greater the difficulty in keeping multiple responsibilities in the same team. This is a particular consideration when teams need to shrink.

14. Strategic sizing

Obviously if a team is to be stable people are not going to be regularly looking at work arising and saying “How long will this take? How many people do we need?”. Rather they will be deciding is work arising is beneficial, directing it to the appropriate team and balancing priorities within that team.

And since each team will have its own areas of specialisation and responsibility there are going to be few questions about moving work between teams to balance the load. Occasional personnel moves are normal and should be expected, but when frequent team changes are disruptive and destroy capacity.

Indeed, since the teams will have their own areas and will have analysts and other requirements people in the teams they may well be identifying and generating their own work to produce business benefit.

So, given all of this, how is an organization to decide how many people to put in each team?

How are they to know when to expand teams?

And known when to shrink or merge teams?

The aim, for the sake of stable teams, is to get away from a position which so many software managers find themselves in: the constant, ongoing discussion of who’s on which team or project.

It sometimes seems that software managers only have one lever with which to control work: team resources. One team is slow so they pull the lever and someone moves from another team to the slow one. In so doing they sow the seeds of the next crisis when the same lever will be used again.

The answer lies in moving away from the piecework approach of constantly looking at incoming work, estimating the size and assigning individuals and teams to undertake the work. As discussed in Xanpan volume 1 this approach is fundamentally flawed because humans are very bad at estimating work.

Estimating the work without reference to who will do it is akin asking “How long will it take to get from London to New York?” and being told “It is 5500km between London and New York” without reference to the mode of transport. Estimates are inherently tired to who (which team) undertakes the work and to have any hope of accuracy requires knowledge of past performance. Even then accuracy is far from guaranteed.

Rather than work on a piecework/estimation basis teams need to be staffed strategically by reference to the value their product holds to the wider business and their past record of delivery. Thus the team are tied to the business they serve.

Should the company in our earlier example determine that the accounts payable system lacks business value they should act to reduce the capacity (and therefore costs) of the team. Similarly if they determine that the online retail system is the source of growth and therefore valuable then it makes sense to increase staffing in this area. Such decisions may mean that it takes longer to get changes to accounts payable but so be it, that is the strategy. It would be foolish to limit the online system if this is where the business sees growth.

Strategic staffing aligns with stability because strategy, like teams, should be stable over more than the short run. Good strategies should last years, if they do not they are not really strategy - or at least, not good strategies.

However looking at the value to the business is not the whole story. Organizations should also examine the benefits delivered by a team and the potential benefit in so far as it can be seen. Partly this is good governance, if a team repeatedly fails to deliver benefit they see then something needs to be fixed.

At a strategic level it is one thing to say the organization should invest in an area but another to actually perform well in that area. To continue the example, deciding to invest in online retail and growing the team does not itself guarantee success. The team may find that while they can deliver software competitors are stealing customers and the anticipated benefits are not being achieved.

Competitors, the market, customers and many other factors mean that realising desired strategies can be hard work. On occasions it makes sense to reverse course or change strategy. Only by executing is it possible to determine such factors. On paper all plans look possible.

15. Conclusion

Teams are the unit of production, organizations should allocate their people to teams according to strategic priorities and aim to keep both stable over the longer term.

Constantly micro-managing teams to match resources to goals is counter productive. Changing team members, forming new teams, disbanding existing teams and changing goals not only reduces productive capacity but job workers of the continuity needed to foster responsibility, sense of purpose and pride.

Achieving quality, responsiveness and flexibility - what might be called agile - comes not from constant changes to teams but from stable teams. These changes make for more management work - as they rebalance the teams - but this work is superficial.

Setting strategy, setting teams to match strategy and staying the course requires less management but deeper management. Less knee-jerk changes and more strategic thinking.

16. References

Brooks, F. 1975. The Mythical Man Month: Essays on Software Engineering. Addison-Wesley.

Inamori, K. 2013. Amoeba Management. CRC Press - Taylor Francis Group.

Tuckman, B. 1965. “Developmental Sequence in Small Groups.” Psychological Bulletin 63 (6): 384–99. doi:10.1037/h0022100.