Many of us are familiar with using the term ‘project’ when delivering change or developing technical solutions. An Agile delivery is different and introduces some new language. This chapter explains why:

• ‘Project’ isn’t always a helpful term to use for Agile work as it can lead to unhelpful assumptions.
• ‘Product’ is the dominant word used by Agile teams at it helps to maintain stronger customer focus.
• Agile applies both an iterative and an incremental approach to delivery, and this is key to how it delivers value.
• The Product Backlog is such a critical artefact.

WHAT IS A PROJECT?

The Oxford English Dictionary defines ‘project’ as:

An individual or collaborative enterprise that is carefully planned to achieve a particular aim.²⁹

The first challenge with this definition in terms of Agile delivery is the reference to ‘carefully planned’. While Agile deliveries can be carefully led, the level of planning is usually very variable – tightly planned in the first couple of weeks; more loosely planned over the next couple of months; and barely planned at all over the next couple of quarters.

This doesn’t mean they are poorly led – it is an artefact of Agile approaches being particularly well suited to problems where the detail of the problem isn’t clear at the start, as we will see in Chapter 4. This means that we cannot ‘carefully plan’ to meet our ‘particular aim’ in advance. Instead, Agile teams must continually plan and adjust as we learn more about the problem we are solving and the solution we are developing.

As we described in Chapter 2, traditional linear projects begin with a requirement, analysis and design phases where the problem is thoroughly understood, requirements fully defined and a solution proposed and analysed. Once this is complete, the development of the solution starts.

In Agile deliveries, we begin developing a solution before we even know the detail and before we have thought through a detailed design. Furthermore, we expect the customers to start using the solution when we know it doesn’t meet all their needs and that its design will likely change. Both these behaviours are profoundly different from classic, linear project management. Understanding that this is how Agile approaches work is critical to being able to understand or lead Agile work.

ITERATIVE AND INCREMENTAL

One of the fundamental properties of an Agile delivery is that it presents the solution to the customer in an incremental and iterative way. This means that:

• The solution is delivered in a series of iterations, usually time-bound, with each iteration delivering a version of the solution or product.
• The value of these versions to the customer incrementally increases with each iteration.

In other words, customers can start using the product very early in the project’s life cycle, and each time a new increment is completed, it will add more value – usually through implementing more of the users’ needs and improving existing features.

As customers use the solution, they understand more about what they need, and whether this version of the solution is meeting those needs. This feedback allows new ideas to be refined, and the next version of the solution to be better. This experience of the solution also improves the customer’s understanding of what is important to them, and therefore what is important to deliver next, and enables prioritisation of the user needs to be achieved iteratively and incrementally.

This feedback loop is essential within Agile delivery as it enables the customer to evolve their ideas throughout. Collaboration between the team and the customer is encouraged so that the design and architecture of the solution also adapts and iterates throughout the development life cycle to support the evolved understanding.

This is particularly important for IT products, where priority of the user needs can be very volatile. The longer it takes to make a decision regarding implementation of a user need, the less likely it is that the user need will still be valid or a priority. In Agile delivery, it is advisable to use short iterations to incrementally deliver a small number of user needs that you are certain the customer has prioritised. Once this has occurred, the customer will be better placed to prioritise what they need next and provide feedback for any new ideas that have arisen from the first increment. This forms the basis for the next iteration and ensures that users’ needs are being understood just enough and just in time.

Each iteration is like a short project

This iterative and incremental approach means that we should visit all aspects of the delivery life cycle in every iteration: understanding user needs, deciding our design options, implementing and testing a solution and deploying that solution for customers to use. That’s why one of the most widely used Agile approaches, Scrum, states that each iteration ‘may be considered [to be] a short project’.³⁰ This is a helpful way to think of Agile delivery and a good use of the word ‘project’. It also helps us to understand the second fundamental difference between Agile and traditional projects – their duration.

