Once upon a time, in the bad old days, projects were spec'd out well in advance. Reams of developer documentation, design documents and specifications were written by "software architects". The whole thing was signed off on by managment, and months into the project, the actual software development would begin.

The architects, having conceived of separate parts of the system in their separate ivory towers, and having cashed their cheques and left the building, would have passed on their great wisdom to the programmers, whose job it would then be to translate their documents and drafts into working software.

And naturally, any issues found when attempting to implement the solution would require rounds of meetings to sort out. Architects would have to be rehired, or worse still, ignored. Software would just happen.

As for software testing, it would be the bailiwick of very harried folks, getting the software mere days before their (oft-delayed) release date and subsequently being micromanaged to the hilt to make SURE no bugs crept out with the software.

Agile changed all that.

Agile's PRINCIPLES are outlined in a manifesto document that's already been noded. But principles are one thing, what are the common practices that make this model work?

Product organisation

Products are typically organised into small iterations called sprints whose main goal is to define two to three weeks' worth of work with defined goals and measurable results. At the end of every one of these, there should be tangible and demonstrable products to show to the customer (either the explicit customer, or the customer's advocate). This results in constant, measurable progress, but it also means that the customer is constantly involved in the shaping of the product, from start to finish.

It also means that the customer can see the product at every stage of its development, play with the results, and approve or disapprove of the direction in which it is taking.

Work is divided into sprints ahead of time, and stories (a story is a description of some service or process the software is to perform) are defined. At the beginning of every sprint candidate stories are chosen to make up the goal of the sprint, and the development team then estimates the size and level of effort of work of each story (measured in "points", an arbitrary measure of size). Then, the stories are broken up into tasks and the number of hours for each are estimated. After a while the team gets good, through experience, at figuring out how many "points" can be achieved in a sprint, and get more adept at estimating task size in hours.

During the sprint, developers take tasks, assign themselves to them, and as they're completed, mark them off as complete. This can either be done in software (like XPlanner) or manually, by sticking cards on a wall and moving them from one spot in the wall to the other. Either way, anyone walking by can see how much has been accomplished at any given time, and isolate problems, pull in more work, or have a meeting to see what's holding up existing work.

At the end of each sprint, the progress of the team is demonstrated to stakeholders, and then the team usually meets to talk about what went well and what went poorly.

Project implementation

Two VERY complimentary technologies that most Agile projects make heavy use of are Test Driven Development and Continuous Integration.

Test Driven Development insists that software tests are written before the software itself can be written. In other words, before you write a function to add two numbers, you need to write software (usually referred to as unit tests) that will exercise it, and use as many representative tests as will be required to describe correct behaviour. In the above case, you'd want to test adding zero to a positive number, a positive number to a positive number, a negative number to a positive number, etc. Software is considered complete when tests pass. This is in marked contrast to earlier ideas of over-architecting software: the principle of YAGNI (you ain't gonna need it) says make it work, THEN make it work better. Software products to make Test Driven Development work include JUnit (for the Java programming language) and its siblings CppUnit (for C++), NUnit (for .NET development) etc. These products not only provide a framework for the development of these tests, they also provide a way for them to be automatically run, and the results can drive any of a number of other processes.

In order to make your software work with software which either does not yet exist or will be difficult to automate, products like EasyMock allow you to create "mock" versions of software entities that will behave like their real life counterparts.

The second is Continuous Integration, which means that some build system builds the software on a regular basis and runs any unit tests that exist. It is easier to fix a bug when it's introduced into the system (because, for example, someone checked in code in one place that turns out to affect the system elsewhere) and the changes are fresh in the mind of the development team, rather than later when they are discovered in testing. The two go hand in hand. No software exists without unit tests to test them, and every time changes are made, the software as a whole is automatically built and put through its paces by a machine, with any compilation problems or unit test failures reported immediately. Cruise Control is the most common continuous integration product.

As a result, a team can react quickly to any inadvertent bugs in the system as well as any changes required by the customers or stockholders. Because the customer (or his representative) is always present, software is not created in a vacuum. The higher level leads and the grunt developers are always cheek to jowl, so there's a constant flow of communication between all concerned. Because details are built into the system in two week integrations, the customer is near-constantly given feedback as to how the system is being built. Machines, having been set up right, constantly verify and document all built code. As the sprints follow one after another, the project takes shape according to the wishes of all concerned, but to the best of anyone's ability, its quality is constantly being evaluated and preserved. Technically, one could dip into the build system at any point and retrieve stable, working and demonstrable software.

