So unfortunately agile is not a product that you can simply buy off the shelf. Agile is an umbrella term for a way of working which incorporates a number of techniques from different disciplines. These are:
- Extreme Programming (XP)
Agile tries to take the best of these and combine it into one business process. So in order to understand some of the ways of working involved in agile, I’ll talk a bit about the above disciplines.
Extreme programming allows software developers to put customer focus at the heart of everything they do. This works by developers working in pairs to deliver solutions which are adaptive to change, incremental and robust. One of the ways this is achieved is by writing automated tests before any functional code is written (test driven development) and the concept of paired programming which is the theory that 2 developers working on the same problem will come up with a better solution than working on their own. More information on this topic can be found here
Scrum is a rigorous business process which involves developing software in iterations (usually 2 weeks) which are called sprints. The scope of the iteration is defined by an iteration kick off (IKO) where initial objectives of sprint our outlined. Work is broken down into stories which are chunks of deliverable functionality which have value to the business.
Every day there is a progress report from everybody (called a daily SCRUM) which outlines:
- what they have been working on yesterday
- what they are going to work on today
- any blockers to their work
more information on SCRUM can be found here
So Agile takes the best of these in order to produce the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
So what does this actually mean for a business ?
Individuals and interactions over processes and tools: So this is all about communication and improving communication between your different teams (Project Managers, Business Analysts, Quality Assurance, Developers and UX designers). So to tackle communication issues we use a number of techniques:
- we have an open plan office so everyone can see each other
- pairing happens across multiple disciplines (e.g. UX & Dev)
- We all use chat clients to talk to people in remote locations
- We have video conferencing technology to talk to people in remote locations
- We all use the same tools when we work on stories
Working software over comprehensive documentation: Now this does mean stop writing down everything you do as this will get you nowhere. it means writing down stuff that people are actually going to read or care about in order to deliver software. So we don’t have 200 page requirement documents or hugely complicated architecture diagrams because of 2 reasons:
- People don’t read them
- They change so fast that it’s pointless keeping them up to date
So what’s the alternative? Break chunks of work down into small bits of functionality that delivers value to the business. An example could be: “As a user i want to search for makes of cars from the Homepage”. This would then be broken down into a list of actions that a user could do. Now this means that the story has all the requirements captured in order to deliver it to live without updating and editing a massive requirements document. The benefit of doing this is that a story becomes more adaptable to change
Customer collaboration over contract negotiation: This boils down to working with the customer constantly to deliver something they actually want rather than showing them something at the end of 6 months and it’s all wrong. We do this by having product owners who we showcase stories as soon as we feel they are completed. This means that when software goes live they have already seen a series of interacting parts beforehand
Responding to change over following a plan: I touched on this point earlier about making stories adaptable to change. One thing that i can guarantee is that if you have a large requirements document up front with very little interaction with product owners whilst you are building it is that by the end of it you will have delivered something they don’t want. Requirements change all the time and Agile allows you to be adaptable to change by having stories which deliver small amounts of functionality. So if a requirement changes, no problem. If possible including in the story you are already working on. If the change is too large then raise a new story to deliver that functionality next time
Ok. So How do I start doing Agile?
So make no mistake, Agile is a big change for organizations. It is a different way of working in order to deliver business value and it will take time. One option is to use consultancy companies who specialize in making companies Agile. This is great but can be expensive. Another option is attend free talks on Agile and gather evidence to drive change yourself. With any large change, start small and work your way up
Will Agile make me deliver software faster ?
The jury is out on this one. Agile is no silver bullet and you do have to put the time in to make it work for you. The great thing about Agile is that you can customize to your business need. Personally, i feel that it might not make you go faster (versus something like a waterfall model approach) but it will deliver higher quality software which in turn can improve your time to market.
So to summarize, Agile is a way of working which uses techniques from different disciplines in order to tackle the problem of developing software. It can be customizable to your needs but you need to put effort into it if you want to get benefit from it