Traditional projects are usually very time centric, with an emphasis on planning and achieving funding milestones. This depends on accurate estimation to ensure the time available will allow the scope to be delivered. Extending projects usually requires some form of change control providing additional layers of governance that make change harder rather than enabling flexibility. As projects are funded and planned for set periods of time, they are rarely stopped early unless there is some crisis. The fundamental flaw with this approach is that it doesn’t work well in an environment where change is likely. We need to shift thinking away from fixed scope and big up-front planning to something that can adapt to change more readily.

Agile deliveries can achieve this as they don’t have a fixed duration or long up-front planning and design sessions, as traditional projects do. Rather, every iteration provides an opportunity for the customer to decide whether they want to continue to invest in improving the solution. Since Agile teams always aim to deliver a solution that customers can use, this means that they can iterate until the customer needs have been met by the solution or until the customer decides to stop funding. Essentially, every iteration could be the last. Conversely, if an Agile team is considered to still be adding value to a solution beyond the originally anticipated duration, a customer can decide to continue investing in it.

This is why Agile deliveries can be better value than traditional projects. Because they focus only on delivering what the customer needs, they save time and money by not developing features that the customer identified at the start, but subsequently decides they don’t need. In a traditional project, requirements are fully elaborated and documented at the start even if they turn out to be a low priority.

Even well-managed traditional projects can overrun. Customers often realise they need new or different requirements after the initial requirements have been agreed. This is usually due to not truly knowing what they needed at the start, or because things have changed since they initially provided their requirements. Agile teams try to avoid contracts around requirements and even try to avoid using requirements at all, instead referring to them as work items, ideas and customer needs. This avoids the contractual aspects often associated with requirements. With traditional projects they are agreed and signed off before the first line of code is written; in Agile this is simply managed through a prioritised backlog where less important work items are de-prioritised and the customer may decide they don’t need them at all.

Managing work in this way enables time and effort only to be spent understanding and developing the items that are most important and provides the flexibility for when customers change their mind. This is discussed in more detail in Chapters 8 and 10.

Since the major cost in many Agile deliveries is people’s time, this also means that Agile teams maintain flexibility with cost; it means that when we need to use cost as a constraint, we can be confident that we get the best value for our investment because we deliver the highest priority requirements first. Even in situations when they take longer than anticipated, we know that the requirements we don’t have time for are certain to be less important than those we do.

Agile deliveries maintain a flexible approach to planning where the detail is understood only when a customer need has been prioritised. While this may look like short-term planning, there is still forethought and long-term planning in terms of roadmaps and a vision. It’s just that the plans can change based on feedback and that the detail is developed just in time.

Of course, there are also many situations where the traditional, linear approach is the best choice to manage the delivery. Where we are certain the requirements will not and cannot change – perhaps a like-for-like legacy system replacement – then a traditional Waterfall approach is likely to be faster and cheaper. The frequent production of iterative versions of the solution and checking the priority of requirements will be wasteful and prevent the team delivering faster.

THE IMPORTANCE OF THE PRODUCT

Although the word ‘project’ still carries significance and weight in many organisations, in Agile teams the word ‘product’ is far more important. The seemingly insignificant difference signals an important shift in mindset:

• A product focus requires a focus on the customer, their needs and ensuring those needs are met by the product.
• A project focus implies a focus on the planned delivery approach and ensuring that we deliver what we are contracted to.

The term ‘product’ in Agile refers to whatever is providing value to the customer. Often it is a tangible product, such as some software, media or a physical item, but it can also be a service, business process, change initiative or organisational transformation. In short, it can be anything that the customer finds valuable.

This focus on the product is also reflected in Agile roles. In every Agile approach there is a significant role responsible for the ownership of the product, usually called the Product Owner. This is the person who is accountable for the product meeting the needs of the customer and for owning the Product Backlog – the list of things that the product could do.

The Product Backlog

The word ‘backlog’ is an unusual one, so it is worth explaining here. In simple terms, it is just the list of work items or ideas that will help to achieve value for the customer; but it is much more significant than it implies. The Product Backlog represents the current view on what the product needs to do to meet the needs of the customer. It is an ordered list, with the items at the top being those that represent the greatest value or are most urgent to address, and below that are things that are less important (see Figure 3.1). It is not a plan.

