The previous three chapters have focused on the foundational elements of all Agile approaches. It is important to understand these well before trying to apply them. However, most people have their first experience of Agile in the context of one of the Agile frameworks or methods. When looking at these frameworks (and there are several), they tend to share much in common, even though they may be described in different language.

This chapter looks at the core activities and decisions that are part of any Agile endeavour and uses a loyalty card scenario to provide some tangible examples that will help you to understand:

• the core elements in Agile deliveries and how they work;
• how they reinforce and apply the core Agile concepts discussed previously;
• how you can be successful in applying them.

By now, it should come as no surprise to learn that these things are frequently misunderstood and/or applied badly, and that this leads to poor results and Agile teams struggling to get the benefits they expect. We will help you avoid those problems.

We will describe some of the ways that Agile teams behave throughout the delivery life cycle, including how we deliver value early, how teams improve and the common roles in Agile teams.

HOW DOES AGILE DELIVERY WORK?

Agile deliveries look very similar to non-Agile deliveries in many respects:

• A problem worth solving is identified.
• A team is formed and charged with solving the problem.
• The team spends some time delivering a solution.
• Finally the problem is solved or the business decides to stop investing in it.

For any given problem, the skills required in the team are the same in Agile and non-Agile approaches; for instance, our loyalty card example will require design, marketing and software engineering skills. What is different is who has those skills, how they are employed and how the solution evolves during its development.

Agile deliveries have a single team developing the entire solution iteratively and incrementally. The team collectively has all the skills, knowledge and authority to deliver the solution to the customer, and the customer can start using versions of the solution from very early on.

An example timeline

Figure 7.1 shows one possible timeline for our loyalty card example. We say one possible timeline because the nature of an Agile delivery is that we expect things to change and we try to keep our options open as much as possible. We could have drawn a dozen different examples of this timeline and they would all have been valid.

This example illustrates several important attributes of Agile deliveries that are not always present in traditional projects. The detail in later months is intentionally vague. We don’t know whether an iteration sees updates to each element of the solution or not. Perhaps, in some iterations, the team focuses on the data analytics and doesn’t make many changes to the customer’s app. Perhaps, in other iterations, the opposite is true (see Table 7.1).

This Agile team will have the skills and knowledge to work on anything that delivers the maximum business value – whether that is front-end UI design, back-end data architecture and analytics or designing marketing materials to support the rollout to new stores.

In practice, teams are not always as multi-skilled as we would prefer and aren’t always as willing to do the work that is needed. It is common to see developers who prefer UI work find things to fix on a perfectly adequate web page when there is critical work elsewhere that is not being done – and vice versa.

The discipline required, from both the team and the stakeholders, to release very early versions of a solution can be a challenge. It is easier to wait until the solution is more complete. In this example, waiting until later may have meant that we missed an opportunity to maximise sales of a promotion, or invested lots of time and money in a data analytics solution that didn’t help store managers make better decisions.

GETTING STARTED

Most Agile approaches assume that you already know what you are going to produce and that your initial ‘backlog’ of work exists. In fact, that is rarely the case, and creating this starting point can be challenging for many teams.

Traditionally, a project manager would be appointed to lead any new endeavour. They would begin by creating a business case or project proposal to secure resources (people⁶⁴ and/or money). To do this, they would usually come up with a project plan that was detailed enough to identify all the factors necessary to deliver the project successfully; usually, this means detailed costing, delivery milestones, resource plans, dependencies and risks. Only with this level of detail could the project manager come up with numbers that they could trust and be held to account for, and only once the proposal was accepted could the team be assembled and work commence. Very often, this process would take some time, as meetings need to be arranged, estimates approved and documents drafted.

There are many problems with this approach, particularly given that we are in a VUCA world where assumptions are likely to be wrong, change is certain to occur and stakeholder guesses and opinions will change. It also relies heavily on one person and their wisdom, experience and knowledge: the project manager.

How do Agile deliveries differ?

If we reflect on the Agile Manifesto, starting an Agile endeavour ought to be very different indeed:

• We rely more on people and collaboration than on plans and detailed agreements.
• We expect customers using early versions of the solution to be a better source of product requirements than detailed analysis done in advance.
• We expect change, including changes in the detail of the problem we are solving and in our intended solution.

This means that an ideal Agile delivery starts by identifying a problem to be solved (or opportunity to be pursued) and immediately assembling a team to begin working on it. At this point, the detail of the problem and solution isn’t that clear, so the team needs to have the skills, knowledge and authority to cope with a variety of different ways forward. They will probably each be multi-skilled and comfortable learning new skills and technologies any time they need to. We will discuss this type of team – of generalising-specialists – later in this chapter.

