Agile Development Practices: An Introduction

There are dozens of Agile development practices. For those new to Agile, here are some of the most common practices from this increasingly popular approach to delivering software projects.

Daily Standup (Stand-Up Meetings)

Also referred to as a Daily Scrum, Agile teams have daily meetings to briefly share need-to-know information. These meetings are held to keep the development team on the same page, not to provide a status update to the project manager. Brevity is the key to these meetings. In Daily Standup meetings, participants answer three questions:[i]

  1. What did I do yesterday?
  2. What will I do today?
  3. What problems are preventing me from making progress?

User Stories

A User Story is a short description of a function that an end-user would want. There are three elements to a User Story:[ii]

  1. a written description for planning (card),
  2. a conversation about the story to better understand it (conversation) and
  3. a series of tests to confirm the story (confirmation).

These are written from the perspective of the end-user in language that is understandable to them. Stories serve as a form of currency between customers and developers that both parties understand.  Stories are the primary practice that supports the Agile paradigm of developing by functions.

Bill Wake put forth the acronym INVEST for the 6 principles of a good story:[iii]

  1. Independent
  2. Negotiable
  3. Valuable (to customer or end-users)
  4. Estimable
  5. Small
  6. Testable

Automated Testing

With Agile, a key aspect is the implementation of automated tests.  Formal and thorough automated tests help ensure the delivery of working software throughout development and eliminate defects at the source. Developers write unit test code using any number of available frameworks (e.g., JUnit is the go-to Java framework) at the same time as they develop the code. In this manner they build a safety net for the working code that allows them to make changes and have confidence that other features haven’t been broken. Automated Tests also greatly reduce the length of time between the origin and the discovery of a bug.

Acceptance tests are functional tests for a User Story. In other words, they are programmed checks to ensure that existing features continue to work as defined as new features are added. Ideally, acceptance tests are defined by the customer and coded by developers. Running acceptance tests help prove to the customer that the Story is done. After acceptance tests are created, they are run automatically and repeatedly to ensure that the newly developed code continues to work as new features are added.

Automated Builds

A key principle for Agile methodologies is to have running software at all times.  In practice, the only way to do this is by ensuring that all software development is regularly and automatically compiled, built, deployed and tested. This is usually done many times a day and at least once every time a developer “checks in” code as a main part of the development branch.

The advantages for automating builds are huge.  They reduce troublesome deployment and integration problems and they provide a reliable environment for demonstrations and testing.

Continuous Integration

This practice has the development team integrate their code to the system several times per day. Before integrating completed code, the developer runs a series of tests to make sure the code to be integrated won’t break any existing functionality or tests in the system. To do so, the developer runs all of the tests for the system and makes any necessary fixes. The more frequently code is integrated, the less time it takes to merge and find errors.

Agile Planning: Releases, Iterations and Tasks

In Agile development, planning is divided into three levels: release, iteration and task. At the start of the project, the developers and the customer come together to discuss the major User Stories (features) that are needed in the software. They focus on identifying must-have features and roughly prioritizing and estimating them, which helps facilitate Release, Iteration, and Task planning.

  1. Release planning: A customer-driven planning session. The developers and the customer decide on a date for the first in a series of product releases. They decide what stories to incorporate in the release. The Developers drive the effort estimates for the stories while the customer drives the prioritization and selection of the stories. Effort estimates take various forms depending on the preferences of the development and customer teams.
  2. Iteration planning: A joint effort between the customer and developers to do part of the release plan. As in release planning, the customer defines and prioritizes the User Stories and the developers estimate the effort it will take to develop them. Naturally, the timeline is shorter for an iteration than that of a release. It is often a matter of weeks, not months, for an iteration.
  3. Task planning: After planning the iteration, the development team breaks down the stories for the iteration into a series of tasks. A list of the tasks is documented in the project room where it is highly visible; Post-it® notes and whiteboards are common tools to help with task planning. Developers sign up for tasks and assign estimates to them.

Pair Programming

This practice has two developers working together on a programming task. Typically, one person takes the role of entering the code (the driver) while the other thinks about the next steps and how this code will fit into the bigger picture (the navigator).

A common objection to pair programming is that it is wasteful to have two people doing the work of one. While it may take more developer time to program this way, the output often justifies it. As one study found, pairing takes 15% more effort than one person working alone but produces results more quickly and with 15% fewer defects.[iv] Results will vary on a case-to-case basis, but when considering pair programming, ask whether a reduction in defects is worth added effort and resources. Also, pairing is not a full-time requirement. Teams often set their own working rules around when it is advantageous to pair.

Retrospectives

A retrospective is a meeting to look back over an iteration, release, or project, specifically to discuss what worked well, what could be improved, and most importantly, how to translate the lessons learned into actionable change. They are a forum for the team to improve upon their process.

For more on Agile development practices, check out our Agile methodology series.

 


[i]  Shore, James, Warden, Shane. The Art of Agile Development. Print.

[ii] Mike Cohn. User Stories Applied: For Agile Software Development. Print.

[iii] Wake, Bill. INVEST in Good Stories, and SMART TasksXP123. Web.

[iv] Shore, James, Warden, Shane. The Art of Agile Development. Print.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn