I need to declare full disclosure up front, if you were to cut me open you would find Agile written through me like a slightly overweight, middle aged piece of seaside rock (hopefully this reference won’t be lost on my non UK readers). With this in mind my early years as a developer were spent frustrated that projects were taking too long, test were engaged too late and the business weren’t engaged at all. I appreciated that a process was critical and we needed to agree what we were to deliver and provide checks against progress but did it really need to take so long and be so disjointed? Over the years I learnt more about the classic problems with large “big bang” (aka waterfall) releases:
In the numerous months between the customer requesting work and receiving it, their requirements had changed due to the speed of change in the real world. This wasn’t the client’s fault they couldn’t have predicted the next 6+ months with perfect accuracy.
During this time customers often had very little progress updates and if they did the indicators weren’t always reliable.
Dev felt they were too remote from the customer and feared making decisions or had to wait a long time for them to be made.
Test acted as game keepers trying to catch the developers out to settle the age old question of who’s better, developers or testers.
With a long project plan very little pressure existed at the start. Issues were found and added given the lack of pressure to hit deadlines. Panic only set in towards the end where it became clear that we wouldn’t achieve what had been committed to. We then had the choice of reducing the test duration or dropping functionality and sometimes both.
Often things would go wrong and it felt like some people were spending more time building their defence as to why it wasn’t their fault rather than working on a solution
You can therefore imagine my absolute joy when I was introduced to Agile. Oddly it wasn’t alien but simply collected ideas that I had seen working well on previous projects. I need to be clear that there are a number of Agile methods which we’ll be looking at in later discussions but for now a few forgive me a few generalisations. Agile focuses on:
- Satisfying the customer through early and continuous delivery of valuable software rather than waiting till all deliverables are completed.
- Work is performed in regular “chunks” or iterations and working software is the primary measure of progress.
- Business people, developers, testers and analysts work together throughout the project to ensure the project remains valid and provides useful software.
- Teams are given the environments and support they need to get the job done.
- The team performing the work are involved with providing consistent estimates to divide the work into iterations.
- Requirements are captured up front but we only add detail to the ones we’re due to work on in the immediate future.
- The team are empowered to make the right decisions
- Quality and validation are built into the process not an afterthought waiting to strike
- The most efficient and effective method of conveying information to and within a development team is face to face conversation.
- Any changes to requirements can be supported as long as we all agree and the impact is agreed.
- At regular intervals the team reflects on how to become more effective, then tunes and adjusts accordingly.
Let’s be clear that Agile is not a silver bullet and won’t be appropriate for all scenarios but now that I’ve given a brief reason to consider Agile my next blogs will discuss, are you ready for Agile, what are the Agile methodologies, myths and facts of Agile, optimal techniques for introducing Agile and optimal development environments.