There is growing excitement about the practice of agile development. Impressive results have been achieved by agile teams, and today it’s regarded as one of the more appealing alternatives to traditional ways of building systems.
It may also help developers secure their jobs long after their peers are swept away by market forces.
Agile development embraces change. Under the methodology, scope creep is good because it can be used to keep the project aligned with the business. Short delivery dates and ruthless testing allow agile projects to delivery quality while also embracing change. It stresses working software over documentation, people over processes and talking to customers instead of negotiating with them. See www.agilemanifesto.org, home of the Agile Manifesto, for more information.
Agile teams work face-to-face, interact with users often, deliver working software frequently, and have a high commitment to excellence and simplicity. Included within the agile family are Extreme Programming, SCRUM, DSDM and Feature-Driven Development, among others. Visit the above Web page and you’ll see that a long list of professionals have already signed the Agile Manifesto.
One important side effect of agile development is that it’s local – remote outsourcing doesn’t work.
But responsible professionals need to understand when, where and why to apply agile…and to know when agile isn’t likely to work.
First, know that success with agile development isn’t automatic. If the rescue mission is important enough, an agile team can get away with breaking (almost) any rule. The end justifies the means. But what is allowed for a critical rescue mission may be not work as well if attempted by a team working on a less important project.
Every successful agile team needs a “user” who can speak for the stakeholders. As they will be developing a new working version of the software every few weeks, frequent decisions will be needed about how to address system issues. Waiting days or weeks to get a decision from users doesn’t work.
A good agile team will not over-engineer or under-engineer the system. A design intended as the foundation for all future work will fail – the future is too hard to predict. But constant vigilance is required to uncover the basic simplicity behind the flood of complex details. Getting the balance right is key.
And understand that agile will never get a chance if the business case for it isn’t strong enough. One problem is with the nature of what agile can promise. “Give me X dollars and I’ll deliver a working version of the software in few weeks,” one might say. But the first, second or third working version may not be good enough. It’s not going to be an easy sale.
To make agile work, keep these three ingredients in mind: frequent delivery, which limits the risk and allows users to guide development; open development, which allows the team to own the entire software system; and aggressive simplicity, which requires team members to focus on quality and actual delivery.
How can this work? In traditional development external controls of are replaced by internal controls, usually imposed by social structure and team processes. A strong social coercion is imposed on team members. Not all developers are willing to accept this.
Agile is also one of the best ways to develop when freezing the requirements isn’t practical. But it isn’t needed when the requirements can be frozen.
Agile will be one of the few remaining ways IT professionals will be able provide local development services.
