III Nature of the team

Teams are the means of production. Teams create value. Organizations are made up of teams. The team are the capability to do work.

A team is like sausage machine, work requests go in, working software - or whatever it is you are building - comes out. Put in pork request you get pork sausages, put in chicken requests and you get chicken sausages¹, put in horse meet and… well who knows!

The aim of the team is to be productive and to increase their productive capacity over time. The team work on products, they may be responsible for more than one product and therefore work on more than one code base.

The team is stable and productive. Work flows to the team. The team sits at the centre of their own little universe, that might make some people uncomfortable but since the teams are the means of production it is inevitable.

Thus the question for management, and the requirements specialists, is: what should the team be working on?

There are different ways to answer this question. One might choose to answer it from an efficiency point of view: “The team should be working to maximise their output and utilisation.”

One might answer it from a value point of view: “The team should maximise the value they deliver.”

One might answer it from a risk point of view: “The team should be working on the items of highest risk” - which, since profit is the return for risk, might also be profit point of view: “The team should be working on the most profitable items.”

One might even answer it from a political point of view: “The team should be working on the highest profile work.” Or as Tom Gilb likes to say “Work on the juicy bits first.”

How the question is answered depends on the priorities of the organization. The organisation is free to choose how it wants to answer the question. Unfortunately it is also free to change its answer. Sticking with an answer, at least for a few months, is more likely to produce the desired result.

17. Work flows to the team

Teams have areas of responsibility, whether that be business domain or a set of software products - ideally it would be a set of software products grouped around a common business domain. These products generate work - because people want changes. And the business domain generates work - because business is in a constant state of flux.

When work arises it is directed to the team. Where there are several teams the work is directed to the most appropriate team.

Some of this work may be small, some might be large. Some might be simple requests and some might be great big bundles of work or “projects.”

This approach follows the Work Flows Inward pattern described in Organizational Patterns of Agile Software Development (Coplien and Harrison 2004).

The great management debate about “who will work on” a request is removed. Such debate is not a productive use of managers time anyway, using a team centric view managers might decide who is on a team but they need not have micro conversations about who will undertake a piece of work or when an individual will work on it. Discussions about whether Bill or Jim should work on something are gone because Bill, and Jim, work within teams. Work is directed to a team and not to an individual.

The team are the means of product. The team represent at the capability to do the work. As long as an organization does business in a particular area using a particular set of products then the team exists to service those products.

Generally it should be clear which team will work on any given request. There may be an occasional discussion about whether one team or another should undertake a particular request but these discussions happen at the team leave.

Internally the team might debate who is going to do a particular piece or work, or they might not, they might just have the next available person work on it when it rises to the top of the priority queue.

The company may decide to run down the use of the products and therefore reduce the size of the team, or it may decide to enhance those product further and that would require expand the team.

18. Vertical teams

Teams are staffed in vertically, that is to say the team contains all the skills needed to do a piece of work across the entire software stack or architecture.

In the past many teams have been organised along functional, or horizontal, lines:

The problem here is that getting a piece of work done requires co-ordination between all the layers. Different teams were responsible for different functional items and getting anything the business would recognise delivered required each team doing its bit. And that might mean lots of co-ordination and even persuasion.

In a horizontal model delivery occurs at the pace of the slowest team. No matter how fast the other teams perform until the work of the slowest team is completed there is nothing that to be delivered. If a customer comes to ask “why is this late?” each team can point at the other teams. Such a situations does not generate responsibility and it is hard to hold anyone to account - except perhaps the person with the thankless task of co-ordinating all the different teams.

Because work must be passed from team to team, layer to layer, there are multiple hand-offs, each hand-off requires communication with adds to cost, takes time, which slows things down, and poses a potential risk - the hand-off misses, information is lost and so on. With each hand-off the distance to the end customer increases and responsibility is lost.

A vertical team works on complete items, things which are recognisable and valuable for the business. One team is responsible, one team accountable, and one team can take the glory. If work is delayed there then one team is talk to, and there is little need to co-ordinate the work of multiple teams. Each team is free to work as fast as it likes.

There may be hand-offs within the team but the team can work to minimise these, and since the work is within the team communication and risk are reduced.

This requires teams to be staffed with all the skills they need and the authority to use those skills. Even when team members are new to a skill set, or there are better people in other teams, the team take responsibility and does the work.

19. Only software?

