Agile 101
Pat Kua More than a decade ago, a group of notable individuals found ways of working that were distinctly different to traditional waterfall management practices for software projects. It worked for them, allowing them to deliver better software for their users, more frequently. Excited about what they were doing, they wrote papers, presented at conferences and found other, like-minded people working in similar, yet different manners. As the Agile Manifesto describes, they organised a meeting in 2001 to find an umbrella term that let them identify with each other. Agile software development is the result.
Agile software development comes in many different flavours and forms, being an umbrella for specific methodologies such as, but not limited to, Extreme Programming (XP), Crystal and Scrum. Many of them share similar characteristics taking incremental and iterative approaches to planning, implementation and deployment phases of software projects. Each methodology depends on feedback, raising visibility into aspects of software projects that normally go unnoticed or channeled to specific individuals. This additional information gives everyone the ability to make better, more informed decisions earlier, and the ability to adapt to continually changing circumstances and priorities. An important characteristic about agile methodologies is that they demand frequent releases to their customers. Where it is not practical to release, at the very minimum, demonstrable and potentially shippable software is the next best thing.
You should not find anything mysterious about working with agile practices. It's simply trying to deliver value, faster and earlier. At its most basic, agile methods encourage completing parts of a system with the highest value, delivering them as early as possible. Different practices let teams do this without compromising quality.
No longer should end users need to wait for a complete system for them to be built before being able to derive tangible benefit from it. In order to do this, agile's focus is on disciplined ways of working that improves the quality of communication, increases the opportunities to learn from continuous feedback and to reduce unnecessary complexity and overhead that needless rituals bring. As an example, continuous retrospectives repeated throughout the life of a project give teams the ability to reflect, and continually adapt their processes to suit their situation as it develops.
What does an agile team look like? Different people have different metrics, but at the heart of it, agile teams deliver high value solutions to end users on a frequent basis (every couple of weeks). They build systems from end to end, instead of layer on layer to provide useful, demonstrable functions earlier than later. They use richer forms of communication favouring conversations over just passing documents back and forth, and building in numerous feedback loops to continually steer a project to success. They raise visibilities into issues earlier based on real data about how the project is being built instead of relative to a plan developed at the very start of a project. By looking at all the dimensions required to deliver software early they uncover risks otherwise found much later in a project's lifetime. Fact-based information gives investors a more powerful set of choices to decide upon instead of simply hoping for the best.
See also: Manifesto for Agile Software Development