Once the team is assembled, they focus on two things:

• understanding the problem (and business context) well enough;
• identifying the quickest and most valuable version of a solution to deliver first.

For small startups this can be relatively simple – just get some people together, perhaps with an external investor or some startup capital, and get on with it – but in larger or more bureaucratic organisations, this is so different from what they are used to that it can cause problems. How can I fund something when I don’t know how long it will take? When will I have a version I can sell? How will you mitigate your risks?

There are still plans in Agile

The first stage – understanding the problem – is where we address ‘planning’. For any endeavour, there are elements that are clear and unlikely to change, and there are elements that are not. The problem of traditional project management is the assumption that most things don’t change.

However, a criticism of Agile is the opposite – that Agile teams never commit to anything. This is wrong. In Agile delivery, the overall solution goal or vision will be stable. How that goal is met may change, but the business need will not. If it were to change, then the whole delivery should stop and we should reconsider whether the new situation still requires our effort.

So, the first thing an Agile team does is to agree the overarching vision and goal of the work. Very often, it will become obvious how much effort or time will be required, even if that estimate is vague. For example, developing a loyalty card programme will probably take a few quarters; we won’t be able to complete it in a month, and it’s not likely to take several years. We can also guess at the types of people we will need, for instance we need a software team that can deliver both user-facing systems (an app, data dashboard) and crunch numbers for management information. We will also need some marketing, branding and communications experience.

This level of information – a rough idea of the type of solution, the types of people we will need and a ballpark schedule – should be enough detail to start an Agile delivery. Figure 7.2 shows an example.

The information necessary to make a business decision is still there and the team will have done some initial analysis of the problem, the business context and the possible solutions in order to come up with it. That analysis could have been very lightweight – perhaps just a couple of hours – or it could have taken a few weeks.

Inception Deck and Agile chartering This ‘pre-delivery’ work is sometimes called Sprint 0, because it describes the time before the first iteration that teams using Scrum would call Sprint 1.

In The Agile Samurai,⁶⁵ Jonathan Rasmusson describes a technique called the Inception Deck, which teams use at the very start of an Agile delivery to capture their assumptions and share their intentions with their stakeholders. It is a simple set of slides, with each slide conveying an element of the work being proposed. For instance, solution vision, stakeholder map, candidate architecture, ballpark costs and so on. Over the past few years we have used this approach many times and evolved our own version.⁶⁶

Another powerful approach to putting just enough work up front is Agile chartering. This is an approach described superbly in the book Liftoff by Diana Larsen and Ainsley Nies.⁶⁷ In Agile chartering the team focuses on analysing the problem from three perspectives before starting an endeavour, or to realign a team. The key is to do just enough analysis to align the team with the work, each other and their environment. Spending a day or two on this, a ‘Liftoff’⁶⁸ can make them much more likely to succeed. The three core perspectives are:

• Purpose – Focusing on the work. Know why this is important and to whom; take ownership and accountability for the outcomes.
• Alignment – Focusing on the team. Know each other at a slightly deeper level. Appreciate our strengths and development needs, our similarities and differences. Teams cannot self-organise well without understanding one another.
• Context – Focusing on the environment around the team. It’s rare for a team to be 100 per cent responsible for all their outcomes. Understanding the wider context, the boundaries of their responsibility and the resources⁶⁹ they require is important to their success.

Spending time on an Inception Deck and Agile chartering can be a powerful way to instil confidence in your stakeholders, particularly when they are involved in the activities themselves. It can make them much more content with a proposal like the one in Figure 7.2 compared to the multi-page documents they may be used to.

Measuring progress

Once the delivery is underway, we are presented with another problem: without a project plan with milestones and dates, how do we know whether the delivery is on track?

The Agile Manifesto is clear on this point: it says that ‘Working software is the primary measure of progress’ (principle 7)⁷⁰ so that’s what we do. As early as possible, we produce versions of the solution (whether software or not) that can be used by customers. Their feedback will be a powerful measure of how well we are doing. Inviting stakeholders to witness and, better still, experience the work completed in each iteration is a better way for them to gauge progress than green ticks on a Gantt chart.

Measurements are discussed further in Chapter 8.

Innovation Accounting