In the context of software a vertical team probably makes one think: Java coders, front end developers (HTML, CSS, JavaScript perhaps), product specialists (a product manager or business analysts perhaps), testers, database SQL skills or similar. Indeed there are many vertical software teams staffed according to this model.

But this might not be the limit of the team. If the team delivers value then delivered completed software products might not be the end.

Technical operations, the capability to deploy software in the cloud, to monitor its use and so on would allow the team to measure the benefit delivered directly in terms of the service they are delivering. Including such skills the the basis of DevOps.

Teams could go further: the team might include outbound marketeers to tell people about the software service they are delivering. The team might include customer service staff to help with customer problems.

In fact the software engineers might be a small part of a much bigger business team or even business unit.

20. Deciding what to work on

Given all the request that might reach a team the question arises: how does the team know what to work on?

When work comes from multiple sources to a team it is critical that the team has a clear way of deciding what will be worked on next. Even if the prioritisation process is unclear or erratic some priority call still needs to be made, it is more important that prioritisation is how it is done.

Basically there are two ways in which the actual work gets decided: the team are told what the priority is (an external command) or the team are trusted to do what is needed (an internal decision.)

My preference is to endowed the team with the authority to make the decision internally. This power may well be vested in one, named, individual. Such a person might go by the title Team Leader, or Product Owner or Manager.

Alternatively the team might decide collectively what to work on. Even here there may be a role for a product specialist with the skills to identify the highest value items and evaluate the results.

When the power to make the decision is vested inside the team the team, or at least individuals, will need to explain their decisions. Putting the power to decide inside the team means that the team can be asked to justify their decisions - perhaps for governance. Specifically teams should be able to justify decisions not to work on something or to delay work on something so that a another piece of work (a higher priority) can be undertaken.

Over time teams will understand their own capacity to do work. As a result they may find their capacity is not enough, they may add more capacity (capacity) or they may need to refuse work.

The important thing is: work potentially arrives at the team from multiple sources and some prioritisation - and thus scheduling - happens within the team. If the team does not have an clear process for doing this, and do not communicate this well both inside and outside the team, then there will be confusion over what the team is working on.

Alternatively the decision over what the team are working on may be made externally to the team. While in theory the person making this decision could have access to all the same information about the team - capacity, requests, etc. - if this person is not part of the team then they will have less information.

Now if such a person works so closely with the team that they have equivalent information then they are probably by default, a member of the team even if they are not a named a team member.

But when such decisions are made externally to the team they are often made with less information than the team have. That can lead to problems, work can be incorrectly assigned or teams overloaded with requests. When people feel unfairly treated their productivity may suffer.

And making such decisions externally to the team, with little team input, is likely to be demotivating for the team. Some of the responsibility and authority have been removed from the team. Team members may be less inclined to work beyond the letter of the request and their employment contract.

21. Value seeking teams

The team control the means of product. Prioritisation is within the team. The team is the unit of delivery, the work the comes out of the team should be valuable to the team’s customers, “the business”. Therefore teams need to be constantly seeking valuable work to do, and ideally the team are undertaking the most valuable work and not undertaking low value work.

In some domains “past performance does is not an indicator of future performance”. In software development recent past performance is a pretty good indicator of (near term) future performance.

When a team is value seeking - and has the capability to seek and deliver that value - then management and governance of the team should be based on the value actually delivered. Specifically the value that the team expects to deliver and the confidence that the team will deliver based on past performance.

In other words, governance of the team needs to look at:

• The value the team has delivered in the recent past: if a team has a poor record of recent deliveries than it is questionable whether the team should continue as is or be repurposed.
• The value the team propose to deliver in the near term, and some idea of where the team expect to find value in the longer term.
• Whether the recent track record of deliveries gives confidence that the forward looking suggestions are deliverable.

22. Discovery and delivery

In order to work effectively value seeking teams need to have skills of discovery and delivery. The teams needs to capability to look at the customer, potential customer, customer problems and the wider market or organisation; the team needs the skills to analyse these source and see where value could be added; the team also needs the skills to understand technology, and especially the newest technologies which allow new classes of customer problems and opportunities to be addressed. Finally, the team needs the skills to deliver on these opportunities. It should be obviously that the ability to think both tactically and strategically as appropriate is also needed.

A few individuals possess all these skills, but only a few. More likely a team would be staffed with multiple people who have more specialisation, while some individuals may undertake multiple roles and activities some will be specialists. For example, the team may include a product manager skilled in identifying market segments and understanding what potential customers want; the product manager may have coding experience, and maybe at crunch times might pair with programmers, but it is not the most effective use of their time to spend a lot of time coding.

