Use modern software development practices, whether you’re Agile or not

What does Agile mean anyway?

The umbrella term ‘Agile’ has become so overused and abused in the IT sector that I think it risks becoming meaningless.

For example, in the past week alone, I’ve heard the word used in all of the following phrases: Agile project, Agile software development, Agile developer, Agile tester, Agile <insert any role you like>, Agile delivery, Agile life-cycle, Agile techniques, Agile processes, Agile books… the list is seemingly endless.

What irritates me the most though is that so many modern development practices, apparently just because they are modern, have been brushed under the same umbrella term - ‘Agile’.

Many modern software development practices can be beneficial to any type of project

In my last post Am I on an Agile project? A litmus test I gave clarity on what I believe constitutes an Agile project and argued that just because you work on a project that uses modern software development practices (which many mistakenly refer to as 'Agile') doesn't mean your project is Agile.

So it follows, that you don't need to be on an Agile software development project to use and get benefit from modern software development practices.

Take, for example, something simple like Continuous Integration. Continuous Integration is a technical practice by which a product is built to include (integrate) every developers' code changes on every commit (continuously), hence the name.

Why, in any development methodology you like, let’s say the V-model since that’s about as Waterfall as you get, would you not do Continuous Integration? The push-back I’ve gotten generally boils down to something like “this is not an Agile project” or “we’re not an Agile development team”.

Even if you’ve done all your design work up front and have separated out all your development from your testing so that you can keep all your testers together and all your developers together (presumably because it makes it easier to draw the floor plan), surely it still makes sense for the developers to know if they’ve committed a compile error quickly? Surely you still benefit as a development team (and I mean literally just the developers) in that your time-to-fix reduces if you know that you’ve broken the system immediately rather than at the end of the day, or the week, or the month, or the release cycle.

Other modern software development practices ‘tarnished’ with the Agile brush

There are many common software development practices that I see labelled as Agile, with the incorrect implication that they can only be used on Agile projects. Here are some, and there are many more:

• Automated testing of any kind (unit, acceptance, integration, security, performance etc.)
• Regular customer review and feedback, such as the Scrum sprint review meetings
• Daily standup meetings
• User stories
• Story mapping
• Impact mapping
• Static analysis
• Automated deployment
• A/B testing
• Technical spikes
• Relative estimation
• Specification by example

Become a great software development team, whether you’re Agile or not

All of the above listed practices are just really good ideas and frankly if a development team isn’t using them then saying that they don’t do this new-fangled Agile thing is just a bad excuse for not being current and good at your job. So enough with the excuses and the organisational constraints and the Project Managers and PMO and IT Management and the countless others that say you can’t do Agile in your context. Don’t do Agile, that’s great, and for all I know could well be the right thing for you and your organisation. But DO do all the good development practices, otherwise, whether you're Agile or not, you’re just out of date and not very good!