Managing the backlog is an ongoing and crucially important task. Once the team is working on the current iteration, the Product Owner’s role is to make sure that the backlog continues to represent the current view of what is important. That may mean things are shuffled around, added, changed, split, combined or even removed. In this way the backlog constantly represents the current priority and ensures the team is always working on the most valuable work.

The Product Owner must also ensure that the work at the top of the backlog – the things that are most likely to be delivered next – describes things that can be delivered and used by real users for real tasks. If it doesn’t, the team won’t be able to release versions of the solution (or product) that can be used, and the core premise of iterative and incremental delivery is lost.

This is surprisingly hard to do well, and it is easy to slip into bad habits such as treating backlog items as commitments rather than options, or describing technical components rather than user value. It is really important that each backlog item describes clear, genuine value for the users of the product. A good tip to test this is to ask someone outside the team (such as a director or user) what the backlog item means and whether they would benefit from it. If they can’t answer, perhaps it isn’t written in terms of customer value.

Since the items at the top of the backlog are those that need to be taken into the next iteration, they must be small enough to be completed in less than the length of the iteration; but, given that users’ needs change, it would be wasteful to spend a lot of time elaborating things that won’t be prioritised for delivery for a long time.

Good backlogs will have loosely defined, big items at the bottom and smaller elaborated items at the top. The bigger items represent larger pieces of work that are not yet fully understood, and perhaps contain complex user goals. As and when these items become important, they can be broken down into smaller goals and the detail and complexities will be uncovered at that point, and not before.

Crucially, the Product Backlog doesn’t need to contain everything the product could ever do – it just needs to contain things that are potentially important enough to be delivered in the next few iterations. Things can always be added to it and longer-term planning can be carried out elsewhere. Approaches for this are covered in Chapter 10.

SUMMARY

Agile approaches introduce new language alongside new ways of thinking. Instead of thinking about a project, with clear aims and plans at the start, we think of a product, with a customer need that must be met.

Customer needs are described in a Product Backlog, which is a prioritised list of work items describing the value a customer can obtain. We often call these items ‘stories’, as they help to tell a story of what we intend the product to do. This is covered more in Chapter 10.

Because all Agile approaches expect change, we commit only to short timeframes – perhaps just a week or two – and leave everything else more fluid. That means we can introduce change late in the process as it arises, even late in the development. Conveying longer-term intentions may be hard, so other ways to achieve this are required, such as roadmaps. However, even roadmaps or release plans are just guesses – we still expect they may change, so we don’t put in too much detail and we certainly don’t expect them to be treated as commitments or promises, as traditional plans are. They are just well-intentioned, well-informed guesses that provide a snapshot of the future, which can change as we learn and evolve our understanding.

As work continues through the development of a product, it is essential that multiple versions of the product are delivered so that the customer can use it as early as possible, within the first few weeks if possible. Each version that the customer can use for their real business problems results in valuable knowledge and feedback. Without this feedback, an Agile approach is pointless.

The early deliverables enable the customer to work out whether the product is working for them and thus helps them to understand their needs better. Feedback on the product itself also helps the developers to improve its quality and evolve the architecture and design. As we get further into the development, our ideas of what still needs to be on the backlog improves and we get a better idea of when we may achieve the overall outcome.

This iterative and incremental approach provides the ability to be flexible with the cost, product features and schedule of the delivery. We can ensure each iteration delivers the customer needs on time or on budget because we focus on customer outcomes and ensure each iteration achieves the outcome even if it is a minimal viable solution.

This is why Agile teams can deliver more value in less time – delivering iteratively and incrementally enables tighter focus on delivering a working solution to the customer early, thereby giving insight into whether that solution is valuable much earlier in the project life cycle than traditional projects.

29 https://www.lexico.com/definition/project.

30 Scrum Guides (2020) The 2020 Scrum guide. https://www.scrumguides.org/scrum-guide.html.