A Brief Introduction to Agile Austin TX

provided by: 
Originally published at Internet.com

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'ss 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