The second page of the Agile Manifesto⁴⁶ lists the 12 ‘Principles behind the Agile Manifesto’. Each principle stands alone as good advice, and together they show how the values on the first page can be applied.

Although several include the word ‘software’, there is little that is unique to software teams. The principles describe the behaviours and mindset that allow any project or product development to succeed.

It is common for people new to Agile to skip past the principles, particularly when their first introduction to Agile is learning an Agile framework or method. However, the principles so comprehensively address the essence of an Agile mindset that they deserve far greater attention and consideration.

This chapter will help you understand the principles. It will explain:

• What each principle is really about.
• What you can do to reinforce each principle.
• How to identify some of the traps and anti-patterns that can distract you from each principle.

THE 12 PRINCIPLES BEHIND THE AGILE MANIFESTO

Like much with Agile, the principles seem simple and common sense, but they are difficult to apply in practice and challenging to master completely. They are not presented with any narrative or explanation, which means that each person will apply their personal spin to them. Unfortunately, this can lead to differing understanding of what they mean, and differing implementations of them. In our experience, even where the principles are considered, it is common to pick principles, or aspects of principles, that suit and ignore the rest.

This ambiguity over what the principles mean can lead to confusion. In the following sections, we share our understanding of their meaning and what makes them powerful, based on our experience over many years of applying them with various teams.

When the principles were first published in 2001, they were split into three sections based on who they were ‘slanted towards’: customers, managers or the team. Although they are no longer described as such, we think it is still a useful way to present them.

PRINCIPLES SLANTED TOWARDS CUSTOMERS

Figure 5.1 lists the four principles relating to customers and we discuss each one in detail below.

Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

This principle really sums up the Agile approach with several key words and phrases:

• Early … delivery – The sooner we can deliver something of value the better. This requires early feedback that provides confidence that we are heading in the right direction.
• Continuous delivery – Delivery is continuous. During the life cycle of the product or delivery, there will be lots of versions of the solution, not just one or two.
• Valuable – The thing we continuously deliver (and it doesn’t need to be software) must be valuable. This means we need to know and be able to express why it is valuable. Often this means it must be able to be used in a real situation by the customer, but this isn’t always possible (for example with some hardware products or where data aren’t available). Another source of value is knowledge or learning. Sometimes the value is in proving a concept, running an experiment or learning something.
• Satisfy the customer – The person we need to satisfy is the customer. That means their views on value are most important; not the team’s, not the testers’, not the project manager’s.

Taken together, this is a powerful principle and Agile teams will demonstrate all elements of it. This is where it becomes challenging. Traditional development approaches tend not to favour continuous delivery and often don’t provide value to the customer until near the end of the delivery.

To reinforce this principle, consider the following things:

• Can you describe what value is being delivered in each iteration of your product?
• Is the value in this iteration valuable to the customer? If not, why not? Why should they care about this iteration?
• How quickly can you get a version of your solution deployed that your customer finds valuable? Why not faster?
• How frequently can you add value with new releases or iterations? Why not faster?

Watch out for the traps and anti-patterns given in Table 5.1 that can divert your focus from this principle.

Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage

The most challenging word for most people in this principle is ‘Welcome’. We are not conditioned to welcome change. On the contrary, most alternative approaches and much of human nature seeks to minimise change. However, that is also the power of this principle. When we expect and welcome change, we are quicker to spot it, quicker to respond to it and quicker to reach new stability. The second sentence explains why: by doing this, we can be more competitive.

The second challenging aspect of this principle is also in the first sentence: we welcome change ‘even late in development’. Again, this isn’t natural. It is common for teams to push on with the original plans, particularly the closer we get to the finish line. We are conditioned to changes being a sign of weakness – a ‘U-turn’, an ‘exception’. A change late in development could threaten the viability of the whole endeavour and cause promises we have made to be broken. Of course, that’s exactly why this is important; when things change we ought to respond as quickly as we can or we risk not delivering the maximum value to our customers. Most traditional approaches inhibit change by making it difficult, time-consuming and expensive to respond to. This makes it easier to ignore and press on with the original plan. Agile teams that welcome and expect change are always accepting of it. Many of the other principles explain how we do this.

This flexibility doesn’t mean that we can’t have a clear vision, plans and roadmaps. It just means that we should expect them to change, and to welcome that change when it happens. And because we expect them to change, we should put as little effort into them as we can – just enough to make them valuable.

To reinforce this principle, consider the following things:

• Where do you expect change to come from? How will you know it is happening? Monitor these sources and keep your eyes open.
• What were the drivers for the work being started? Are these still true? Is the strategy still the same? Have market conditions changed? Are there any new competitors or customers?
• Use short iterations. Make short-term commitments. Avoid promising details months ahead.
• Keep backlogs short and high-level; go into detail only when you need to.

Watch out for the traps and anti-patterns given in Table 5.2 that can divert your focus from this principle.

Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

The principles reinforce one another and emphasise important points several times. This principle is an example – it focuses again on early and frequent delivery of a working solution. As we discussed in Chapter 4, the word ‘working’ is important here because a solution isn’t working for the customer if they can’t use it to solve some problem for them. It doesn’t have to solve their entire problem, but it does need to solve some part of it.

The second part of the sentence makes it even clearer: not only should we deliver frequently, but we should also aim to release new working versions of our solution every couple of weeks and no longer than every couple of months. The more frequently we have customers using our solution, the more feedback we get and the more we learn about the problem and the solution. Each opportunity for feedback is an opportunity to reduce risk and increase our understanding. The earlier we start this process, the better.

This might sound extreme or implausible for some teams, but it’s not. It just requires us to think differently about what constitutes value and how we organise our backlog. We discuss techniques for this in Chapter 10.

To reinforce this principle, consider the following things:

• Set short iterations.
• Split big goals into smaller goals, not into big plans. Check that the smaller goals deliver independent value. Could you stop after this goal and still have a valuable product?
• Are manual processes slowing you down? Invest in automation and continuous delivery tools to make releasing easier.
• Help your customers to understand why you want to work this way, perhaps with training or coaching.
• Do you know what ‘working’ means in your context?
• Does each iteration have a customer-centric goal?

Watch out for the traps and anti-patterns given in Table 5.3 that can divert your focus from this principle.

Principle 4: Business people and developers must work together daily throughout the project

For such a simple statement, it is surprisingly rare to see teams do this; yet it is such an important factor, as emphasised by the word ‘must’. Working together is not optional.

The theory is simple: when we make it easy to ask questions, get feedback and clarify language, then communication improves. When we need information, we can access it quickly. We stop relying on formal meetings or reports for updates because everyone knows what’s going on or can find out quickly. We spot mistakes quicker and make decisions quicker.

This increased collaboration helps to build stronger relationships and creates psychological safety in our teams. Psychological safety is one of the most critical things required to build high-performing teams, as we discuss in Chapter 9.

The easiest way to achieve this principle is for the team, their customers and the important business stakeholders to work in the same room. But that’s not the only way – with remote or geographically distributed teams, we can always find ways to work better together and to achieve the same benefits. Working together reduces the need to communicate in more formal ways. It can reduce the amount of detail needed in digital tools and the amount of information we need to collate in advance, ‘just in case we need it’. By creating an environment where we can overhear conversations between others, we increase our general awareness of the product and are able to contribute when we have something to add. This builds consistency in our ‘tacit knowledge’⁴⁷ – the things that we implicitly know but would find difficult to write down or describe.

The word ‘daily’ is an interesting one in this principle. We aim for short cycles and frequent releases, so it follows that there should usually be something to talk about each day. This means the word serves two purposes:

• Business people and developers should be available every day to talk about the work.
• If there’s nothing to talk about, perhaps this is a sign that the work is the wrong shape; perhaps too much detail is agreed up front, or the increments of work are too big.

To reinforce this principle, consider the following things:

• If you can co-locate the team and their business stakeholders, then do that. If you can’t, could you co-locate some of the people, or for some of the time?
• How easy is it for the team and their business stakeholders to talk? Help them get to know each other early in the project and create frequent opportunities for them to talk. Choose meeting times and locations to maximise attendance and adapt these if you need to.
• Use digital channels such as Slack or Teams and invite business people and developers to the groups.
• Don’t allow significant detail to be stored in requirements or stories. Leave them high level and vague to force clarifying conversations to happen once the team starts work on them. A definition of ready (DoR)⁴⁸ can help.
• How transparent are you? Can your stakeholders see the same information as the team? If not, why not? Try to encourage your stakeholders to look at the team’s information and interact with it.

Watch out for the traps and anti-patterns given in Table 5.4 that can divert your focus from this principle.

PRINCIPLES SLANTED TOWARDS MANAGERS

Figure 5.2 lists the four principles relating to managers and we discuss each one in detail below.

Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done

This principle captures what is required of management and leadership in Agile teams and organisations. We cover Agile leadership in detail in Chapter 9. Much of the advice and guidance there will directly reinforce this principle.

It can seem this is about autonomy – removing management and letting the team get on with it – but there is a lot more going on here, and a lot more to Agile leadership than just empowering the team. Let’s start with building projects around ‘motivated individuals’. This sounds simple, but it isn’t. Not every individual in the team will be motivated in the same way, nor be demotivated by the same things. Motivation is not static, and individuals can become more or less motivated all the time. As we explore in detail in Chapter 9, the science and psychology of motivation and leadership is evolving, and much of the current theory aligns very well with the Agile values and principles.

To create and sustain motivated individuals, the environment and support around them must reinforce the Agile values and principles and remove factors that promote the wrong behaviours. That’s exactly what this chapter and Chapter 4 will help you do.

We tend to think of ‘support’ as being things like training budget, development opportunities or mentoring and coaching. These things are important, but support is also about helping align the team with the organisational vision and strategy, identifying and mitigating external pressures on the team and creating opportunities for feedback and improvement.

One area that can cause problems with this principle is management processes. Real world Agile teams often exist within a larger organisation. They are required to follow management and governance processes that are rarely well suited to an Agile environment. Such an environment can impact individual motivation and impair team performance. Some examples are annualised processes, individual-focused reward (especially where employees are pitched against one another for bonuses) and a culture of fearing feedback because it only comes during appraisals.

This is why Agile principles and values are not just for software teams. HR, finance, procurement and other functions must also change if an organisation is to become truly Agile. There are many opportunities to do that. We discuss some in Chapter 9 (expense policies for instance), but by applying a principles lens to management processes, we have found many other examples.

The final directive in this principle – ‘trust’ – is also easy to erode with poor management or leadership. Agile team members need to trust one another and have the trust of their stakeholders. Creating this trust can be hard because many organisations and processes assume the opposite – they assume people cannot be trusted. This means their processes and culture can inhibit the creation of trust, for instance multiple oversight or approvals processes or detailed tasking and micromanagement.

Agile organisations assume people are acting with noble intent. We assume people and teams can be trusted and do not need high levels of oversight and control. We use high levels of transparency and frequent feedback to prevent the kinds of misdemeanours or poor performance that require formal intervention from arising in the first place. For example, the focus on frequent feedback and continuous improvement means that Agile teams will often identify problems within their team themselves. If someone is beginning to struggle, the team will realise and can provide additional support, training or refactoring of the work. This can happen immediately and be revised frequently without waiting for a HR process to trigger an assessment.

Agile processes are designed for exceptions, and we only deploy them when those exceptions occur. There will still be processes to manage underperformance that can result in dismissal, but they are invoked only when necessary, not built into the processes used by the majority of good performers.

To reinforce this principle, consider the following things:

• What can the team make decisions about? What can’t they? Is everything out of their control reasonable? Even if they don’t have absolute control, could they be more involved in the decision making?
• Do they understand the purpose of their work? Autonomy requires connecting the team with its purpose (see Chapter 9).
• Do you involve (or invite) everyone in strategic decision making and setting strategic direction? If not, why not?
• Assume people are acting with noble intent (unless proven otherwise).
• Don’t micromanage; encourage curiosity, asking questions and seeking advice. Encourage teams and individuals to ask for help when they need it. Listen more than you speak.
• Allow teams to work on challenging problems. Help them to increase the challenge as their skill improves, perhaps by adjusting the size and complexity of the stories.
• Use coaching to help the team develop and grow. This can be with dedicated Agile coaches, by using coaching skills in existing management processes, or both.
• Keep the faith. Things will go wrong; expect that to happen. Inspect and adapt to continually improve. It will be tempting to revert to a more command and control management style, so try to resist.

Watch out for the traps and anti-patterns given in Table 5.5 that can divert your focus from this principle.

Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

This is another principle about how people interact. Face-to-face conversations, particularly when they take place just when the information is needed, will be up to date and can reduce the ambiguity that might arise from written exchanges or voice-only calls.

When we use written means to communicate there is a lag between the information being written and it being read, meaning it may be out of date. There is also more opportunity for confusion and misunderstanding.

Face-to-face communication can be harder as it causes interruptions and breaks the flow of concentration when you are working on specific tasks. Lack of availability of the people you need to talk to can also introduce delays and can lead to single points of failure. However, we can look at these disadvantages as opportunities to operate in a more Agile way. For example:

• Interruptions can cause breaks in concentration when working on specific tasks. An Agile team should strive to work together on the most valuable stories, thereby creating an environment for collaboration. This should not be seen as interruption.
• Sometimes too many interruptions can be caused by there being too many people in the team. This could be an indication that the work should be split into smaller independent and autonomous teams.

Key individuals may not be available when they are needed. An Agile team encourages co-location of a team (physically or digitally), and key individuals should be part of that team. When this occurs, conversations are more ad hoc and frequent, so scheduling time to get answers to key questions shouldn’t be a problem. When we are used to regular collaboration and communication with the team, each conversation will be shorter, since they happen more frequently, and we know we can go back for clarification if we need to. Also, the impact of key individuals is limited when teams are working together on the same stories. There is likely to be more than one person who can answer the question. Similarly, when we work directly with the users (rather than through a proxy), there is often more than one person we can ask.

The point of this principle is that development benefits from face-to-face communication. It doesn’t mean that written communications are not also valuable, it just acknowledges that when we want to convey many types of information, face-to-face communication is better. However, there must be clear guidance on what does need to be documented and what does not. For example, technical constraints, system-wide non-functional requirements, anything contractual, changes to service level agreements and so on will probably need to be documented. Clarification on the detail of a story, opinions on a user interface (UI) layout or agreeing the agenda for a service launch probably won’t.

To reinforce this principle, consider the following things:

• Are the team used to talking to one another? If not, work on building trust and psychological safety in the team.
• How will you know who to talk to? Build a network among the stakeholders and customers. Get to know who you can talk to for particular topics.
• Consider accessibility, for example technology assistance (such as live subtitling in video conferencing software) can help with some disabilities. Not everyone prefers face-to-face conversation, so create adjustments if necessary.
• When you are not co-located, consider using video and phone calls in preference to email and messages.
• Create opportunities for ad hoc conversations to happen.
• Encourage sharing of knowledge to remove single points of failure. One good way to do this is to work together more in pairs or groups.
• If you must have reviews or approvals, try to have them in person rather than comments on a document.

Watch out for the traps and anti-patterns given in Table 5.6 that can divert your focus from this principle.

Principle 7: Working software is the primary measure of progress

This principle seems obvious, but like much in Agile it is not followed (or followed well) often enough. All too often teams measure progress by time elapsed, money spent or arbitrary milestones passed. While these things may be interesting, they are not good measures of progress towards our goal. A better measure is the extent to which we are confident our solution is meeting the needs of our customer, and the best way to do that is to let them use it and provide feedback.

As we discussed in Chapter 4, working software means that the solution (and it might not be a software solution) is performing the job it was intended to. It is helping customers with their real-life problems and their real-life data. It isn’t working if it is in a reference environment, operating on dummy data, demonstrated by the development team or an idea on paper.

Only when a customer can use the product for real – even if it just meets a tiny slice of their overall needs – can they provide feedback on whether it is working for them. Only with this feedback can we have a genuine indication of progress. We refer to this as ‘value in use’, as it is only by using it that the customer can say whether it is valuable.

In Chapter 8 we discuss how Agile teams measure success, and why leading measures are better indicators than lagging measures. Working software, and the feedback it brings, is an ideal leading measure as it builds confidence that the goal will be met. Time and cost are lagging measures, as they can only be measured after they have occurred and are not good indicators that you will meet the goal.

To reinforce this principle, consider the following things:

• Do you have a clear understanding of what ‘working software’ means for your product? Does your customer agree?
• Are you being asked for other measures of progress? Have you challenged this?
• Do your iteration goals represent something of value to your customer? Could they use it for ‘work’? Ensure you set iteration goals that are small slices of real value to the user (see Chapter 10).
• Set acceptance criteria that ensure the goal is met (or the story complete) and is being used in a real scenario.
• Describe progress in terms of customer value, rather than in terms of percentage complete or tasks finished. Try adding ‘so that’ to the end of tasks when describing them; for example: ‘Check Balance on mobile app so that customers can see their points balance while in the store and decide whether to redeem points.’
• Use DevOps practices and deploy stories to production as soon as they are complete.

Watch out for the traps and anti-patterns given in Table 5.7 that can divert your focus from this principle.

Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely

The word ‘sustainable’ here means that the team should be able to sustain the pace. Today, sustainability is often assumed to mean sustainable from an environmental perspective. This is also very important for teams to consider, but is not the point of this principle. Certain things can achieve both, such as automation.

One of the benefits of traditional, linear development is that it can be relatively calm for most of the delivery. Often, it isn’t until the end that stress levels rise, deadlines get closer and testing throws up problems that require urgent attention. Customers and other stakeholders are generally quite happy during the early stages, content to trust the Gantt chart and believe the final product will meet all their needs – only to find that features get descoped to meet deadlines, costs start to rise and expected release dates get further away. This is not the pattern in Agile teams. With each increment of the product ideally being used by customers, teams can feel the stress and urgency to get a working version ready every single iteration. It can all feel a bit relentless, and that’s why this principle is so important.

Because Agile teams work in frequent, short cycles, it is critical that they don’t burn themselves out. If every week is release week, we mustn’t spend every release week working until midnight to get the release out. The team needs to find a pace that suits them and that they could continue with indefinitely. It needs to accommodate taking leave, personal and professional development, and any corporate processes. While there may be times when additional effort is called for, this should be the exception rather than the norm.

For large pieces of work that may run for many months, or even years, it is important to ensure the work doesn’t become monotonous. Using short- to medium-term product goals or releases can provide opportunities to reflect on progress and celebrate the team’s accomplishments even though the work is not yet finished.

To reinforce this principle, consider the following things:

• How is your team feeling? Do you know if anyone is struggling? How would you know? Good psychological safety and approaches such as daily Check-In Core Protocol⁵³ can help, or consider using part of a daily stand-up as a mental health check-in.
• Set clear, achievable goals for your iteration. We cover prioritising and setting goals in Chapters 8 and 10.
• Account for other essential activities (such as training, corporate meetings, annual leave, etc.) when planning iterations.
• Use release planning and longer-term goals to set direction and manage expectations.

Watch out for the traps and anti-patterns given in Table 5.8 that can divert your focus from this principle.

PRINCIPLES SLANTED TOWARDS THE TEAM

Figure 5.3 lists the four principles relating to the team and we discuss each one in detail below.

Principle 9: Continuous attention to technical excellence and good design enhances agility

A common criticism of Agile teams is that their focus on short timeframes leads to sloppy implementations, short-cuts and poor-quality solutions. Teams start implementing straight away without thinking about design, and the result is a mess. This principle states that if this were happening, those teams would not be Agile at all.

Technical excellence and good design are not just ‘nice to have’, they are essential enablers for incremental and iterative delivery and of being Agile. It is a helpful first principle in this section. Together with the following two principles, this principle describes how and why Agile is not an excuse to hack together a solution without following good practice. Designing with change in mind, expecting to refactor and evolve both your solution and your design, and keeping the solution simple are all important considerations for any team, but they are especially important for Agile teams since these practices make it easier for them to be Agile.

The first word in this principle is important: ‘continuous’. It isn’t enough to have a design that you follow. To enhance agility, the design and technical excellence will evolve and change as the team learns more about the problem and solution, but ‘continuous’ also means they are present from the start. The team starts with a design and attention to technical excellence and expects them to change and evolve. Good design expects and enables change.

To reinforce this principle, consider the following things:

• Iterate your design. Do just enough at the start to know where to begin. Don’t be afraid to refactor. Just because you know the final product will include a database with a million records, doesn’t mean the first iteration needs it – perhaps a text file would be good enough?
• Don’t neglect non-functional requirements such as performance, security or accessibility. Design these in from the start, especially if they are challenging and failure to meet them would cause the product to fail.
• Include quality in your acceptance criteria or definitions of done. If you can, automate quality testing. For software products, this could be in your continuous integration/continuous deployment (CI/CD) pipeline.
• Automation, version control and loosely coupled architecture are examples of technical excellence practices that enhance agility.
• Minimise coupling with other systems or teams. The more interfaces that need to be agreed, the greater the impact if they need to change. Where you do need to agree interfaces, make them as simple and as generic as you can.

