To deal with endless change the industry seems to have settled on Agile software development. However the original definition of Agile coming from the Agile Manifesto in 2001 hasn’t really survived. All these techniques call themselves agile but often it’s just a popular label rather than something deeper. Dealing with change is not new and existed before the word Agile.
Before the manifesto
The Waterfall model is the classic heavyweight engineering method. This has a strict separation between a series of phases: requirements capture, analysis, design, coding, testing, operations. Each phase should be completed before moving on to the next. However if problems occur or changes are required at later stages then this necessitates returning to and repeating earlier phases. Any changes are likely to result in a much longer and more expensive project. This technique favours well understood technology with clear goals for it’s use. Even some of the originators of the model acknowledged problems with the dogmatic application of it.
More incremental approaches take phases of the waterfall model and turn it in to a cycle, I learned this as the spiral model. A project is the result of many cycles. Early ones will focus more on capture and design but may include coding. Later ones would focus more on coding and testing but may still include design. By including some coding early on their is the possibility of discovering problems early. By including some design later on it encourages leaving flexibility to cope with changes that may be required. This technique is more open to less understood technology.
Even more flexible approaches were taken in extreme programming. Here the expected that customers will change their requirements over time as the problem is better understood. Therefore the method concentrates on high quality but flexible coding using: pair programming, code reviews, unit testing and sticking to essential code. A short release cycle gives high visibility for progress allowing for course corrections. However with an extreme focus on the short term this can miss out on long term savings that planning and investment in code can bring.
That’s just a couple, there were others:
- Rapid application development
- Unified process
- Dynamic systems development method
- Feature driven development
They mix together practices, iteration and cycle times in different ways, plus a few extra details for each method. Then a bunch of people came together with experience of these and came up with the manifesto.
The Agile Manifesto
The Agile Manifesto starts with some values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
And twelve principles with a similar feel to extreme programming. The embrace change, short development cycles, close working relationships and simple working software.
Deciding to follow the Agile Manifesto doesn’t give you a rulebook. It’s the start of a journey and not the end. The team and the customer will have to work together, continuously, in order to work out what development will look like. To me this sounds as though it needs the right team of people and the right customers.
However without process and tools, which it doesn’t rule out but does de-prioritise, this is a hard to sell to companies. Literally companies are not going to pay much for something that can be printed on a couple of sheets of paper.
After the manifesto
My first proper experience of Agile was Scrum. In contrast to the Agile Manifesto’s rejection of processes Scrum has many. You are expected to have daily stand-ups, retrospectives and sprint planning. Some people have specific roles, product owner and scrum master, with specific responsibilities. Working time is divided up into sprints which must occur on an fixed cycle. You might well end up using specific tools in Jira to help with all this. It all tells a story that if you’re not doing it the Scrum way then it’s not being done right. That goes along with the accredited courses that teach you the Scrum way of doing things. The product backlog provides the mechanism by which future tasks can be refined and updated as new information becomes available.
I’ve also had a little experience of Kanban where one of the keys to have a board that can visualise current situation. Work is restricted more by the number of tasks in each state of play than specific cycle times. Expect to see many similar tools to Scrum perhaps with a different focus.
Again, that’s just a couple. The older methods are still out there, sometimes with a new coat of paint. Searching around I can also see:
- Fluid Scaling Technology (FAST)
- Scaled Agile Framework (SAFe)
- Large-Scale Scrum (LeSS)
- Disciplined Agile
- Spotify Model
As you can see they often want to have a good acronym.
In the end
I’m not an expert in Agile, just someone who wanted some background in order to make look for better practices.
A lot of what is called Agile today seems to be down to marketing. The future was, apparently, Agile so any new method you try to sell has to have that branding. Then some projects don’t work and people start to wonder if Agile is the problem, despite all the different flavours that are out there.
People want to deal with change but also want to have a timeline for development. Even without change estimation is hard. I don’t think this is a solved problem and it feels difficult to research as well. A lot of promises but it’s hard to tell if they will pan out. At least I’ve got a few things to compare anything new against now. Hopefully I can come back and explore some of these in more detail.
Leave a Reply