Agile software development has been around for quite a while now. In fact, it could be argued that in many cases it is now the de facto standard for software development.
However, throughout the industry we hear that organisations have tried and failed to reap the rewards promised by Agile advocates.
Most often, the root cause of failure lies in how the tenets of Agile are applied, rather than the Agile concepts themselves.
Where does it go wrong when we try to be Agile ?
In this series, I’m going to look at ten common misconceptions that can lead to failures in product development. I’ll focus on the development of products and systems, rather than desktop applications, because this is where Agile techniques can be particularly hard to apply. Along the way, I’ll throw out some helpies that suggest how these problems may be solved.
These posts will look at the fundamentals of product development, rather than focusing on specific languages, tools or frameworks. These first principles deal with how we engineer, rather than what we engineer.
This post looks at the first Agile myth:
It is quicker and cheaper to develop software using Agile techniques.
It’s not necessarily quicker or cheaper to develop products using Agile techniques. The Agile manifesto (somewhat cunningly) makes no statement so bold.
Agile is less about making a product quickly or cheaply, and more about being predictable and transparent. These factors are intended to improve project management, break down the divisions between different roles and share a common understanding of the product.
It is perfectly possible to achieve the bare minimum of features early in the development. However, this doesn’t necessarily mean that the end product will be delivered to the stakeholders any more quickly. In fact, it could easily take longer to develop a product that all stakeholders are happy with.
Feature Selection
The features judged to be the most important (e.g. to the market of users) may be the hardest to implement. These features will remain hard to deliver, whether the team is Agile or not. Agile does not remove the inherent complexity within features, but it encourages us to manage that complexity constructively.
A higher priority assigned to a feature implies that it will be delivered before a lower priority feature. However, if the higher priority feature is particularly complex, it may be counter-productive to build that feature early on. Therefore, the priority should not be defined only by its importance to the user, but also by how easy it is to deliver. The user (or even the market of users) is not the only stakeholder.
If we start trying to deliver complex features early on, then we often need to consider various dependencies, conflicts and many other unknown factors. Many other important aspects of the product’s integrity may become compromised in the rush to impress the users with what is little more than demo code, and the architecture will suffer. When features are prioritised poorly, we will inevitably incur a lot of technical debt.
Whilst Agile encourages refactoring of code, we need to avoid going through many iterations. Every iteration over the code inherently means more cost, so we must aim to minimise the amount of rework.
So, whilst a given feature may be important to the user, the order in which features are added is particularly important to the developers. To avoid drowning in the debt of rework, we must devise a practicable path for integration.
In Scrum, the integration path is defined by the order of features in the product backlog. This is negotiated by all stakeholders early in development, and maintained throughout.
The order can be manipulated to minimise the impact of dependent features. For example, a key feature of my house is its roof, but my house also needed foundations that will support the walls and the roof before the roof was added.
The roof of a house may be the most important feature, but it is rarely built first.
Agile Helpie
Therefore, the most useful or market-leading features may be delivered later on, because they depend on more basic features or platforms. The roof may be delivered later on, but it saves on costly rework – just imagine making a roof that can’t be supported by its foundations.
Agile encourages collaboration between stakeholders.
Prioritise the features to facilitate integration.
Agile Helpie
Magnitude of Work
It’s easy to add too many features to the minimum viable product. The result is that the development will be less predictable, and the integrity of each feature will be weaker, because effort is diffused across many different aspects of the product. The minimum viable product should be just that – minimal.
A phrase often thrown around development teams is “keep it simple, stupid”. Unfortunately, software is inherently complex. In fact, somewhat ironically, it often takes a lot of careful consideration to make a product as simple as it can be. Products are not made simple by simply not thinking about them.
Agile encourages incremental, iterative delivery of features.
The minimum viable product minimises the features.
Agile Helpie
Development Process
Poor development processes compromise the stability of the product. A common failure in teams that aspire to be Agile is to write everything twice (or more), when it could have been written right (or at least “righter”) first time.
Inadequacies in the development process will extend development time rather than shorten it, because the “working code” favoured by the Agile manifesto is actually the most expensive artefact to deliver. Therefore, the process itself must be developed to minimise the cost of working code.
Unfortunately, the Agile manifesto states that:
[We favour] Individuals and interactions over processes and tools.
Agile Manifesto
I do not interpret this statement to mean that processes and tools are not Agile. I believe the authors of the manifesto are expressing that, as a group of professionals, they should be trusted to make the right development decisions, and not get bogged down in the bureaucracy of heavyweight processes.
An experienced, well-organised team will interact effectively to deliver reliable features to a product, with little rework. An inexperienced team that is poorly organised will develop lower quality code. For example, if developers do not communicate their design decisions, participate in peer reviews or test their code, then they will probably end up with a lot of bugs to fix. This extends development effort.
The authors of the manifesto are all extremely experienced and well qualified. Whilst a development team may aspire to their capabilities, we cannot assume that a team is populated by such luminaries. Each team member has their own strengths and weaknesses.
The developers must take responsibility for defining a development process that ensures “just enough” quality to meet the stakeholders’ expectations. In terms of project management, these expectations are all related to performance, time and cost. All developers must buy in to the process and follow it consistently, because this is the essence of quality.
Given that Agile provides the opportunity to avoid the bureaucracy of heavyweight processes, it’s actually the appropriate use of the right tools that helps achieve this (e.g. continuous integration servers, configuration management tools, IDEs).
Therefore, using the right tools in the right way is integral to success in Agile.
The product is only as good as its development process.
Agile encourages continuous refinement of the development process.
Agile Helpie
Product Architecture
If it is difficult to add features to a product, then that product will take longer to develop. Worse, the product will be less stable for each iteration.
In the Feature Selection section, I suggested that it often helps us to build features from the bottom up, starting with the simple and working towards the most complex.
Therefore, it is important that the product architecture makes it easy to add new features. Every feature provides an opportunity to refine the architecture to help make this a reality, and stop developers sucking their teeth with apprehension whenever a new feature is suggested.
Whilst one particular feature itself may be easy to implement quickly (e.g. making a light flash), we must consider investing some more effort so that subsequent features can be added just as easily (e.g. making multiple lights flash in different colours).
Unfortunately, many developers react to the perceived pressure of time rather than using design activity to help them out. This means that we cut corners under pressure to create “working code”, and we suffer for it later. It’s important to have a longer term view of the overall architecture so that we can add more complex features easily. Thinking about design and architecture costs less than fixing bugs in code.
In architectural terms, this can be demonstrated by successful Agile projects that develop mobile, desktop or web applications. All these environments are supported by well established frameworks like iOS, .NET and Bootstrapper. The complexity presented to the application developer is minimised so that they can focus on adding value for the user. The complexity is reduced by platform architectures that facilitate development.
Thinking about design costs less than working code.
Refine the architecture of the product so it’s easier to add new features.
Agile Helpie
So What’s Your Point …?
The point is that Agile itself does not mean that a product can be delivered more quickly or more cheaply than any other approach to development. This is especially true when we have lower expectations of quality.
Is it really worth shipping a product with minimal features and low quality, just for the sake of time …?
Agile Helpie
A high quality product will perform to the expectations of the user and be developed within project timescales. The issues presented here are all hallmarks of a low quality product development. The result is that the cost of the lower quality product may actually be higher overall than the higher quality product.
Agile techniques favour incremental delivery, stakeholder engagement and the dynamism to monitor and improve both the product and its development process as we go.
To get the most out of Agile, we are expected to apply our professional skill and judgement to avoid common traps:
- Feature Selection: Order the backlog to integrate the architectural elements of the product, rather than its features. The simplest features can drive the implementation that more complex features will exploit.
- Magnitude of Work: Don’t commit too many features to the minimum viable product. Prove the easy things are stable before adding the hard things.
- Development Process: A development process must be defined by the developers and followed by the developers. It must be refined throughout development to improve quality (i.e. fewer bugs, more predictable time scales).
- Product Architecture: Every feature provides an opportunity to improve the product architecture. Take a long view of the objectives, and refine the architecture so it is easy to add new features. Ensure enough design is done up front so we commit to writing the right code, not writing everything twice.
3 thoughts on “First Myth of Agile”