What is Agile?
Agile is an interesting topic. Is it a process or a methodology? If I had a dime for every time I heard that question debated I wouldn’t be concerned with such things because I’d be retired on a beach somewhere.
Given Agile’s popularity, the line between trend or movement, and actual development practice, is blurred. It has become a buzzword that invokes a socialized meaning that often clouds the real meaning. When you get a chance, after you hear a developer or manager talk about Agile, ask what does Agile mean to them? Typically they struggle at first and then may offer some eccentric definition. Such is the nature of people
We glean and create meaning from our experiences – and we do so the most from social experience. Such is a highly subjective process. Even if we received Agile training, such training is only an introduction and it typically does not help one make the paradigm shift to Agile. And many concepts are not concrete enough for them to be useful enough to transform their practice.
To really understand Agile, one must understand the typical problems in software development Agile is hoped to address. In order to do this we need to go back to the grassroots movement: http://agilemanifesto.org/
On the first page you can get a feel for the motivation behind the birth of Agile. The founders recognized that the activities and artifacts of software projects distract from satisfying the customer. It seems they also recognized the distractions and other problems are rooted in human nature. By focusing on more effective communications, and delivery of real value (determined by the customer), Agile is expected to produce better outcomes.
To understand the how to do this, we need to visit the Twelve Principles of Agile (http://agilemanifesto.org/principles.html). If there is any list that might be used to determine if a software development shop is Agile, it would be these twelve principles.
The Twelve Principles of Agile are listed below.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Software development has some of the same problems as other engineering fields, but many of these problems are magnified in software development. The main problem is that the human factor is the most influential variable in project success. Writing software is an inherently personal, intellectual experience, much like writing a novel.
Now let’s say you wanted to hire a team of novelists. They are tasked with writing a best-selling novel along a particular theme and genre. Each have different writing styles and the concepts and ideas they have for this best-selling novel, are vastly different. Not only do they have to agree on the details of the novel, each piece has to flow nicely into the next as well. This difficulty is compounded by the difficulty adequately conveying abstract concepts and ideas in advance before the text is written. This is an inherent flaw in the social side of human nature that is out of scope of this post.
As humans, we have flaws associated with our reasoning but we also exhibit flaws associated with the group we belong. These flaws are roadblocks to communication. Ideas are believed to have been adequately conveyed, and those receiving may assume they understand the idea, but there is no evidence the conveyed idea was understood by recipients – until the idea becomes something concrete (like filled pages of a novel or software code). Even those conveying the ideas may not fully understand or have fully explored their own ideas.
The biggest issue is that the text of the novel has not yet been written, so knowing whether it is good text or even suits the intended purpose, or whether each piece of the novel flows well into the next, cannot be determined until it is written.
In comparing to other fields that design and build things, whether its a building, computer or car, the laws of nature dictate a lot about the project - laws that cannot be ignored, negotiated with or changed. Software on the other hand produces emergent laws of its nature that didn’t exist before. It can misbehave in ways only those emergent laws dictate.
Returning to the twelve principles of Agile, you’ll notice it suggests involving the customer early and often in a cyclic fashion, it focuses on communications and business value, and suggests considering the people on the development team. In following the Twelve Principles, we position team members and stakeholders to catch problems early and to know whether the project is on track sooner rather than later.
How Agile a team is should be determined by how they measure up to the Agile Manifesto, and ultimately, how successful their projects are. In order to develop a team toward being more Agile, one must first truly understand Agile.