Watch out for the traps and anti-patterns given in Table 5.9 that can divert your focus from this principle.

Principle 10: Simplicity – the art of maximizing the amount of work not done – is essential

This rather clumsily worded principle is probably one of the most important, and one that describes the essence of what Agile is. It is applied in all aspects of Agile and should be the first consideration before any action:

• How can I make this as simple as possible?
• What can I do without and yet still ensure the delivery is valuable?

We also like to capture this principle with the phrase ‘just enough, just in time’.

This principle is the reason that Agile can claim to deliver quicker than traditional, linear approaches. It isn’t because Agile teams build the solution faster than non-Agile teams, it is because, by following this principle, Agile solutions do less, reduce waste caused by over-engineering solutions and don’t implement features that aren’t needed.

Traditional projects tend to build all the ‘must have’ requirements listed, even when those requirements are very large (feature sized) and contain many smaller stories. These smaller stories seldom carry the same priority. Some will turn out to be neither necessary nor a priority, yet will still be built. Agile deliveries only build the user stories needed. They do this by simplifying – delivering just what is essential in small usable increments of the solution iteratively. As customers use these early versions, they realise what they do and, more importantly, do not need.

This focus on simplicity isn’t just on the stories we include in our iteration, it is also about how complete we make the solution, how comprehensive we make our documentation or training, how we test to ensure the solution meets the customer needs and even how much time we spend meeting those needs. It isn’t about cutting corners or making compromises – it is about being ruthless about what is necessary and what is not.

To reinforce this principle, consider the following things:

• Always ask yourself and the team: Could this be simpler? What could we remove and still deliver the value?
• Use reviews and retrospectives to challenge each other and identify ways to simplify.
• Use techniques such as ‘Good-Better-Best’ or ‘story mapping’ (see Chapter 10) to simplify stories, goals or releases to deliver them earlier.
• Apply this principle to all aspects of work, including backlog generation, roadmaps, architecture, design, communications, reporting and documentation.

Watch out for the traps and anti-patterns given in Table 5.10 that can divert your focus from this principle.

Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams

This principle covers two important practices – emergent artefacts and self-organising teams – yet people tend to focus solely on the second. This is probably because it is easier to understand, although still difficult to master in practice. However, the notion that important artefacts such as architecture, user needs and design emerge from teams is arguably more important to the Agile mindset.

The word ‘emerge’ is an interesting choice. It implies something that is becoming known. It isn’t necessarily arriving fully formed, but emerging bit by bit. The word supports the previous ideas that architectures, user needs and designs are also things that are iterating, just as the overall product is. Furthermore, those artefacts are emerging from the team and their collaborations – they are not given to them or imposed on them. This is a really important point – the job of the team is to iteratively and incrementally develop architectures, design and their understanding of the customer needs. It is no accident that these three things are mentioned explicitly. They are all important aspects of successful product development and if they are neglected the value of the product to the customer can be severely compromised. They are also things that are hard to create accurately up front.

Much like the ‘technical excellence’ Principle 9, this principle reinforces that Agile teams need to consider all aspects of development. An Agile team is collectively responsible for all the work needed to achieve the working software. They don’t receive requirements from a requirements team, implement what the architects hand them or handover their work to a testing team. These patterns are common in a traditional, linear development project, but are not how Agile teams operate.

This brings us to the other part of this principle: self-organising teams. There are two elements to this.

Self-organising teams have all the skills, knowledge and authority necessary to create a product increment the customer can use

As we have just discussed, the team is collectively responsible for developing the architectures, user needs and designs. This means they need the right skills, training, tools and authority to be able to do that. The same is true for anything else that is required to create ‘working solutions’ – versions of the product that the customer can use to solve their real problems with real data.

Depending on their context, that may mean the team also needs to have some expertise in other areas, such as marketing, information security, policy, user training, technical writing, change management or a whole host of other areas. Even for software products, the development team need to know a lot more than just how to code. This creates a problem. Historically, many of these areas have been covered by specialist roles and jobs; many organisations are structured in ways that make these areas specialised, with specialist teams that are distanced from development teams, which can impede collaboration.

In a self-organising team there is no room for dedicated specialists. They create handoffs, with some of the team creating parts of the solution and others doing the rest. This adds waste, cost, risk and time. It also makes it hard for the team to always be concentrating on the most valuable work unless the most valuable work happens to match the specialist skills mix of the team. This isn’t how to adhere to the manifesto values and principles; and it isn’t being Agile.

