After getting a head of gray hairs and a quickly receding hairline, I have learned that the simplest solutions are often the best. Having worked with Java since 1995 and various software development lifecycle methodologies over the years, I have seen things grow complex in these areas. Thanks to some new lighter-weight Java tools and agile methods, I can provide a fresh perspective on developing Java applications in an agile manner.

This article is different from typical Java articles for two reasons. First, instead of providing in-depth details on some API or cool tool, it provides a roadmap for building enterprise-class Java applications using agile methods and plain old Java objects (POJOs). Second, it covers a lot of ground, from conceptualization through deployment, so for the sake of brevity, there are minimal code excerpts; however, there's a completely functional sample timesheet application called Time Expression (with source code) built using Spring, Hibernate, Junit, and Ant available at visualpatterns.com/resources.jsp.

We have a lot to cover so let's get started.

Agile Manifesto
In 2001, 17 software experts (including Martin Fowler, Kent Beck, and Jon Kern) got together to discuss lightweight approaches to software development; they jointly defined the term agile. The outcome of this was the "Manifesto for Agile Software Development," a set of values and principles for these agile methods.

The term agile incorporates a wide range of methods; some of them include Extreme Programming (XP), Scrum, Feature Driven Development, Agile Modeling, and Crystal. Many methodologies tend to include both process and modeling since they often go hand-in-hand; we will look at both next. For details on the Agile Manifesto and various agile methods, visit the agilemanifesto.org and agilealliance.org Web sites.

Agile Processes
One of easiest agile processes to understand is Scrum. While XP tends to steal the limelight in the agile community, it's a bit more involved than Scrum. However, the two are highly complementary since XP provides a set of excellent engineering practices whereas Scrum is more about product/project management. In fact, these days I tend to recommend becoming "agile" by bringing in Scrum first, then adding XP practices one at a time, as and when needed since moving entirely to XP-based development (from waterfall) is a rude awakening for many organizations and requires a fundamental mind shift that many projects aren't ready for.

So, how does Scrum work? Simple. We gather a list of new features or change requests for an application in a product backlog. For our sample application, Time Expression, these could include:

• Hourly employees will be able to sign in to a Web application and enter their hours for each day of a given week.
• The employee's manager must approve the timesheet.
• After a timesheet is approved or disapproved, notification is sent to the employee indicating the updated status of the timesheet.
• And so on...

A common theme of agile processes is iterative development. For example, XP works like Scrum, however, it uses the concept of quarterly releases with weekly iterations as shown in Figure 2. Also the features are provided in the form of user stories, typically written by the customer using one to three lines to describe the feature. My explanation of XP is overly simplified; there's a lot more to it such as pair programming, sit together, and continuous build. Visit extremeprogramming.org for details on XP.

So now we've looked at two agile processes, Scrum and XP. These help in gathering user feature requests and overall project management. However, as developers, we need to implement features by engineering them into software applications, so let's look at agile modeling techniques next, which can help us bridge the gap between user requirements and coding.

Agile Design
According to thefreedictionary.com, a model is "a preliminary work or construction that serves as a plan from which a final product is to be made...used in testing or perfecting a final product." So here I'll use the word "model" to describe diagrams and other artifacts.

Agile Model-Driven Development
Agile Model-Driven Development (AMDD) created by Scott Ambler provides guidelines for effective modeling. Instead of creating extensive models, AMDD recommends creating "good enough" models. One of my favorite Scott quotes is "your goal is to build a shared understanding, it isn't to write detailed documentation."

AMDD suggests two categories of models, requirements and architecture. Requirements models could include a domain model (Figure 3), usage models such as user stories or use cases (Figure 4), and UI models such as prototypes and flow map (Figure 5 and Figure 6).

Architecture models could include a freeform model like the one shown in Figure 7.

There really isn't a whole lot more to AMDD since it provides minimal guidelines for agile modeling. Visit agilemodeling.com for more details.

Agile Draw
Before moving to the next topic, let me briefly mention a new and elegantly simple technique called Agile Draw, which was used to draw Figures 3-7. This technique provides an alternative to the heavy-handed Unified Modeling Language (UML) but can also be used to complement UML. Agile Draw provides minimum guidelines for modeling and additional guidelines for adding appeal to these models using graphic design concepts. The core concepts behind Agile Draw include four basic components that make it a virtually notation-free modeling technique; these concepts include circles, boxes, lines, and text. Using them you can draw practically any model by hand or with a drawing program.

Visit agiledraw.org for more details.

Refactoring
One of the core aspects of agile methods is not to do too much design upfront so you can start showing results to the customer quickly by developing actual software versus producing comprehensive documentation that no one actually reads or maintains. Of course, the downside is that it cuts down on the amount of design done for an application. However, this isn't necessarily a bad thing since most programmers find better ways of doing things once they begin coding.

For example, we find cleaner ways of structuring our code after the first pass at it, perhaps by improving our own design or because we learned a better way of using a framework (such as Hibernate or Spring). This code improvement is known as refactoring and is considered a continuous design activity.

Refactoring is more than fluff; it's now appearing as a menu option in integrated development environments such as Eclipse and IntelliJ IDEA. Visit Martin Fowler's Web site, refactoring.com, for more information on refactoring along with a catalog of many refactoring techniques.

Other Design Considerations
While refactoring can help improve code, there might be other things you should consider upfront or in the first couple of iterations. Some of these include schemes for transaction management, exception handling, clustering, and application security (authentication, authorization, and encryption). Any enterprise-class project that doesn't at least consider these "big picture factors" upfront is asking for trouble later. One common problem found in XP projects is that a lot left for refactoring later never happens. Drawing bare-minimum architecture models like the one shown in Figure 7 upfront can help with general discussions about the important design considerations I've mentioned here.

• Developing MVC Applications Using ZK and Spring
• Scrum Buts, “Meta” Thinking, and Agile Architecture