The current economic downturn is a new test for Agile, until now Agile has been promoted in a growing economy. Proponents of Agile have emphasized how it improve competitive advantage and helps a company out-compete its rivals.
Now companies are concerned with simple survival. Today's managers are concerned with cutting costs, improving cashflow and managing without credit. Organizational change and process improvement are not top of the agenda. Promoting Agile in this environment is something new.
The first question we need to ask is: How, if at all, can Agile help companies manage in the downturn?
The second question to ask is: Does the downturn make switching to Agile more or less attractive?
How Agile can help
In this particular downturn conserving cash is more important than ever.With banks reluctant to lead and sales slowing cashflow conservation is vital to company survival.There are two ways in which Agile development can directly help.
The first ways drawn directly from the practices of manufacturing companies: reduce inventory.
Reduce inventory
Inventory is code that has been written and not delivered to production; it is requirements documents that have been created but not coded; it is project plans for software that may never be built, and it is software stuck in test because it has too many bugs.
One company I worked with last year took about four months to develop a new software release.They then took close to six months to test it and two more to deploy it.This costs the business–features were completed and paid but did not start earning revenue for over half a year.
The company had to fund this development long before it saw the benefit.That is money is lost cash–perhaps it was a loan that they could not secure today.The money is only repaid when the software starts to deliver value, either through cost savings or generating revenue.
By shrinking the time between software being developed and it starting to earn a return Agile can make a difference.
Deliver sooner to generate sales and/or savings
Shrinking the development cycle will not only reduce inventory it will bring forward cashflow.Some software is built to generate sales–either by selling the software itself or by facilitating the sale of something else.If the software is delivered sooner that sale can happen sooner.
Other software is built to improve the operations within a company.In the current environment such changes will be aimed at reducing costs so delivering software sooner allows costs to be reduced sooner.
In either case a tight focus on the objective will help.Each iteration needs to bring the goal noticeably closer.Ultimately it should be possible to measure the value of an iteration in costs saved or sales immediately. Agile development should out perform traditional development that can only show progress against plan and not cashflow.
Layoffs
Until now the productivity improvements provided by Agile would be used to produce more product.A booming economy created job opportunities which encouraged people to switch jobs so natural wastage would remove any excess capacity. Today there is less demand for products, lower staff turnover and more a need to reduce costs.Consequently increased productivity may lead to redundancies.
Agile is particularly vulnerably to job cuts because of the emphasis on self-organizing teams and continual improvement through learning.People will only speak openly and act independently when they trust the organization.When people are being laid off and decisions are being taken about who to keep and who to let go trust is lost and ideas unspoken.
When it comes to layoffs companies that have yet to make the switch to Agile are in a different position to those who have already switched.Such companies may look to Agile as a way to increase productivity while saving costs–the proverbial do more with less.
Announcing a switch to Agile with layoffs to come later is unlikely to facilitate an easy change. It is hard to motivate a team to change when a successful change means jobs losses.
When layoffs must happen it is better to cut staff first, then change practices.As hard as this seems this allows a clean break with the past and allows people to begin the transition to Agile without the worry that the change will itself lead to cuts.
Taking this approach will not be easy.Managers need to act hard, then swiftly change tack and persuade people that they genuinely want a change of style.
Managers who attempt a switch to while hiding coming redundancies run counter to Agile principles.Agile demands openness and trust.Hiding coming cuts while talking the language of trust is an act of bad faith.
Such an approach also suggests that managers have unrealistic expectations.In my experience teams do not become Agile overnight.With support (training and coaching) at least six weeks is needed before benefits are clear.The complete journey to Agile takes many months longer.
For those companies that have already made the switch to Agile the issues of layoffs are different. Agile places people centre stage–"Individuals and interactions over processes and tools"–so layoffs are potentially a bigger threat to effective working.
Keeping true to Agile values and principles demands teams and managers find ways to reduce the wage bill without resorting to job losses.Simple wage cuts are often the simplest and fairest way to do this but other options should be considered.
Alternatives include part-time working, sabbatical breaks or unpaid vacation.Teams can switch to four-day workweeks or take an entire iteration off without pay.
In fact Agile working makes it easier to implement some of these alternatives.Pausing projects is far easier to do when the whole team operates on the same cycle and has natural break points.
For teams with an established velocity the effect of switching to a four-day week will be clear.With less capacity to do work it becomes more important to strictly prioritise the work and make sure the highest value is done first.Again, Agile teams who reprioritise regularly will have an advantage over teams which work to fixed priorities for several months.
Those on the team doing the work - developers, testers, product owners and such need to recognise that maintaining a sustainable pace sometimes means economic solutions.There is no point in a team delivering software while the ship sinks.
Layoffs are never easy, and there is no clean or easy way to do them.When faced with the need to reduce costs Agile teams and their managers need to respond with the same values and creativity they use in delivering software.The watchword needs to be: collaboration.
Companies which can manage this most difficult of issues will be far better placed when recovery finally comes.Agile companies will bounce back on the way up.
Change in a time of downturn
Faced with a downturn there are two possible reactions. Option one: act like an ostrich, put your head in the sand and hope the thing will blow over.This is quite a natural reaction and one I experience most mornings when I open the newspaper.
The second reaction requires more bravery: recognise the fact the world has changed and respond accordingly.One day we will probably get back to a 2007 style boom but it isn't going to happen soon.Even if things start to turn soon it will take a while before the good times are really with us.And some things will have changed forever.
Coming out of the downturn requires companies and individuals to change their behaviour.We are heading for a new world.Some companies may survive by putting their head in the sand, conserving cash and waiting for things to change but the ones that do change will come out of the downturn sooner.
So the question is: how will your organization change?The downturn is an opportunity to rethink how your company works.
The downturn is a time when the risk of change is lower.When times are good it may be possible to make things better but there is more to loose so the risk is greater.Why risk changing anything when good money is being made?
Now things are not so good there is less to loose.Change is the imperative, doing things the way they used to be done is no longer a given.As individuals and companies realise they can't keep their head in the sand forever change will occur.Whether it is embracing Agile something else, something must change.
Change has its own price - it doesn't come for free.Still, now is a good time to change.Agile has never demanded expensive tools the way some methodologies do.If you do feel the need for a tool then there is probably an Open Source solution.
Where Agile is expensive is in terms of training and consulting.While you can read the books and put the ideas into practice by yourself the change will go a lot smoother and quicker if you can afford some training and the services of an consultant - or more likely a coach - to guide you though the first few weeks or months.
Now it may be a good time to haggle on price, some training companies are experiencing a fall in demand as big companies conserve their cash.So try asking for a discount before you book.
Then there is the cost of the learning curve.There will be a temporary slowdown as staff master new practices and processes.Now is the best time to pay this price. Far better to slow down and re-skill when demand is low lowest than when demand outstrips supply.
In conclusion
In some ways the downturn changes little.What was good to do before the downturn is still good to do.Managing in the downturn is a lot like managing at any other time except you need to do more of it.
It is always good to reduce inventory, bring cashflow forward and minimise costs but when times are good it is easy to avoid making these decisions.Bad times sort the also-rans from the winners.
The downturn plays to Agile's strengths and makes it less risky for companies to make the switch.The real change is for those who want to promote Agile in the business.Promoters need to rethink their arguments and explain how the Agile approach can help companies ride out the downturn.
Provided you adopt the right mindset the downturn should be a great opportunity to push Agile adoption.
About the Author
Allan Kelly is a London-based consultant and interim manager specializing in Agile adoption. His first book, "Changing Software Development: Learning to be Agile" was recently published by John Wiley amp; Sons. He is a qualified Product Manager and Project Manager, and holds a BSc in computing and an MBA in management.
