What Is Agile?
Agile programming, or agile software development, is a group of software development methods which have become very popular and widely used recently. Its basic idea is to avoid the problems that arise using the traditional waterfall method by focusing on early delivery, evolutionary development and rapid and flexible response to changes. The development is done incrementally (it is divided into monthly or weekly periods called sprints), where each sprint is composed of many tasks and has a small part of the end product as its output. At the end of each sprint, the project is evaluated and the product is tested, which allows the developers to discover and fix the bugs, get the client’s feedback and make changes in the next iteration. According to recent survey, the top three reasons people choose one of the agile development methods are to accelerate product time to market, manage changing priorities and better align IT and business objectives.
Agile vs. Waterfall
Waterfall software development method is the traditional project management methodology. It defines the sequence of phases to be completed, where the project can move to the next phase once the previous one has been completed and verified. In today’s IT industry, this approach could lead to a number of problems, such as slow and costly changes (especially in the later stages of the project), late bug discovery (since testing is the last phase of the development) and lack of client’s feedback before the end of the project. A more detailed comparison of agile and waterfall method is nicely shown on this infographic from LiquidPlanner:
Agile Development Best Practices
If you have read this far, you have probably decided to use agile development methods for your next design or software development project. In order to implement them easily, let’s take a look at the industry’s best practices for agile project management.
Continuous integration is a software development practice that consists of merging all developers to a shared mainline several times a day. The benefits are early discovery of integration bugs (fixing them quickly saves time and money), avoiding last-minute chaos at release dates and having the current build constantly available for testing and demo.
System metaphor is a simple shared story of how the system works. Kent Beck, author of Extreme Programming Explained, points out the following advantages of using a system metaphor:
- Common vision — enables everyone (clients, programmers, managers) to understand how the system works.
- Shared vocabulary — creating common names for objects and relationships between them makes communication easier.
- Generativity — the analogies of a metaphor can suggest new ideas about the system (both problems and solutions). For example, the metaphor, "Customer service is an assembly line". This suggests the idea of a problem being handed from group to group to be worked on, but it also raises the question, "What happens when the problem gets to the end of the line - does it just fall off?" This can bring out important issues that might otherwise lurk and fester.
- Architecture — the metaphor shapes the system, by identifying key objects and suggesting aspects of their interfaces. It supports the static and dynamic object models of the system. 1
Here is an example of a system metaphor: "The software has the capability for transferring images from one device (e.g., PDA, PC) to another, and some image processing capabilities. It is much like a portrait studio, where a camera takes a picture, which is developed, retouched, printed, and distributed. Larger, more capable devices are like cities, in which many services are available. Smaller, less capable devices are like small cities, or even villages, where fewer services are available. Transfer of files is like a train moving from one municipality to another." 2
Test-driven development is a software development method where an automated test case that defines a new feature or improvement is written first. After that, the developer writes a minimum amount of code to pass that test, and finally refactors the code. This approach has a couple of benefits. A 2005 study found that using TDD meant writing more tests and, in turn, programmers who wrote more tests tended to be more productive. Also, the programmers using test-driven development reported they only rarely felt the need to invoke a debugger.
Pair programming is a specific development technique in which two programmers are working at one computer unit. One programmer is the driver, who writes the code, and the other is the navigator, who reviews each line of code. The two programmers switch roles frequently. Compared to when the programmers are working alone, pair programming has many benefits. The two programmers produce code with fewer bugs, complete work and find solutions to problems faster and provide more design alternatives. Also, pair programming improves productivity, as the programmers working in pairs are less likely to check social network, personal e-mails, or surf the web during the work time. If you want to read more about pair programming, check the top 10 tips for efficient team coding.
- Hold short daily meeting to resolve current issues (usually standing meetings)
- Team members volunteer for tasks (self-organizing team)
- Hold sprint review meetings to present completed work
- After sprint review, do the sprint retrospective to learn from previous sprint
- Code should be written according to the team’s predefined standards
- Unit test should be created before coding the feature itself
- All code must have unit tests
- All code must pass all unit tests before it can be released
- Refactor whenever and wherever possible
- Give the team a dedicated open work space
1. [Software Engineering with an Agile Development Framework/Iteration One/System metaphor, Wikibooks, Retrieved September 2, 2015, from https://en.wikibooks.org/wiki/Software_Engineering_with_an_Agile_Development_Framework/Iteration_One/System_metaphor] ↩
2. ["How Useful Is the Metaphor Component of Agile Methods? A Preliminary Study", James Tomayko, James Herbsleb, Retrieved September 2, 2015, from http://reports-archive.adm.cs.cmu.edu/anon/2003/CMU-CS-03-152.pdf] ↩