This represents a quantum leap in software development methodology.

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.

E. F. Schumacher, "Small is Beautiful", The Radical Humanist: volume 37, p. 22.

I work in a world of bureaucrats, pseudo-engineers, and business analysts. Sprinkled among these, I have become personally responsible for the output of a handful of software development teams comprised mostly of programmers. I share this with a programmer friend of mine. He handles the technical leadership responsibilities, and I cover most of the administrative and budgetary concerns. In the past several months he has begun implementing a new development model for our teams, and it has been a significant enough improvement that we are interested in extending it to our other software teams. As a prerequisite for us taking on this new role, we requested that we be allowed to attend some in-depth training on the process. And so I recently found myself at an annual Agile Alliance training conference.

Leading up to this conference, my knowledge of Agile Development remained limited to those aspects that immediately impacted my day-to-day work. I started seeing some of our teams standing up, which of course scared the hell out of me to see 10 people I'm responsible for tasking seemingly standing around in a circle for 15 minutes every day. Management started asking questions. My co-worker started using terms like "sprints" when referring to the week's work, and "story points" when asking one of the programmers about a particular job. And none of this was clear to me, as I tried to piece together this new way of doing business.

In the past, we managed our software projects by what is called the "Waterfall" method. This involved monstrous Microsoft Project graphics depicting very linear, rigid, and often long paths from start to finish. Based on the old Requirements, Design, Development, Integration, Testing, and Deployment structure, this model did not respond well to last-minute changes or unexpected situations arising in the middle of development. Under Agile Development, the basic idea is that work is broken down into short durations (sometimes called Sprints). And by short, generally these last between two and four weeks. What can get accomplished in 2 to 4 weeks you ask? Well, that is another aspect of Agile Development. Previously, it has been common to separate out people by functional area, slapping all of the programmers together, the testers together etc. Under an agile model, development efforts are broken into collaborative teams containing representatives of all functional areas responsible for getting the product out the door. This team begins with an initial user story, which is a very short statement that frames the problem to be solved. For instance, an initial user story may be something like, "As a traveler, I want to check in with my rental company online as soon as my plane lands." This statement is broken down by the collaborative team (led by the Product Owner, who represents the stakeholders , in this case the travelers) into all of the discrete portions needed to solve the problem statement. At this point, the team (including the owner, developers, and testers) prioritize the tasks. Large tasks are broken into successively smaller tasks, and then as a group the members assign a value to each task that represents a relative level of work it would require. This is done in a variety of ways, including planning poker, but ultimately results in a distribution of story points for every task representing relative levels of effort. This may sound complicated, or time-consuming, but once the group understands the process, this can be completed rapidly.

At this point, Agile Development really starts to prove itself. An initial estimation of how many story points can be completed in each sprint is made, and work begins. The focus is on treating each duration as its own release. By considering the possibility that the current Sprint might also be the last sprint before it goes live, a new clarity is developed that was previously impossible under the Waterfall method. As sprints are completed, review meetings highlight what worked during the previous sprint, what can be improved in the next one, what are the user priorities for the next sprint, and how many story points were captured. This number can only be actual completed tickets, work in progress is not counted until it is completely finished. By reviewing each sprint in this manner, a velocity can be established for a reasonable amount of story points that can be closed by the team during each iteration. This provides a much more accurate forecasting capability over previous software management models. By reevaluating user priorities, development efforts are much more responsive to changes midstream.

Agile Development has been around for over a decade but recently has seen a surge in attention. Major corporations, such as IBM, have begun actively implementing agile development models. While these may vary slightly from implementation to implementation, they share as a common denominator a link to the Agile Manifesto. Below is the Agile Manifesto (emphasis added by me, from http://agilemanifesto.org/):

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan


That is, while there is value in the items on the right, we value the items on the left more.

©Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.
This declaration may be freely copied in any form, but only in its entirety through this notice.

Principles behind the Agile Manifesto
We follow these principles:

  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.

More information can be found at the Agile Alliance, a nonprofit organization that supports the continued development and implementation of the Agile model.

Log in or registerto write something here or to contact authors.