Just what is agile software development? In 2001, a group of methodologists got together to agree on a common set of guiding principles around effective software development. Rather than summarize their agreements here, I’ll point you to their “agile manifesto”.
From a pure definition standpoint, agile is a conceptual framework generally centered on iterative and incremental delivery of working software, driven by the customer. The iterative part suggests that we are repeating, or iterating, a complete lifecycle of development over a short, fixed span of time. With each of these iterations, we ship some working subset, or increment, of features.
Agile Methods
Several agile methods exist. Some of the more well known include extreme programming (XP), lean software development, Crystal, DSDM (Dynamic Systems Development Method), Scrum, and feature-driven development (FDD). What they generally have in common is the IID aspect, but more importantly they hold similar values and principles. I’ve listed a few things that each method emphasizes:
- Lean – Move closer to customer, shorter cycles, eliminate waste, decide as late as possible, empower the team, build in integrity
- DSDM – Empower the team to make decisions, emphasize frequent product delivery, integrate testing throughout, promote collaboration and cooperation between all stakeholders
- FDD – Center development around the feature, create a domain model with domain experts
- Crystal – Emphasize people, gather techniques from other methods, improve communications, adapt the process itself (shrink or grow to fit)
- Scrum – Manage a prioritized list of requires on a product backlog, collaborate through daily standup meetings, exhibit the product upon iteration completion, use retrospectives to correct the process
- XP – Emphasize the values of communication, simplicity, feedback, and courage; use specific technical and collaborative practices, including TDD, refactoring, pair programming, continuous integration, open workspace, and automated acceptance tests
The Rational Unified Process (RUP) is also a process framework that centers on iterative and incremental development. RUP can be configured to support an agile process; one such implementation is the “Agile Unified Process” (AUP). However, the agile community often shuns RUP. They view it as unnecessarily “heavy” in its use of artifacts.
Note that these processes all emphasize the human aspect in software development. It’s important to understand the motivation behind agile software development. Agile largely arose out of frustration with attempts to apply “heavyweight” methods and phased approaches in an IID environment. IID is a great idea, but it’s difficult to sustain over any significant time.
Extreme programming, devised largely by Kent Beck and Ward Cunningham, is probably the most well known agile process. It arose from a programmer’s interest in maximizing the amount of time they could dedicate to coding software, as opposed to the amount of time doing other things potentially relevant to being able to deliver software. This includes time spent in meetings and in maintaining large design documents.
That’s not to say XP ignored non-programmers. It promoted a singular thread into the nebulous world programmers often think of as “the business side of the fence.” XP called this world “the customer,” emphasizing that in fact they should be driving everything, starting with just what we as programmers should build.
XP first started gaining popularity in the late 1990s. About ten years after its creation, Kent Beck published a second book on XP that demonstrated considerable refinement to the guiding principles behind the process. Over the years, XP’s programmer-heavy focus shifted more toward understanding how to mesh these practices and make them work in more than a small number of organizations. Today, XP is a reasonably mature process that is well understood by the many teams who have been able to sustain it for long periods of time.
XP has survived its “hype bubble.” As with any over hyped technology, you don’t hear nearly as much about XP now. Many teams abandoned XP due to their inability to make it work. Others embraced it and quietly went about applying it as best possible, learning how to continually ship working software every week.
At some point XP will likely begin to fade away, as better approaches take hold. But it will leave behind some important legacies: most notably, its heavy emphasis on specific technical practices, including test-driven development, refactoring, and continuous integration. Many of these concepts were borrowed or derived from other sources, but it was XP that brought them to the forefront.
Today we’re all familiar with unit testing through the xUnit family of tools (JUnit, NUnit, CppUnit, etc.). These tools are readily available and often ubiquitous–direct JUnit support appears in most IDEs. Much of that emphasis on unit testing came from Beck. XP’s heavy promotion of continual code refactoring certainly had an impact on the availability of automated refactorings in our IDEs.
What Does Agile Look Like?
Your experience will vary depending on what “flavor” of agile you use, but most agile teams have similar practices in place. Often what varies between agile teams is not the practices so much as their underlying philosophies and principles. Here is what you might encounter as you work on an agile project.
- Expect to work in a team that emphasizes cutting to the chase. They’ve been asked to deliver working software every week or two weeks. As such, you’ll rarely be asked to spend time working on large detailed design or requirements documents. You might instead be asked to contribute to designing automated tests, or to brainstorming ideas for new features on index cards.
- The outset of an agile project is usually short. You won’t spend weeks or months gathering and refining requirements, followed by working on a detailed design. Instead, you’ll gain an understanding of the high-level vision of the project. You might provide estimates that are used as the basis for a rough project timeline. You’ll contribute to architectural decisions–decisions about things that would be costly to change later. Note that detailed design is not one of these things!
- Once the project has begun, you’ll have a tough time telling the early part of it from the later parts. All work takes place in iterations of fixed length–most typically one or two weeks each.
- You’ll begin each iteration in a planning meeting lasting a few hours. The “customer,” who is represented by one or more individuals, who know the next most important features that the team should build, drives this collaborative working session. During this session, you might sketch UML diagrams or help refine test cases, in order to better understand what needs to be built. The meeting finishes when you and your team members commit to a set of features that you can deliver by iteration end.
- A very important aspect of agile methods that they all emphasize is delivering working software at the completion of each iteration. An iteration is not two weeks in which you do some coding, and then throw it over the wall to a QA team to test. Instead, the goal of the iteration is to update production software. That means software has to be fully integrated and tested before the completion of the iteration. Sounds challenging!
- From day to day, you get together with your team as frequently as possible to collaborate on building software. Minimally, you’ll meet daily for a few minutes to discuss who’s doing what and to discover issues exist. But the best teams view a 5-minute status meeting as barely adequate. You might work together in an open bullpen, in earshot of your fellow developers. You might even actively develop software in pairs, in order to improve the quality of the design and code.
- From a technical standpoint, most of the agile methods say little about what a programmer does from day to day. This inattention to technical challenges can introduce significant risks: how do we continue to deliver software week in and week out without rapidly degrading the codebase? How do we ensure that the cost to introduce new features remains reasonable, given that we’ve spent little time on up-front design?
- XP addresses these concerns with a handful of technical practices that ultimately bolster each other and purport to minimize the risk. For example, test-driven development and refactoring are core practices that emphasize continual attention to design and system quality. If you’re doing test-driven development, you’re changing how you actually program. You continually iterate through simple, short cycles of writing bits of test along with production code, followed by refactoring the code base to ensure it remains clean.
- Throughout an iteration, you’re not just trying to complete individual technical tasks. Instead, you’ve promised to deliver completed business functionality. This means you need an effective way to determine whether or not you’re done. You might use automated acceptance tests for this purpose.
- The business side of the fence defines acceptance tests. Some of your development work for the iteration might include automating these tests so you can execute them on demand, or as part of the nightly build. You might work in concert with a QA or testing team to help design and develop these tests. You won’t be allowed to ship the software until all of the tests execute successfully.
- When you reach the end of an iteration, you might be asked to demonstrate the newly-completed features to interested parties and stakeholders. You’ll also hold a retrospective meeting, in which you and your team reflect on the accomplishments and failures during the iteration. You’ll use the retrospective to decide how to make the next iteration more effective.
- You might find that your team was unable to complete all the features they promised for the next iteration. Even if you coded everything for a feature, the work is considered incomplete as long as any of its acceptance tests did not run successfully. The work gets put on the back burner, to be addressed in some future iteration.
- Overcommitment is a learning point, an opportunity to correct things. The amount of work you were able to complete is known as your velocity–your team’s rate of development. It’s intended to reflect how much work you can actually deliver. For the next iteration, your velocity is decreased by the amount of incomplete work. If you finish all features early in an iteration, you can increase your velocity by taking on additional work and completing it prior to iteration end.
- Iterations are framed by releases–the points at which we choose to deliver the latest version of the software to a production environment. Like iterations, releases also start with planning sessions. In an ideal environment, teams are able to release software to production with each and every iteration.
Agile software development is great for many situations but isn’t appropriate for every shop or even every team within a company. It’s also not a guarantee for success. It requires an appropriate attitude, an eye for spotting deficiencies in the process, and a willingness to correct the process itself with every iteration.
About the Author
Jeff Langr is a veteran software developer with a score and more years of experience. He’s authored two books and dozens of published articles on software development, including Agile Java: Crafting Code With Test-Driven Development (Prentice Hall) in 2005. You can find out more about Jeff at his site, http://langrsoft.com, or you can contact him
directly at jeff@langrsoft.com.