Conversely, a programmer may well spend most of their time programming and while they could get on a plane and visit a customer occasionally it is not an effective use of their time to do so on a regular basis. Certainly it is good for programmers to meet customers from time to time but having them meet customers on a regular basis (particularly in product development endeavours) is not a productive use of their times or skills.

In order to seek and deliver value teams need both discovery and delivery skills. The mix of these skills will vary from team to team and place to place. However, whatever the mix there is one team, one team wins or looses together, the whole team crosses the finish line together.

23. Defining value, and benefit

Value seeking teams need to define what constitutes value. And they need to explain to their stakeholder(s), specifically those who govern the team, what this value is.

What constitutes value is an open question but one all value seeking teams need to address. For a start-up the simplest form of value is revenue, money paid by customers. Money allows the start-up to survive and perhaps grow but money is also information: the flow of purchases tells the team that customers consider their product valuable and that customers are prepared to trade their hard earned cash for the product. Information has value too although it may not be measured directly, or even soon, in terms of cash.

In a start-up company, the whole company is the team and by definition the team is value seeking. The start-up seeks to deliver value so that it may continue to play the game. If the team cannot deliver value - either because they cannot deliver or they deliver something with no value - then, through the power of market economics, the company will eventually fail and go out of business.

Outside of a start-up world questions of value become more complicated because there are other players, other considerations and multiple values. This is especially true in a corporate environment.

Consider for example a large international bank. Some of these banks employ tens of thousands of people inside the IT function alone. For a team buried inside the IT department of a bank determining value may be no simple question. The team may be many steps away from actual customers, instead they provide services to internal “stakeholders.” These stakeholders may have competing needs and varying levels of influence. Inside a large organization the tyranny of numbers means the difference a single team can make to the overall organization, and annual report, may be negligible.

In the corporate IT world it can be hard for a team to define value and more difficult still for teams to deliver enough value to have a discernible difference to the financial position of the company. (Conversely it is relatively easy for an IT endeavour to make a noticeable detrimental impact on a company’s position.)

Indeed while it is common to talk of value it is perhaps more correct to talk of benefit. Value implies cold hard, measurable, numbers, while benefit is a more inclusive description. The benefit a team may bring can be multiple sources:

• Increased revenue leading to higher profit
• Reduced cost leading to higher profit
• Increased understanding leading to reduced risk or new products
• Learning leading to better customer understanding which may make an immediate different to finances or may play out over years
• Learning which informs decisions which results in fewer mistakes, or bad decisions which in turn leads to improved financial results
• Better quality products which create happier customers, and which may after a delay lead to additional purchases and profits

In large organizations it can be incredibly difficult to see how the actions of one team make a difference. And since teams serve many different stakeholders it is possible that increased benefits to one stakeholder means reduced benefits elsewhere.

All this means it is essential that teams define what value and benefit mean to the team.

If the team can quantify this benefit with numbers good but quantification can cause its only problems. Consider the pursuit of shareholder value than lead to the Enron and Worldcom collapses at the start of the millennium. Or consider the financial engineering and “off balance sheet” stratagems that resulted in the collapse of Lehman Brothers, Royal Bank of Scotland and much of the financial sector during 2007-2009.

According to some authors (e.g. Admati and Hellwig 2014) the pursuit of ever for higher earnings per share which leads banks to dubious financial engineering which makes banks vulnerable to financial crisis. Pursuit of these numbers creates behaviours which impose risks on costs on entire societies. ing risk to entire economies.

Quantification can be useful but it can also lead in false directions. All quantification has to be tempered with qualification and understanding. Value seeking teams need to be able to modify the value they seek over time.

Finally, time needs to be consider.

Not only does value change over time, not only do short term value creation sometimes detract from long run value creation but it can be difficult to measure changes over short periods. Consider for example the billions invested globally in IT during the 1960s, 1970, 1980s and into the 1990s. When examined by economists it proved very difficult to see any added value during this time. (See Brynjolfsson and Saunders 2009 for a full discussion.)

24. References

Admati, A., and M. Hellwig. 2014. The Bankers New Clothes. Princeton University Press.

Brynjolfsson, E., and A. Saunders. 2009. Wired for Innovation. MIT Press.

Coplien, J. O., and N. B. Harrison. 2004. Organizational Patterns of Agile Software Development. Upper Saddle River, NJ: Pearson Prentice Hall.