Stakeholders, particularly those supplying the budget, can often be uneasy at the apparent open-ended nature of Agile delivery. With no milestones or firm dates and improved versions of the product arriving every couple of weeks, it can be difficult to know when to stop investing. That’s where Innovation Accounting comes in. The term was introduced by Eric Ries in The Lean Startup.⁷¹ Innovation Accounting works well with Agile teams because it places responsibilities both on the team and the investors.

• The team is encouraged to make tangible progress each period and is more likely to do that through usable versions of their product rather than deferring release until the end.
• The investors are encouraged to focus on the value being created by the team right now, rather than adherence to a plan generated months ago.

With Innovation Accounting, the investors decide how long (or how much) to invest in a team (or product) before they want to see some results and decide whether to continue funding. This could be as frequently as weekly or monthly.

This differs from traditional project accounting because a traditional project assumes that the project will last for the duration planned, and, while it can be stopped early, this would be an exception activity and regarded as a failure. As we explained in Chapter 3, even the use of the word ‘project’ leads people to assume it will last (at least) as long as initially planned.

In contrast, in an Agile delivery, even where we expect it to take a couple of years, our assumption is that change is likely to happen and that we might want to change direction or even stop it. This would not be regarded as an absolute failure; instead, it would just tell us that an assumption we had was wrong, or an experiment we tried had failed.

So, in an Agile delivery using Innovation Accounting, we may expect a full year’s investment but begin with just a month’s money to begin proving that our ideas have merit. After a month, the investors would look at our results and decide whether we should persevere (continue as expected), pivot (still aim for the same vision, but try a different approach) or fail (the vision is not likely to be met or would be too expensive).

Creating the backlog

The final thing that the team needs to have in place before they can start is a backlog of work to start doing. Preferably one that is in priority order with high priority items estimated in enough detail that they know whether they can complete an item in one iteration.

Some of the things that teams can do to create a backlog include:

• Stakeholder workshops to elicit user needs and problems.
• Value stream mapping, a Lean technique to walk through all the end-to-end steps that need to happen to realise value for the customer, including identifying where there are pain points, waste, delays or other opportunities to optimise the flow.
• User story mapping,⁷² a technique (and book) developed by Jeff Patton that allows large and complex products to be visualised in a map and prioritised to break the work down into small releases of value.
• Impact mapping,⁷³ a technique developed by Gojko Adzic where you start with the goal and work backwards to identify the behaviour changes necessary and then the activities or tasks required to make those changes.

Chapter 10 covers this in much more detail, including more guidance on some of these topics.

THE FIRST DELIVERY

We know that Agile teams aim to deliver early and frequently, but this can be a challenge when the solution is inherently large or complex. Sometimes it can seem impossible to begin delivering something of value in a few weeks. That could be the case with our loyalty card example. The final solution includes (at least):

• An app that customers use to sign up and track their progress.
• An analytics method to sift through the data and generate information that supports operational and strategic business decisions.
• Integration with the existing store systems and tills to connect customer purchases to the new system.

Figure 7.3 shows a candidate architecture that the team could have created as part of their Inception Deck.

This architecture looks like it could be pretty complex and might take several weeks to build enough that it could be used. So how can the team deliver earlier? This is where the minimum viable product (MVP) comes in.

Minimum viable product

The term ‘minimum viable product’ (MVP) was popularised by Eric Ries’ book, The Lean Startup,⁷⁴ where MVPs are critical to the Build–Measure–Learn cycle and an important way for entrepreneurs to test that their ideas have merit.

Put simply, an MVP is the quickest, cheapest version of the solution that will allow you to test your hypotheses and assumptions. It doesn’t need to demonstrate all of your product’s functionality, but it does need to have an outcome that you can measure in order to decide whether you are on the right track.

An MVP ought to be a viable product – it should be able to be used by the end user to solve a specific problem. However, some people extend the definition of MVP to include products that test a market but don’t actually provide value. When Buffer launched their first ‘product’ it was just a web page asking if people were interested in purchasing a product that would schedule their social media posts. The interest received was enough to justify further investment, but at that time there wasn’t actually a product that existed and it wasn’t possible to generate any customer value.

When this definition of MVP is used, the first version of the product that does provide value is sometimes called the minimum marketable product (MMP). In either case, the important thing is that the product is the cheapest and quickest way to complete a learning cycle. The knowledge you gain from the MVP helps you to decide whether to continue and what to prioritise next. Figure 7.4 shows how the loyalty card example uses MVPs.

While the concept of an MVP is relatively simple, like many things in Agile it is easily and frequently misunderstood and abused. The earlier discussion on whether a marketing test (as Buffer used) is an MVP or not is one example, but the more common problems we see are MVPs that don’t test a clear hypothesis, don’t have measurement and learning built into them or don’t provide any value to the customer.

