Agile Software Development in Practice

Wanted to file this away on my blog.  David is one of the smarter guys I know and is taking us to world class development.

Post by David Dickinson (Director of Software Development) on March 22 2011

Naturally, after reviewing the fragile foundation that underpins the traditional development, the next step is to offer a solution to the problem: How can we effectively manage IT projects in a way that meets the customer’s goals without the usual cost/time overruns and with no diminution in quality? Agile development practices present an alternative that addresses the issues with conventional software development and also addresses the need for increased customer engagement.

What it is

Agile software development is based on four key values:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

These values manifest themselves in a number of principles:[1]

1)    The highest priority is to satisfy the customer through early and continuous delivery of valuable software. There is a strong correlation between overall quality of systems upon final delivery and how early and frequently partially functioning software was presented to users. Ultimately, working software is the primary measure of progress—everything else is inventory.

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 for the shorter timescale.

4)    Business people and developers must work together closely (preferably daily) throughout the project.

5)    The most efficient and effective method of conveying information to and within the development team is face-to-face conversation.

6)    Simplicity, the art of maximizing the amount of work not done—is essential. The simplest path consistent with the goals of the project should always be taken.

7)    The best architectures, requirements, and designs emerge from self-organizing teams. Responsibilities are communicated to the team as a whole and team determines the best way to fulfill those responsibilities.

Conclusion

Development teams new to Agile often focus on the particular practices recommended by the various Agile methodologies, whether they plan on using XP, Scrum, DSDM or whatever method and fail to spend sufficient time reflecting on the values and principles that underpin the methodologies. I contend, however, that any time invested in such reflection will be handsomely rewarded. Inevitably, no particular Agile methodology will meet the needs of a particular team/project/customer combination precisely and so some modification will be necessary. If the preceding values and principles are kept in mind when those changes are made, it greatly increases the probability that the team will 1) not regress back into familiar, traditional, development habits, and 2) continue to serve their customers well.

Craig Sroda