4 Agile methods compared and contrasted
“Thirty spokes unite around one hub to make a wheel.
It is the presence of the empty space that gives the function of a vehicle. Lao Tzu”
Choosing a method to support your Agile initiatives can be a daunting task. There are many different methods available, all with different characteristics. Each one is good at some aspects, and not so good at others. It is important to stress again that implementing a method will not in itself make an organization Agile.
One of my old bosses used to say, ‘You can’t learn to run by buying a smart pair of running shoes.’ You have to learn to run first, then get the best shoes for running in; for top athletes, good shoes can make the difference between winning and losing.
When implementing Agile, methods and frameworks are useful and probably required, but we have to understand where they can be used best, and why we are using them. We need to be in control of the method, not vice versa. So be careful if you hear people saying, ‘If you’re not using our method properly, you’re not Agile.’
So how can we make sense of the plethora of methods and frameworks available? Categorizing them might help. In my opinion, they fall into four basic categories:
- Techniques
- Not methods as such
- Can be used throughout the Agile process (or other processes)
- Provide ways of approaching or visualizing situations
- Development methods
- Provide guidance on Agile development
- Limited for working at scale
- Delivery methods and frameworks
- Generally cover delivery of features
- Some scaling may be possible
- Provide role/team structures
- Full project/programme methods and frameworks
We will now look in more detail at the techniques, methods and frameworks.
4.1 Techniques
There are certain techniques and practices that are useful when working in an Agile way. Typically, they help to visualize situations, or provide an approach to solving certain problems. While they are very powerful in what they do, they will probably be insufficient to run full Agile projects and programmes. However, they may be sufficient when using Agile for business as usual or continual delivery.
4.2 Development methods
Development methods are focused on software development teams, and provide a structure and technique that allow developers to work in an Agile way. Although multiple teams can use these methods, the methods themselves do not offer ways to scale up or down, except in a very technical sense, such as for continual integration or distributed software configuration. However, they can be an effective tool for the software development team.
4.3 Delivery methods and frameworks
Methods focused on delivery offer a structured approach to turning vague high-level requirements into features that can be implemented into the organization. They will incorporate techniques for defining requirements sufficiently to be able to develop and deliver them. The development process happens in short time periods, called timeboxes or sprints, that are typically between two and four weeks long. At the end of this period, features will have been developed that can be delivered into the organization.
Delivery methods often include team roles and structures with an ideal team size of around seven, plus or minus two people. The teams work towards a goal and are empowered to deliver against that goal. The teams are multidisciplinary, incorporating representatives from teams developing the outputs (i.e. supplier) and those who will use the outputs (i.e. customer).
Although these methods offer some scaling possibilities, problems often emerge as the number of teams grow and the governance needs of organizations need to be satisfied.
4.4 Full project/programme methods and frameworks
Methods that work at the project or programme level will normally offer a structured approach to execution from start to finish and incorporate all the expected Agile concepts. They can offer a way to bridge the gap between the processes and governance operating within an organization and the Agile approaches being used at a delivery level. Within these methods we are likely to see:
- ‘Just in time’ planning based on planning horizons
- Enough design upfront (EDUF)
- Full project organizational structures and roles
- Sufficient governance to satisfy the organization’s needs.
These methods offer a good approach to setting the foundations of a project or programme, enabling a good understanding of high-level goals and requirements, while allowing the detail to emerge during the development undertaken by the Agile teams. They also provide sufficient governance without affecting the Agile nature of the project or programme.
4.5 Which method is for me?
When considering which Agile methods to use in your organization, it is important to understand that you do not have to make a single choice. Methods in the four categories can be combined to provide your organization with a solution that works for you. For example, full project/programme frameworks will provide interfaces to your governance requirements, but can also incorporate other delivery and/or development methods for that part of the process. Similarly, delivery methods can be used in conjunction with development methods. In general, techniques can be incorporated throughout any of the categories. Guidance is available on using specific methods together – for example, the DSDM Agile Project Framework and Scrum (Craddock et al., 2012).
Exactly which methods will suit your organization will depend on its culture and approach. Organizations that utilize structured, controlled approaches (or are required by regulations to show structure and control) are likely to require a project/programme framework. Product-based, innovative organizations may start at the technique or delivery level, and eventually implement a project/programme framework.
Table 4.1 shows some of the more popular methods (in alphabetical order) and where their key focus lies with respect to the four categories. The category assigned is their main focus, and strength, but they may also offer some capabilities in some of the other categories well. Each method is briefly described, followed by its main uses and potential limitations.
Table 4.1 is correct at time of writing, and is my opinion of the frameworks, techniques and methods.
It is useful for senior managers to understand some of the detailed concepts that may affect informed decision-making. The following sections describe some of these concepts.
4.6 Continual flow and delivery
A growing trend in Agile is to use it for continual delivery and continual improvement. The same tools and methods are used, but combined in a different way, as the emphasis is not so much on a project- or programme-based approach as on a constant, continual flow. Most of these approaches include aspects of Lean and Kanban, sometimes in combination with Scrum (for example, Scrumban and/or the product-based programme delivery approaches such as LeSS and SAFe. Further information on these is given in the bibliography.
4.7 Hybrids
Agile is not suitable for everything, but some of the techniques and practices can be used even if you are not totally Agile. As Agile matures, more and more organizations are asking the question, ‘What if I want to, or must, do some of my project in a non-Agile way?’ There may be many reasons for this:
- Regulations demand it
- There is little chance for iterative feedback
- The whole problem is very well defined
- There are organizational constraints.
Basically, we want to use Agile where it works and a more traditional approach where it doesn’t. The combined approach is known as a ‘hybrid’ (see Figure 4.1).
Until recently, the term ‘hybrid’ has had bad press on both sides of the Agile fence. Terms such as ‘Water-Scrum-Fall’ have been seen as derogatory, or there is a tendency to revert to Waterfall-type approaches. In fact, hybrids should be seen as normal. There are many situations where it would be better to have a more procedural approach. Equally, I struggle to think of any situation where you would not want to do some upfront work before diving in. This is particularly important as the problems become larger and more complex. In fact, what we are trying to do is to understand a problem sufficiently to be able to define increments that can be worked on and delivered early and often, perhaps in parallel. Then, a traditional approach may be more suitable for some of the separate pieces of work.
Figure 4.1 Sample hybrid model
I believe the hybrid problem is now mainly resolved. The Agile methods and frameworks defined as Agile project/programme management generally provide a structure for incorporating Agile. They incorporate the required (architectural) design and planning work upfront, with the concepts of ‘enough design upfront’ and ‘just-in-time planning’.
Chapter 7 provides guidance on tracking Agile and non-Agile initiatives together. Ironically, the greater risk is with the non-Agile parts, as it can be difficult to understand their exact status.
4.8 Mega-projects and scaling for Agile
Often, I am told that Agile would not work on mega-projects because of the problems with scaling. I always ask, ‘What is a mega-project?’. Is it:
- Large
- In scope?
- In time?
- In resource?
- Complex?
- Business transformation?
- All of the above?
When examined in more detail, some so-called mega-projects are business transformations, which are programmes consisting of a series of projects and enablement activities. Others are simply large projects that can be decomposed into manageable increments. Either way, this means scaling down rather than scaling up. Let’s examine the two cases in turn.
4.8.1 Business transformations
Business transformations move an organization from one organizational state (where it is now) to a new state (where it wants to be) and deliver benefits, or value. Such transformations often involve many aspects of the organization, requiring changes to business processes, organizational hierarchies, business architectures and culture, as well as introducing new technology and systems. It can take years to get to the final desired state. So how can Agile help with this?
The trick is to examine the programme sufficiently at the start to understand how we can deliver value incrementally, moving the organization closer to its goal in manageable steps. This not only provides benefit early, but allows us to learn from the experience so far, and from the feedback of those parts already enabled.
The term ‘step’ should not be confused with a small amount of work. Each step will involve a number of projects and activities and the resources and skills required between steps may be vastly different. Taking a step-by-step approach also allows us to change course or stop as needed. Once the projects and activities are defined, the teams can be empowered to deliver their part of the transformation. This structure allows the use of both Agile and more traditional approaches.
4.8.2 Large projects
What if our ‘mega-project’ is not a business transformation, but merely something that will take a lot of time and/or resource?
The Agile project management frameworks are useful in this case. They enable us to understand the problem enough (and no more) to be able to determine subsets that can be delivered separately, often in parallel, and potentially by separate teams.
Once each subset has been delivered, we can almost forget about it and move on to the next. ‘Delivered’ is a subjective term, as we may not always be able to deliver into the live environment (although this is preferred as the organization can start to get benefit from the project) but at least we know everyone is happy with what has been completed. This approach also allows us to understand interdependencies between teams, and to build team and project role structures that span the whole project and do not require constant stand-ups at different levels. We can then let each team determine how to deliver its part of the project, within the constraints of interdependencies and the wider project architecture and goals. This way of working will demonstrate that the step-by-step approach is faster than trying to do too much at once with a large number of separate teams.
When tackling so-called mega-projects, I always quote Albert Einstein:
“Everything should be made as simple as possible, but not simpler.”