Some examples where the term MVP is misused include:

• proof of concepts, wireframes, models or non-functional prototypes;
• early versions of products that don’t include enough functionality to meet the users’ needs, for example not operating on real data, not being approved for business use or only partially solving the problem;
• products that customers cannot use, for instance products created to demonstrate features that the customer can’t use themselves.

That isn’t to say that an MVP needs to do everything – far from it. An MVP exists early in product development when there are many more features to add and improve. But it does need to solve enough of the customer’s needs to provide them with some value, which could be a very small slice of value. Breaking down big problems into small goals is described in Chapter 10.

CONTINUOUS IMPROVEMENT

One of the reasons an MVP is useful in early development is that it provides a start point from which continuous improvement can commence. Getting actionable feedback from customers early increases the chance that our product will deliver the value and quality to the customer.

Continuous improvement is a fundamental aspect of anything Agile. It isn’t an add-on to delivery, it is a fundamental component of how Agile teams deliver value for their customers. It has its own principle in the Agile Manifesto and is integrated throughout Agile practices, methods and frameworks. Agile teams always believe there is opportunity to improve, and actively seek out those opportunities. The most obvious way this happens is through a retrospective.

Agile retrospectives

Agile retrospectives are held frequently, usually each iteration. They are also useful for looking back over longer periods such as funding cycles or product releases/increments. Retrospectives involve the whole team reflecting on what has happened in an honest and non-judgemental way and taking decisions about things to change or improve.

In their book Agile Retrospectives,⁷⁵ Esther Derby and Diana Larsen set out this agenda:

• Set the stage.
• Gather data.
• Generate insights.
• Decide what to do.
• Close the retrospective.

Each stage is a facilitated session and there are dozens of different techniques you can use to keep the event fresh and generate powerful insights from the teams.

This open and honest approach to finding ways to improve is very powerful, but it isn’t how many people are used to working. To some people, finding a potential improvement means admitting that things have been done wrongly until now. Reflecting on progress and identifying areas to improve can become an opportunity to highlight failure and attribute blame. The retrospective can become an adversarial and unpleasant place to be.

Potential changes don’t need to be big things. The Japanese word for continuous improvement or ‘change for the better’ is kaizen. In the Toyota Production System, team members propose thousands of kaizen a year. They could be something as simple as moving a waste bin closer to a machine to see if it makes the operator more effective, or moving it back if it doesn’t. When Agile teams are self-organising and empowered there should be lots of things about their work that they can change and lots of opportunities to improve.

We often see the opposite problem, where teams identify big things that could improve, but which they are not empowered to change themselves, for example unwieldy corporate processes, lack of people or slow procurement. It is important that the changes identified can happen and that the team commits to the changes.

THE ITERATION

Agile delivery focuses on iterative and incremental delivery of a product. This usually means that the team chooses a regular cadence to regulate their work, such as two or three weeks. Although different Agile methods use different language, there are certain things that are common across most approaches, whether teams are using Scrum, a scaled approach or an in-house method. The elements in a generic iteration are set out in Figure 7.5 and discussed in Table 7.2.

Iteration length

We know that Agile is biased towards change being inevitable. One of the ways to cope with this is through iterative delivery. Delivering without any plan is stressful and challenging, so we still want to have some planning and certainty in an Agile delivery. The iteration is how we do that. As we have shown, the iteration is a simple plan with a few events and artefacts.

The secret to being able to respond to change is to have short iterations. The longer into the future we try to predict, the more likely we are to be wrong. I can tell you with high certainty what the weather will be like two minutes from now, and I can have a fairly accurate guess about an hour away and even a day. If I try to predict the detailed weather in 10 weeks’ time, I am much less likely to be correct. It’s the same with iterations. Iterations work best when we have a clear and certain goal that we are working towards, with a team we can depend on being available to work towards it, and when we know the customer will benefit when it is delivered. The longer the iteration, the less likely these things are to be true.

In Scrum, an iteration length of no more than four weeks is mandated. Other approaches have different guidance, or none at all. Two weeks seems to work well for many teams. The iteration events should all scale depending on the iteration length – so the planning and reviews for a one-week iteration should be three times shorter than for a three-week iteration.

The iteration length is one factor the team has within their control and can adjust as part of their continuous improvement actions. Generally, we always advise: the shorter the better. Teams struggling to deliver on time often want to increase their iteration length when often this just exacerbates the problem. Try a short iteration first – the short timeframe requires smaller, simpler goals that take less effort to meet.

