Since 2001 there has been a change sweeping the software development industry. Not for a long time has a single term generated such debate. This term, as you've probably gathered from the title, is 'Agile' or more correctly 'Agile Software Development.' It's unlikely that you haven't come across this term and most likely your day-to-day working has been in some way affected by it; but what does it really mean?
If you search the internet or visit your local bookshop you'll find article upon article, book upon book on the subject of Agile Software Development, however it is unlikely that they will provide you with a single common definition, and herein lies one of the problems. The 'Agile Manifesto' created in 2001 set out a list of principles, not definitive rules and processes, and as such has been open to interpretation ever since.
As with any new technology, process or methodology in the industry there was quickly a move to label, productize and capitalize on it. This led to a narrowing and defining of multiple 'Agile Frameworks' and ultimately certification. These frameworks include:
The downside of this in my opinion is that the core principles that these frameworks are supposedly based upon can be missed. One of the original authors, Robert C. Martin, has since distanced himself from the 'Agile movement,' instead focusing on the Software Craftsmanship and returning to some of the key principles that the Agile Manifesto was based upon.
For many years I have had project planning meetings often begin with the opening phase "we want to run this project as Agile, not Waterfall." The reason often varies, from company edict, through to a project sponsor having read an article in the latest edition of their favourite tech publication. This statement then leads to a large portion of time being spent picking apart what the other party actually means when they say "Agile."
I need to clarify myself at this point, whilst I sound like I'm anti-Agile, I'm definitely not. In fact I'm pro Agile Software Development as defined in the Agile Manifesto. However because the term can mean literally anything, it can add unnecessary complexity and confusion to projects.
I find that in the majority of cases the other party is looking for flexibility and visibility during the project build phase, however they also want the project at a fixed price. This I find is a contradiction, as in order to commit to a fixed price project, the supplier (myself) requires the functionality to be specified up front – not very Agile. It is possible to achieve a purely Agile project, however you need buy-in from the start on key ideals such as:
- Undefined deliverables – they will be discovered during the project, not defined prior to beginning development. This also means the duration of the project is undefined; it finishes when you're happy with the state of the product.
- Increased resources compared to a Waterfall project – due to the undefined scope, usually at every stage a developer, tester and requirement owner is required. If you have multiple components being worked on during the iteration then this multiplies out.
- Willingness to accept failure – this is hard to accept, but as there is no end goal it has to be accepted that time may be spent on a component or research that ultimately isn't required. What Agile does allow for compared with Waterfall, is to discover this earlier, perhaps within a single iteration instead of in UAT at the end of a traditional project.
Greater visibility during the project is normally requested; this is beyond that of the Project Manager's weekly update. This has an associated cost in terms of preparing environments with content, planning the meeting and ensuring the correct resources (normally the Lead Consultant or Solution Architect) are available to present the project and answer any questions. Typically iterations or sprints are a minimum of 3 weeks in duration, therefore the cost is multiplied by the iterations in the project.
So after doing the dance around 'Agile,' the result is often that everyone in the room is actively avoiding using the word Agile and common sense prevails. The true goals come to light and frequently include:
- Visibility – 'Show and Tell' sessions of a set frequency, normally budget dependant, to review progress, provide confidence that we (the supplier) are on the right track, and for us to verify that the components built haven't been misunderstood. This is highly valuable during the build phase of a project and is what we find leads to better software.
- Iterations / sprints – Clearly defined time blocks with set deliverables. Kanban can be mixed in to the iteration planning either with the project team or internally within the development team.
- Minimum Viable Product (MVP) – This is a key tenant of Lean. As quickly as possible get to a viable release. It doesn't have to be the full final product, but get something in the hands of the end users as soon as possible. This may be seen to be too risky or contain too many unknowns, if so look to phase the project, keeping the phases small and succinct.
A combination of these can provide a way to add agility to the project. The project isn't Waterfall and it's not pure Agile, it's an iterative approach bringing in the best of the Agile frameworks. It's worth pointing out that previous trends in the industry such as Unit Testing and Test Driven Development (TDD) are no longer sold in to projects as separate line items, instead they have become woven in to our everyday development practices. I believe Agile practices will, to a certain extent, follow the same route. But for now pick and choose the best parts to create a process that best fits your project – don't try to do Agile, instead be agile in your processes and practices.
If you want to know more about the way BrightStarr approaches its countless successful projects, then why not check out our proven Kinetica project methodology, which has delivered for all our clients.