The 7 Heresies of Agile
The dark arts that helps IT projects succeed
IT projects are often like climbing to the top of the ladder only to find you're against the wrong wall. The various causes of project failure include poorly defined and changing requirements, poor collaboration between stakeholders and developers, poor teamwork and poor leadership.
Agile project methodologies are forward as a solution, particularly in the case of software development. Evaluations of projects ran like this are finding them more successful.
Making Agile approaches work is not just a matter of following processes and procedure (which by definition would not be very agile). It is also about changing attitudes, culture and teamwork. The Agile Manifesto is clear on people over processes.
But be warned some of these new-fangled ideas - with origins in Japanese manufacturing - may disrupt traditional management wisdom. Here are seven strange heresies that the agile methods make but explain how they work.
#1. Change is Good
It was Heractlitus who said
"The only thing that is constant is change".Many people don't like that and avoid change and changing. They are comfortable with routine or seek certainty. The Agile Manifesto has as one its main tenants "Responding to change over following a plan" and amongst the 12 principles, is to "Welcome changing Requirement" as "Agile processes harness change for the customer competitive advantage".
In a changing and uncertain world of volatile markets those adapting to change quicker are the ones most likely not to fail. Better still be the ones making those changes. Being resilient to change, involves moving on from failures, quickly, and to learn from them. Regular reflection on what worked, what didn't and what can be done better next time is part all agile methods.
#2. Minimising Work in Progress
For many people it is important to be seen to busy and multi-tasking. However the reality of having too much on your plate means there is task switching. This reduces focus. This idea comes from Kanban. This is the "Signal Card" method from Japanese manufactory, but applicable many different types of business workflows. Work is visualised, possible via a display board, with the flow running left to right from a back log through work-in-progress to completed work.
Limiting what individuals or teams have as being considered as work-in-progress means others who may have less on their plate are free to pick from the back-log, which will be prioritised, or there is more capacity to add to existing work. This approach is more responsive to changing priorities and the unforeseen. The overall ability to complete work is unaffected as this is just a way of distinguishing between to-do and being done and by whom.
#3. The Iron Triangle
The Iron triangle centres around quality with time, cost and features as the three corners. The usual scenario has features as fixed which makes time and cost the variables quantities, leading to the possibility of over-running on both and this is a common problems associated with IT projects.
Agile inverts this triangle. The required features or Stories, as they are called in agile, are prioritised using techniques likes MSCW (must have, should have, could have and won't have) these them delivered accordingly in the time-boxed development phase, or sprint as called in the SCURM method. Time and cost are fixed, meaning potentially difficult decisions have to be made regarding what gets left out. The benefit being that at least something of value gets delivers on time and excess time does not go into features that may never get used.
#4. Optimise the Whole
The more traditional approach, to IT projects compartmentalize into sequential stages which cascade for one to next, which is why they are often referred to as water fall methods. The tendency here is form teams around functional roles, such as analysis, design or testing. With any splitting out of people into teams there is a danger of forming silos. This is where there are boundaries form in the project delivery across which delays and misunderstanding can get introduced, as the proverbial buck gets passed "signed-off" between the "Then and Us", hopefully to forgotten about.
Using interdisciplinary teams working on a product from concept to cash will focus them on the value and purpose of that which they are developing. Agile methodologies encourage collaboration, and recommend getting customers and stakeholders embedded in development teams. Specifically the agile manifesto states "Customer Collaborations over Contract negotiation" and "Working software over comprehensives Documentation", and also amongst its principles is that business people and developer must work together daily and the belief that face-to face conversations are the best way to convey information.
#5. Self-Organising Teams
The Agile manifesto states "Individuals and interaction over Processes and Tools" and back that up with principles to "Build Project around motivate individuals" and that the best systems "emerge from self-organising teams" Giving people a say in how they go about their work gives them more ownership of it. The results is better quality, productivity and innovation. This is particular true in complex, creative knowledge word. Allowing a team organise themselves will encourage discussion and collaboration, this may lead to creative compromises being made between induvial. Relinquishing command and control, to lead from the back, can take a lot of trust and courage.
#6. The Last Responsible Moment
A problem associate with IT project is the time taken in upfront planning end being wasted by changing requirements. A solution to this is making plans at the last responsible moment. Also known as deferring commitment and options thinking. This is where decisions get left for later, or the last moment it can be made. The idea is that as much time be taken to learn about the problem and the options as reasonably possible, and not beyond a responsible moment where an important option is no longer available.
#7 Simplicity
Often there is a tendency to let the inherent complexity of IT or business processes to spiral. Courageous decisions about priorities, when to re-write a program or to scrap some ones pet project, may be necessary.
The Agile Manifesto has Simplicity - the art of maximising the amount of work not done, as a supporting principle. This is a cornerstone of many agile methodologies such extreme programming and Lean software development.
Steps to achieve simplicity include identifying and eliminating wasteful processes and activities. Removing superfluous stories from a backlog to concentrate on producing a fit for purpose product. Also code refactoring - the process of re-writing code, so it still does the same job but is easier to read and modify - is a simplifying process.
Agile Methodologies are most applicable to complex and changeable environments. Whilst they were developed for programing projects they are applicable to other areas of IT and also other types of business projects may benefit from this thinking.
Read More
Agile Foundations: Principles, Practices and foundations. Peter Measey, British Computer Society 2015
Manifesto for Agile Software Development
March 2016
| Duncan Stonebridge.
Back