AGILE BACKLOGS

In Chapter 3 we introduced backlogs and explained their importance to Agile teams. Agile teams don’t have the same requirements artefacts that we find in traditional project delivery, and a backlog is very different thing from a requirements specification. The main difference is that we tend to assume that a requirement in a catalogue or in a requirements document is required. In other words, we expect to meet that requirement with our product and the product will not be complete otherwise.

In contrast, most backlogs contain items that may be included in our product, but also may not be. This is because we assume things might change and we might change our mind about a feature we thought we wanted at the start of the endeavour. The only exception is where the work for an iteration is described in a backlog, as happens in Scrum. Because iterations are short, we can be confident that the work planned won’t change and we can treat a Sprint backlog as something we have committed to.

Because backlog items might not be implemented, particularly those lower in priority, it is important not to put too much effort into them. Similarly, it can be wasteful to create lots of backlog items that you know are not likely to be implemented for a long time. It is better to wait until the team is close to being able to work on them.

Figure 7.6 shows an example Product Backlog for the loyalty card. The items at the top are the things we want to prioritise for the next iteration. Some of these are solution elements that we revisit many times to improve them, for instance the dashboard doesn’t need to have rich functionality right at the start because there aren’t many data to analyse. As the delivery progresses and we get more data in the system, there will be many more backlog items describing how that part of the system needs to change.

As we move further down the backlog, the descriptions get more vague. As the delivery progresses, those items will need further analysis, which will result in new, more specific items to be added to the backlog and prioritised. This is an ongoing process that is driven by feedback and by the need for the items at the top of the backlog to be detailed enough for the team to be able to consider them for the next iteration – too vague, then the team cannot possibly judge whether they can complete them in the next iteration or not.

Backlogs should have a 1:1 relationship with products. However, sometimes there are several backlogs (for instance in some scaled Agile approaches). This can be because there are different stakeholders involved in the backlog refinement and reviewing or because the teams are organised in a way that makes it hard for them to work from one backlog. Where there are multiple backlogs there is a higher risk of confusion, and it can be harder to be confident that everyone is working on the most valuable items.

Backlogs do not include everything that would be described as a requirement in a traditional approach. Things like non-functional requirements are managed in other ways, such as via acceptance criteria or definitions of done. Chapter 10 discusses in more detail how Agile ‘requirements’ are managed.

AGILE TEAM BEHAVIOURS

Perhaps the greatest difference between Agile and traditional teams is how they behave. Focusing on the left-hand side of the Agile Manifesto and following the pillars of transparency, inspection and adaptation requires a different mindset and behaviours.

The main pivot in mindset is from individual accountability to team accountability. Agile teams are collectively responsible for their outcomes. The team focuses on doing the most valuable work and working together to meet the goals they have committed to. That means helping one another, identifying opportunities to improve, changing plans to respond to events and doing the work that needs to be done, even when you would prefer to do something else.

High levels of collaboration

In an Agile team, while individual working is sometimes necessary, it is the exception rather than the norm. Working as a team allows for better decisions to be made – because there are more brains engaged on the problem and more perspectives shared – and creates higher quality products. When we work collaboratively, we get quality reviews and design improvements for free. This is why pair programming and mob programming are so effective.

Pair and mob programming are when two or more people sit around a single keyboard and monitor and work on creating a product. The conversations, challenges, discussions, explanations and experiments that result mean that the subsequent artefact has already had several rounds of review and several opportunities for problems to be found and improvements made. This also works for creating documents or other non-software artefacts. It sounds counter-intuitive – how can five people doing a job one person could do be more efficient? Yet, in practice, they can.

Some companies, such as Menlo Innovations,⁷⁷ believe this so strongly that all their work is done in pairs, as co-founder and chief storyteller Rich Sheridan describes in his book Joy Inc.⁷⁸

Customer focus

Menlo also demonstrate other core behaviours that we see in good Agile teams. They have a strong focus on the customer, including their ‘High-Tech Anthropologists’ who focus on gaining a deep understanding of who the customers are and uncovering their underlying needs, not just asking them what they think they want.

People focus

It isn’t just customers that Agile teams focus on; they also focus on themselves. As we describe more in Chapter 9, motivating people who do knowledge work is not the same as motivating people to do manual work. It requires more sophisticated leadership and creation of environments where people are challenged, supported, trusted and empowered.

