Share this
by Ben Hughes on 15 October 2013
The Agile Manifesto states that it values “individuals and interactions over processes and tools”. However many Agile Processes are very much focused on tooling and rules, adding structure and restrictions around something that, by definition, should be free of both.
In this post I refer to Agile Processes as standardised Agile approaches such as XP, Scrum and Kanban. Agile Processes provide key elements that should be adopted and crafted into a software development approach that works for you; they should not be adopted simply because they are expected. The best way to develop your agile approach is to know what is out there, and what challenges it was developed to overcome.
Separating agile (as per the Manifesto intent) from Agile Processes (standardised agile approaches) is crucial for discovering the strengths and weaknesses of both.
Agile Processes are an implementation of the Agile Manifesto intent, they sacrifice some of the core tenets of this Manifesto in order to maximise the output of the development cycle. This isn’t a bad thing; the widespread adoption of Agile Processes has facilitated a revolution in the software development world, promoting greater customer involvement to deliver software that better addresses the business need.
Processes can be wonderful; they can allow for the controlled self-management of a team while ensuring that the project goals are met. This is a key strength of Scrum—in essence the team runs itself once the sprint goal has been developed and agreed on. This is a great thing from a process point of view, but not necessarily from an agile point of view.
Scrum is an example of an Agile Process that is not necessarily agile. Consider the scenario of a change in requirements mid-sprint, or perhaps an urgent additional task that would provide a high business value return.
Theoretically in Scrum this feature would be added to the backlog and not be addressed until the next Sprint planning session, at which point it would very likely be picked up and then developed.
Within a true agile environment, this feature could be worked on immediately, with the client and the team discussing which in-progress or immediately upcoming tasks should be delayed to make room for the new task.
The Agile Buffet Table
At TechEd New Zealand this year, John Bristowe and Stephen Forte delivered a fantastic presentation The Agile Buffet Table: Building your own Agile Methodology. They discussed how the best approach for a development team is more than likely not going to be a clearly defined Agile Process but rather a mix of the key attributes of XP, Scrum and Kanban that allows your organisation to get the most out of agile, without being limited by externally defined Agile Processes.
Their talk also suggested a list of back-of-the-box features of three core Agile Processes. The features are of course generalised and not meant to represent the entire scope of these Processes. However, if you look at their lists of features at a high-level view, you can see that XP introduced a number of fundamentals to software development, Scrum added a strict process leveraging some of these and adding more, particularly around team structure, and Kanban added a monitoring system.
The aims of these three Agile Processes already suggests a single cohesive solution: take features from the XP pile for your key practises, take features from the Scrum pile to create a day-to-day process, and take features from Kanban to monitor how close you are tracking to your development goals.
The advent of ScrumBut
This is where true agility is seen, where your development processes reflect your individual requirements, rather than your requirements being adapted to meet your process.
This approach is already known by name, ScrumBut. This is what you get if you describe your process along the lines of “We do Scrum, but …” and then follow-up with a number of non-Scrum techniques. In the Scrum world this is seen as a negative, and if you are attempting to ‘do’ Scrum then it absolutely is.
I believe however that if your aim is to embrace agile as a mindset rather than a technique, this is the ideal solution. Begin with Scrum, and then see which rules work within your organisation and which do not – allow Scrum to support and enhance your development practises, but don’t be absolutely controlled by the rules.
Agility within software development is what is now expected and required from the industry. It is important to ensure that you adopt agility to enhance your development methodology – not just to control it.
About Ben Hughes
Ben is a Systems Analyst with Equinox IT’s Business Application and Product Development Line of Business. He holds a Computer Science degree from Monash University, Australia. Ben plays a key role on many of Equinox IT's software development projects, where Lean and Agile practices are used.
