The statistics are deplorable. Even as late as 2009, less than ? of projects are considered successful (on-time, on-budget, satisfactory functionality and quality). The rest are either challenged (gross problems with schedule, budget, quality and/or functionality) or canceled altogether.
A lot of executives fail to appreciate the inherent complexity of software development that prevents it from being effectively managed within traditional project management frameworks. No amount of work-breakdown structures, PERT analysis or scoping workshops can guarantee the predictability of a sizable software project.
The Birth of Agile
It is encouraging to note though that there is gradual improvement in the success rate over the years. Success rates in 2006 and 2009 are twice that of 1994. The most recent Standish surveys show that of the projects that were successful, the respondents have often reported one particular factor as a reason for their success - the practices of Agile Software Development.
In 2001, seventeen thought leaders of software development met to attempt to synthesize the various methodologies that they have been developing and practicing independently. While they were not able to agree on a single methodology, they did produce a statement of common beliefs.
This was the Agile Manifesto:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the left more.”
While the various Agile methodologies do not agree on all their practices, core to all of them is the importance of collaboration, especially face-to-face communication and natural human interactions.
Agile Practices of Collaboration
Agile is not solely about collaboration, since there are many aspects of Agile that involve such technical concerns as the way programmers write their code or the automation of certain processes in the software development lifecycle. The focus of this article is on the collaborative aspect of Agile, while noting that this aspect is only part of what makes up Agile Software Development.
One Team.
For the other practices to make sense, we need to first establish the Agile concept of “One Team”. This means, that everyone that has a stake in the project - customers, developers, quality assurance, marketing, project managers, etc - should consider themselves one team. Every member of the team wants the project to succeed, to the point that one will take on another’s role in order to achieve a project’s objectives. For example, programmers can help in testing, and marketing can directly engage programmers in helping the programmers understand the business value of what they are building.
Common, Open Work Area. No Cubicles. Big Visible Charts.
The first thing one usually notices in an Agile development team that’s in stark difference to other organizations is common work area and absence of cubicles. Every member of the team - quality assurance, project manager, business analysts, developers - sit in the same room, and usually at the same large table. The large table is usually surrounded by white boards and big visible charts.
This environment provides natural communication throughout the day. Issues are resolved within minutes via casual conversations with teammates, often with the use of a whiteboard, referring to a chart, or sharing one’s computer screen. The environment is also conducive to focus on the project, since one is surrounded by charts and discussions about the project, and since one’s activities can easily be seen by others.
Contrast this to the environment found in many IT organizations where the different members of a project team are separated, often on different floors! Often simple issues take an entire day to resolve since communication occurs unnaturally through email. Face-to-face communication can only be done in scheduled meetings. Team members often report to different bosses. It’s next to impossible to get the entire team to be in a single “zone” of focus.
Stand-Up Meetings.
Each day at a fixed time, the entire Agile team has a quick meeting. This meeting is not for status updates. Rather, it is an opportunity for people to raise issues and for others to volunteer to help with those issues. Again, this is a natural way for the team members to find out about issues early, and to volunteer their time to help other teammates resolve their issues.
Contrast this to usual projects where issues are discovered only late in the project, when they have become more difficult or expensive to resolve.
Short Iterations & the ‘Product Backlog’.
These two elements are the most well-known aspects of Agile. The various features of the project are organized into a prioritized list called a “Product Backlog”. The Backlog is prioritized by the “Product Owners” or “Customers” - those with the business interest in the project, such as users, company management, or the marketing department. The Backlog is prioritized mainly along business value, but Product Owners may opt to prioritize features with somewhat less business value but which will be quicker to build and therefore can be released earlier.
The development team then delivers a working system in short iterations, usually two weeks each. In each iteration, the team delivers a working system - meaning that the system is deployable, usable, and well-tested. The team starts with the high priority features listed in the backlog and works their way down the backlog with each iteration.
The result is that with each iteration, the Product Owners receive a working system with their most high-priority features implemented, which they can begin to use at a much earlier date than with traditional projects. The short iterations also give the Product Owners a chance to review the delivered software and make changes to the Product Backlog before the start of the next Iteration. This opportunity to review and make changes is difficult to do in traditional software projects, when working products are only available towards the end of the project, when changes are difficult and expensive.
Collective Code Ownership & Pair Programming.
In Agile, code is not considered the ownership of one programmer or another, but of the whole team. Each team member is free to change code as needed in order to move the project along. This avoids delays or poor workarounds because work is blocking one person or the other.
Of course, it goes without saying that each member of the team must have the skills and discipline needed to make sure that they don’t break the codebase in the process of making modifications. Also, it’s important that the work of one programmer is reviewed by others. A unique practice in Agile is that of Pair Programming. Programmers in Agile teams would often work side-by-side on a single computer. This is so that they can review and discuss each others work while they are writing their code. This provides instant “code reviews”, and the result is higher-quality code, as well as opportunities to learn from one another.
Other Agile Practices
The practices I discussed above are only scratching the surface of Agile. There are other aspects of Agile that involve planning, design, code, testing and process automation. I hope this article provides motivation for the reader to do more research on Agile Software Development.