Agile teams recognise that people develop professional skills faster when the work they do provides the right balance of challenge against skill. This optimal state – where the challenge of the work matches the skills of the person, stretching them without leading to failure – is described as the state of ‘flow’ by psychologist Mihaly Csikszentmihalyi.⁸¹ This is the state where we can lose track of time, stop worrying about other people’s opinions and want to continue with the task for its own sake.

If the challenge becomes too great, we can get stressed, anxious, worried or give up; if the challenge is too simple, we can get bored, relaxed or go on auto-pilot. This can also lead to poor quality work, because being in a bored or relaxed state can lead to poorly performing the task, for example it’s easy to do a poor job of cleaning the house, even when we know we can do it better.

The problem for many teams is that being in a balanced skill and challenge state will tend to increase our skill, but the challenge often doesn’t change. This can lead to the dwindling performance of a team and its people becoming less motivated. To solve this problem requires one of two things to happen:

• Adjust the work to increase the challenge, perhaps by the team taking on bigger chunks of work that require more skill and effort to break down.
• Move the people around to give them more challenging work, perhaps by moving to a new team with different technologies, customers or challenges.

In both these cases there can be concerns over disruption to the team, particularly if there are unhelpful measures being applied, such as Story Points.⁸² However, when this is a regular occurrence, as at Menlo, then teams are used to welcoming new members and adjusting to new types of work. The Tuckman cycle of ‘forming, storming, norming and performing’⁸³ still happens around teams gelling together, but it completes much more quickly.

This type of dynamic Agile team is also better able to cope with other types of change than a stable, unchanging team – and we know from earlier chapters that change is the one thing that we can depend on in a VUCA environment.

Professional development

This focus on the person extends to personal and professional development. Agile teams find ways to help each other develop and they factor that into planning and continuous improvement actions.

One of the most valuable activities we use in the alignment part of Liftoff is to understand each other’s aspirations for this delivery. For example, are there skills or technologies team members would like to learn, or skills they don’t want to use? It’s easy to see people as the product of their previous work (particularly when we also describe them as resources and define them by their CV) when it is better to see them as the potential for future work. This means that we want to include opportunities or training that help to develop the team as well as focus on delivering value for the customer. In this way an Agile team ensures that it is stronger and more capable after each cycle.

Formal training courses can help, and be scheduled and costed into the delivery, but there are many on the job opportunities that teams can choose to take to develop themselves. Some examples are:

• pairing with specific people;
• choosing work that challenges the person;
• setting specific development actions for each Sprint;
• regular knowledge sharing sessions;
• cross team collaboration, such as inviting other teams to design discussions or review sessions;
• open review sessions (and participating in those of other teams).

Continuous improvement

As we have mentioned previously, continuous improvement is a core principle of Agile teams and is woven throughout their practices and behaviours. Identifying something to improve is a positive thing with no implication of blame.

Success is not a binary attribute; we can succeed in meeting a goal and still find ways we could improve. Conversely, if we fail to meet a goal, we can still find things that worked well that we should do again.

Feedback

A primary driver of continuous improvement is feedback. Feedback in all its forms is a gift, whether it is systemic feedback from the results of a process or a personal comment from a colleague. The problem is that feedback is too often entwined with performance management.

In many organisations, feedback is almost always negative and often conjoined with some other purpose, such as an annual review, a promotion application or an assessment. It is rarely given solely for the purpose of continuous improvement. This also means that it is often given after the event it concerns, perhaps long after, and frequently bundled with other people’s feedback and anonymised. This makes it really hard to interpret and really easy to dismiss.

Agile teams have a much healthier relationship with feedback. It is both sought and given frequently, and it is always for the benefit of the recipient and given with kindness and respect – and it is often feedback on what went well; it’s not always critical. A helpful mantra for feedback that we have used is that it should always be kind, specific and helpful, as in the feedback model at Table 7.3.

AGILE ROLES

There are a few common Agile roles found in many approaches and methods, and there are some that are specific to a particular method. This book will not attempt to describe all the possible roles, not least because the frameworks change and evolve frequently. The main roles are the most important to understand. In all cases the roles need not be full-time. Apart from the ‘Developer’ role, it is common for people to either work on more than one product or have additional responsibilities to their Agile role.

The Scrum roles

In the 2021 State of Agile⁸⁴ survey of more than 4000 people, over three-quarters of respondents were using Scrum or some variant of Scrum, so it is no surprise that the Scrum roles⁸⁵ have become synonymous with Agile. They are described in the Scrum Guide,⁸⁶ and there are three: Developer, Product Owner and Scrum Master (see Table 7.4).

