Agile
for all?
The vast majority of software development teams today claim to be working ‘Agile’. While not perfect, Agile development is seen as better than alternatives like the Waterfall model, and is becoming more or less the industry default methodology.
But is Agile development really suitable for all situations? What if your development project is contract-based with a fixed scope, fixed schedule and fixed price? What if you can’t deliver a partially complete product? What if your product needs significant effort to be installed in the field?
Doesn’t ‘agile’ mean you need to be able to change direction? Does Agile development make sense for you?
Does Agile work for fixed price, fixed scope projects?
The Agile software movement came about in 2001 when a group of self-described ‘organizational anarchists’ defined the key principles that, in their opinion, made for good software development. These were enshrined in the now legendary Agile Manifesto, and fleshed out further in the Principles behind the Agile Manifesto.
These ideas fit very well to a team that has control over its product scope and delivery timeline, can regularly gain feedback from the market and has the ability to adapt to that feedback. Building your latest mobile phone app? You have access to constant feedback on what users are downloading and which features they are using. You can run A/B testing on a representative set of users. You have the flexibility to adapt your roadmap whenever you like and release app updates every week. Agile is for you.
But what about when you don’t have those options? When your project scope, release schedule and revenue is defined in a 100 page contract, is Agile development even possible?
The Agile manifesto tells you to favour “Responding to change over following a plan” – try telling that to your project manager.
How can you, in the words of the Principles behind the Agile Manifesto “deliver working software frequently” when doing that means getting access to an operational radar system or travelling to a remote mine?
Do four week sprints make sense, when you have an unchangeable set of requirements that will take two years for your team to complete?
Just be
agile.
Fortunately, although some aspects of Agile seem difficult to use, others are of clear benefit in this situation:
- The value of face-to-face communications.
- Using multi-skilled, self-organising teams to develop the best solution possible with the least organisational overhead.
- Continuous attention to technical excellence and focusing on simplicity in design.
Furthermore, even those aspects of Agile which, at first glance, seem problematic, can be adapted to suit this environment.
The key thing to remember when applying Agile ideas to your development is … to be agile. The underlying principle of the Agile movement is to reflect on what you are doing and adapt your processes accordingly. Nothing is prescriptive if it doesn’t make sense for you.
So while you may not be able to change your requirements or roadmap, you can adapt your design or your technology choice. You can possibly change the priority of how you implement your solution. Working on new or complex features first can greatly reduce project risk and provide early warning of any cost and schedule issues.
The Scrum-based practices of “daily stand-up” meetings, short work blocks (sprints) and retrospective reviews of sprints provide the basis for making the above changes to your implementation priorities, as well as providing more early feedback on potential issues. Teams should be asking themselves constantly how to improve, another key tenet of Agile.
And while you may not be able to formally release very often, and may not have access to your customer, setting up in-house alternatives can provide huge benefits. Build your product in a way that it can be built with minimal functionality and then improved. Then use continuous integration and deployment (CI/CD) to in-house test sites to mimic the ability to ‘deliver working software frequently’.
Nominate in house subject matter experts (SMEs) as proxies for your customer and demo the latest build to them regularly. Focus on demonstrating the things you are unsure about, to allow time to incorporate their feedback into the final product within the bounds of your contract and budget.
Then, once your organisation starts working like this, it will become important to consider how to support this way of working in any new project negotiations.
- Keep the contractual requirements at a high level to provide more freedom for the development team;
- include the costs of internal test site infrastructure for CI/CD in the contract proposal; and
- build in as many customer checkpoints as you can to gain feedback, within reason.
Working within the bounds presented by your industry or project contract, Agile concepts can still deliver great advantages to your development effort.