We discuss this topic further in later chapters, including discussing situations where specialists can be required.

Self-organising teams are empowered to organise themselves

The second element to self-organising teams is the most obvious: they must be able to organise themselves. This isn’t as simple as it sounds and can be made even harder when the nature of the problem means that there is lots of specialist knowledge or skill required.

The primary goal of every Agile iteration is to maximise the amount of value to a customer within the iteration. To achieve this, we need everyone on the team to be contributing to that value. This can be tricky when there are specialists. After all, if I am a security architect and there isn’t much security work involved in this story, then what can I do? I usually have three choices:

• Find some other security work to do, perhaps on a story that might be prioritised in a later iteration or at a lower priority in this one.
• Go and do some work for a different team.
• Find some non-security tasks to do that will help the team deliver the highest priority story earlier.

The correct choice is obviously the last one, yet we frequently see people choose one of the other options; sometimes because of a misguided notion that they are not valuable unless applying their specialist skill, but sometimes because they don’t want to do other work or think it is beneath them.

Organising the team to focus on maximising the value they can deliver means that they must be motivated, competent and empowered to work that way, as shown in Figure 5.4 and discussed in Table 5.11.

Creating the conditions for intrinsic motivation and empowerment requires strong leadership, as we discuss more in Chapter 9.

To reinforce this principle, consider the following things:

• Can the team get the product live? Can they take it to a point where the customer can use it for their work? If not, what is missing? Is it people, skills, authority, business process?
• Can the product operate on the right data? Are real users available to use the product?
• Minimise external handoffs, reviews or approvals. If possible, bring the authority into the team.
• Create ‘T-shaped’ team members (see Chapter 7) where people augment primary skills with other skills, perhaps at a lower skill level. Only use dedicated specialists where you really need deep expertise and experience.
• Set goals for the team; let them work out how to meet them (see Chapter 9).
• Set expectations for supporting artefacts such as architecture, design and roadmaps and include them in acceptance criteria or definitions of done. Expect them to iterate and evolve.

Watch out for the traps and anti-patterns given in Table 5.12 that can divert your focus from this principle.

Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

This principle encapsulates perhaps the most widely recognised and powerful element of Agile, that of continuous improvement through reflection. It acknowledges that teams can always improve (adjust), and states that these reflections should be regular events.

The most common way that teams do this overtly is with a retrospective: a regular meeting where the team considers how it can improve and agrees actions to make changes to how they behave. This is the ‘inspection’ and ‘adaptation’ pillars in action. The term ‘retrospective’ originated around the same time as the Agile Manifesto, in Norm Kerth’s book, Project Retrospectives,⁵⁴ and a Sprint Retrospective is a critical part of the Scrum framework.⁵⁵ When teams diverge from other good Agile practices, they often retain retrospectives. Retrospectives are described in more detail in Chapter 7 and in the book Agile Retrospectives by Esther Derby and Diana Larsen.⁵⁶

Although seemingly simple, there are pitfalls that can make retrospectives less effective. They need honesty and trust within the team, a willingness to accept there will be ways the team can improve and a desire to make those changes. These elements can be affected in various ways, as discussed below.

Trust and honesty

We previously mentioned the importance of psychological safety to team performance, and it is particularly important when teams are trying to become more effective. In teams with good psychological safety, there is no blame culture and everyone acts with noble intent. Everyone in the team makes decisions that they honestly believe are the right ones given the information they have at that time. Often, we later realise that a different decision may have been better, but we are reaching that conclusion at a different point in time and with different information.

In a psychologically safe team, suggestions of things to do differently or ways to improve do not imply blame or that previous decisions were wrong. This is quite a difficult leap for some teams to take, particularly where there is a management culture that expects perfect performance and assumes that changing your mind is bad.

The primary value of retrospectives is to the team, so it should just be the team who participate and just the team who share the results. Don’t include additional stakeholders in a team retrospective, especially if any of them have a performance management relationship with the team.

Of course a retrospective doesn’t have to be a single event. We can have several retrospectives with different audiences, focusing on different things to improve. For example, conducting a retrospective with other teams you work with or with wider stakeholders can be a powerful way to improve.

For retrospectives to be useful, two aspects need to be embraced:

• Acceptance that we can improve. Even high-performing teams can improve, and this needs to be understood and accepted. Every change is an experiment; we think it will make us better, but we don’t really know until we try. Agile teams are constantly finding different things to try to see if they can improve.

  There are always changes that can be tried. In his book, Black Box Thinking,⁵⁷ Matthew Syed describes how small changes that result in marginal gains can amplify to help teams and organisations make radical leaps forward. The Japanese concept of kaizen, which means ‘change for the better’, also advocates small frequent changes and these concepts should be embraced by the team.

• Willingness and ability to make changes. Even with teams who can identify things to change, they still need the willingness and ability to make those changes. Very often, this will take some effort and must be factored into the other work of the team. The team’s stakeholders, leadership and management need to be committed to the team’s investment in themselves too, even if it impacts the product.

  Teams frequently identify great actions from their retrospectives, but consistently de-prioritise them and never find the time to make the change. These actions and problems then arise at future retrospectives and are a sign that teams are not investing in their continuous improvement. This may be because the problems are too big for the team to solve.

  Teams need to ensure proposed changes are realistic. A common trap is for teams to think broadly in their retrospective but over-emphasise problems beyond their control. Problems are easy to identify, but unless they can also identify realistic actions that they can achieve themselves, they won’t be able to enact any actual change. In this situation, the team needs to refocus their attention to identifying problems they can solve and find other ways to address their higher order issues.

To reinforce this principle, consider the following things:

• Ensure teams have regular retrospectives that are properly facilitated.
• Include improvement goals alongside product goals and give them priority.
• Celebrate failures as opportunities to learn.
• Have a future-facing mindset. Focus on the future and use your knowledge of the past to improve that future. Previous behaviours are just information and data that can help you to improve in the future, they are not mistakes.

Watch out for these traps and anti-patterns given in Table 5.13 that can divert your focus from this principle:

SUMMARY

The principles of the Agile Manifesto are 12 relatively simple statements. However, there are two key factors that are important to remember:

• The principles may appear common sense, but are not common practice in many teams. There are systemic behaviours and practices that undermine or directly oppose the principles in many organisations and teams.
• Although short, there are hidden depths and nuance within the principles that aren’t always obvious when they are first encountered.

Understanding the principles in depth and understanding what lies beneath them is critical to being able to harness their full potential for yourself or your team.

46 https://agilemanifesto.org/principles.html.

47 The term ‘tacit knowledge’ is attributed to Michael Polanyi in his 1958 book Personal Knowledge, republished with new foreword by Mary Jo Nye in 2015. Polanyi, M. and Nye, M. J. (2015) Personal Knowledge: Towards a Post-Critical Philosophy. University of Chicago Press, Chicago, IL.

48 A definition of ready defines the criteria that work must meet before the team can commit to delivering it. This can include too much detail as well as not enough. See Chapter 10 for more details.

49 Koren, J. R. (2017) Wells Fargo overhauls pay plan for branch employees following fake-accounts scandal. Los Angeles Times, 10 January. https://www.latimes.com/business/la-fi-wells-fargo-pay-20170110-story.html.

50 Boué, G. and Corradino, D. M. (2019) Does incentive pay work? SHRM. https://www.shrm.org/hr-today/news/hr-magazine/summer2019/pages/
does-incentive-pay-work.aspx.

51 Information from a conversation one of us had with the chief technical officer (CTO) of the company.

52 Personal experience from working there from 2001 to 2005.

53 https://thecoreprotocols.org. The Core Protocols are a set of techniques for high performing teams developed by Jim McCarthy and Michele McCarthy and are an open source resource. They are also described by Richard Kasperowski: Kasperowski, R. (2015) The Core Protocols: A Guide to Greatness. With Great People Publications.

54 Kerth, N. L. (2001) Project Retrospectives: A Handbook for Team Reviews. Dorset House Publishing Co Inc., New York.

55 https://scrumguides.org/scrum-guide.html.

56 Derby, E. and Larsen, D. (2006) Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, Dallas, TX and Raleigh, NC.

57 Syed, M. (2015) Black Box Thinking. John Murray, London.

58 Some examples: https://retromat.org; https://www.tastycupcakes.org; https://www.liberatingstructures.com; https://www.retrium.com; https://www.mural.co/; https://miro.com/guides/retrospectives/
ideas-games.