Other common roles

Most Agile approaches use the Scrum language, but some have additional roles. Even with Scrum teams, there are often responsibilities that fall outside the three accountabilities that need to be done. For example, Scrum doesn’t talk about financial accounting, contract management or performance management of staff, yet these things are often still required, particularly in large organisations.

One solution is to assign those responsibilities to a Scrum role. However, when the Scrum Master is also your manager or responsible for your contract, human nature means you are less likely to be open and more likely to defer to their view. This is not conducive to self-organising and self-managing teams.

Another approach is to have other people involved, either as an individual role or as part of a support function. The support functions can also be useful where a person in a role doesn’t have enough time to devote to it. In this case, it is really important that the support function doesn’t become a ‘proxy’ for the accountable person.

There are a few additional roles that we commonly see, either when we are using one of the other Agile approaches, or when organisations have created their own version of Agile. These are listed in Table 7.5.

Specific roles

Some Agile approaches have specific roles that are common enough to be worth us mentioning (see Table 7.6). The sources of these roles are: AgilePM,⁸⁷ SAFe,⁸⁸ LeSS,⁸⁹ Scrum@Scale,⁹⁰ Kanban⁹¹ and UK Government Digital, Data and Technology (DDaT) Framework.⁹²

T-SHAPED PROFESSIONALS

We have mentioned that Agile teams are self-organising and that they arrange themselves around the most valuable work necessary to meet their goal. However, we also know that there are roles, specialisms and careers that people either are in or aspire to be in. This apparent contradiction causes problems for many organisations. They desire to have specific career and skills paths for their staff, such as architecture, business analysis, testing or software engineering.

Often, we see that this segregation of skills finds its way into job titles and team membership, so that teams are not made up of ‘team members’, but of junior, senior and principal developers, analysts, testers, architects, technical writers, DevOps engineers and more. While this solves one problem, we have observed that it creates several more:

• Labelling people with specific skills leads them (and the rest of the team) to assume that they will be the people to do that type of work. This is also true of seniority labels. This leads to people only doing work of their ‘type’, even when it would benefit the team for them to help others (if their help would be accepted, which often it isn’t).
• Unless the necessary work is evenly distributed across the skills (which it never is), this leads to some people running out of important work and busying themselves with less valuable tasks (creating ‘inventory’ waste) and others having too much to do and running out of time – which often results in the iteration goal not being met and work carried over to the next iteration.
• The presence of ‘experts’ leads others to abdicate themselves from responsibility for that skill. This means that, even when they see problems or errors, they are less likely to speak up about it and less likely to be listened to.
• The segregation of role type inhibits a team’s ability to behave as one. In particular, seniority labels create an explicit hierarchy and pecking order.
• Individual desire to do particular work to achieve a skills assessment or promotion can mean work is hoarded by one person or things made more complicated than they need to be in order to get better ‘evidence’.
• Single points of failure, sometimes called Towers of Knowledge, are more common. This is where an individual (or small group) is the only person with skill, knowledge or ability to do a particular type of work, often one that is critical to the team’s success.
• Pairing and mob programming become harder to do (despite them being good ways to share knowledge and reduce risk).

Overall, these problems (and the many others we haven’t listed) make it much harder for the team to achieve their main purpose – to always be working on the most valuable work that will deliver the goal for the customer.

A solution to this is to have a team of T-shaped professionals. This describes people who are competent in a range of skills, even though there are one or two areas where they have deep expertise. This is in contrast to people who have depth in a skill but no real breadth in other skills. Scott Ambler coined an alternative phrase – ‘the generalizing specialist’⁹³ – since the person can reasonably call themselves a specialist but is still able to do more general tasks at a more basic level.

In an Agile team, the range of skills where we expect breadth are the range of skills necessary to deliver the product to the customer in a way that they can use it. For the loyalty card product, we have several customer-facing components, so we need some UI skill, but we also may have iterations where there is much more back-end data analytics to do; therefore, the T-shaped profile shown in Figure 7.7 could be a good fit for our team.

It isn’t necessary for everyone to have the same breadth, but across the team we would expect to see all the necessary skills present in:

• at least one person;
• preferably more than one person;
• preferably at least one person with some depth.

The level of depth required will depend on the complexity of the product, and there is often more than one area that requires some depth. For our loyalty card example, we also need some marketing and branding skills. Perhaps people with depth in those areas could also bring some competence in user experience testing or business change. Our engineer in Figure 7.7 has some data architecture skill, but we would want to boost that with other team members with more depth in data science and data analysis.

Constructing a team in this way not only helps to ensure we have the skills we need for the job, but also presents more opportunities for our people to learn from one another to develop their own skills. It can be a powerful way to bring more diversity into the team.

SUMMARY

While an Agile team starts with the same objective as a traditional project team – deliver a product that meets the customer’s needs – they approach and meet that objective in a very different way.

Although there are several methods or frameworks used by Agile teams, they follow the same basic format and share more in common than they may care to admit. They are biased towards change and use early delivery of value, short iterations, frequent feedback and flexibility to be able to respond to that change when it happens.

While from the outside Agile delivery may appear just like any other project, look a little closer at a good Agile team and it will look and feel very different indeed. Agile teams have a strong focus on people and collaboration. They care about their customers and that their needs are understood and being met, and they care about their colleagues, factoring professional development into planning and aiming to keep the work challenging and interesting.

Continuous improvement runs throughout Agile delivery, from early versions of the product, such as a validated MVP, all the way through to actionable feedback from customers to allow the Product Backlog to evolve. Additionally, daily stand-ups and frequent retrospectives provide multiple opportunities for feedback, reflection and identification of improvements the team can make to their approach.

Conversely, a poorer Agile team can look quite like a traditional project team, with similar poorer outcomes. Each of the differences described above can be challenging to implement and to persist with. People are not always used to working in these ways and there are many opportunities to revert to traditional practices, particularly when things get challenging.

Achieving successful Agile delivery requires everyone involved in the endeavour to understand the Agile Manifesto and principles, to have them at the forefront of their minds and to be supported by strong Agile leadership (see Chapter 9).

64 There is a terrible trend of using the word ‘resource’ to describe people. If you mean people, say people. Resources are money, pens, fuel and so on. We won’t use the word this way in the book again, and we hope you won’t either.

65 Rasmusson, J. (2017) The Agile Samurai: How Agile Masters Deliver Great Software. Pragmatic Bookshelf, Dallas, TX.

66 https://www.linkedin.com/pulse/navigating-inception-deck-simon-girvan/.

67 Larsen, D. and Nies, A. (2016) Liftoff: Start and Sustain Successful Agile Teams (2nd edn). Pragmatic Bookshelf, Dallas, TX.

68 We sometimes call this a ‘Liftoff’ after the book, or sometimes a ‘kickstart’, ‘project refresh’ or ‘realignment’.

69 Here we mean resources in the paper, software licences, desks and money sense, not people.

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

71 Ries, E. (2011) The Lean Startup: How Constant Innovation Creates Radically Successful Businesses. Portfolio Penguin, London and New York.

72 Patton, J. (2014) User Story Mapping: Discover the Whole Story, Build the Right Product. O’Reilly Media, Sebastopol, CA.

73 https://www.impactmapping.org.

74 Ries, E. (2011) The Lean Startup: How Constant Innovation Creates Radically Successful Businesses. Portfolio Penguin, London and New York.

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

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

77 https://menloinnovations.com/our-way/our-people.

78 Sheridan, R. (2013) Joy Inc: How We Built a Workplace People Love. Portfolio Penguin, New York.

79 https://www.strategyzer.com.

80 Osterwalder, A., Pigneur, Y., Bernarda, G., Smith, A. and Papadakos, T. (2014) Value Proposition Design: How to Create Products and Services Customers Want. John Wiley & Sons, Hoboken, NJ.

81 Csikszentmihalyi, M. (1990) Flow: The Psychology of Optimal Experience. Harper & Row, New York.

82 Using Story Points to measure a team’s performance is a bad idea for many reasons. In this context, it requires both the team and the work to be homogeneous and consistent. This means we can’t change the team, the roles or the type of work without making the measure meaningless.

83 Tuckman, B. W. (1965) Developmental sequence in small groups. Psychological Bull., 63, 384–399.

84 https://digital.ai/resource-center/analyst-
reports/state-of-agile-report.

85 The 2020 Scrum Guide uses the word ‘accountability’ not ‘role’ in order to prevent them being interpreted as ‘job titles’. Roles are not meant to be synonymous with jobs. A job can entail many roles.

86 https://scrumguides.org/index.html.

87 https://agilepm.wiki.

88 https://www.scaledagileframework.com.

89 https://less.works.

90 https://www.scrumatscale.com.

91 https://resources.kanban.university/kanban-guide/.

92 https://www.gov.uk/guidance/delivery-manager.

93 www.agilemodeling.com/essays/generalizing
Specialists.htm.