Guide to Seven Agile Methodologies

A Practical Guide to Seven Agile Methodologies

But once an organization decides to adopt an Agile development regimen, there is still plenty of difficult research and decision-making to be done. In particular, navigating the various Agile methodologies available can be confusing to the Waterfall-minded. The most popular Agile methodologies in use today appear to be Extreme Programming (XP), Scrum, Feature Driven Development (FDD), Lean Software Development, Agile Unified Process (Agile UP or AUP), Crystal, and Dynamic Systems Development Method (DSDM). This two-part article will briefly explore the Agile value system, and analyze how these methodologies manifest these values. Particular care will be taken to highlight the similarities and differences between each methodology and we will conclude with a brief analysis of the varying business contexts that may make one methodology more appropriate than others.

Agile software development is a style of software development characterized by an emphasis on people, communication, working software, and responding to change. Its principles are summarized in its seminal declaration, the Manifesto for Agile Software Development. One of the most notable characteristics of this manifesto is that it is worded as a value statement and not a concrete plan or process. This underscores Agile's nature as a style of development consistent with the values laid out in the manifesto.

All Agile methodologies engage in an iterative workflow and incremental delivery of working software in short time-boxed iterations. An iteration is essentially a small release of software. Generally during each iteration many activities will occur in parallel, such as requirements, coding, and testing. Iterations are typically a fixed length (although this length varies between the methodologies) and thus are referred to as time-boxed. The time allocated to each iteration is sometimes referred to as a cycle time.

Agile methods also differ in the activities and artifacts that they produce. Methodologies that have many artifacts (or work products) and steps along the way are referred to as higher ceremony. Conversely, methodologies with less emphasis on these are referred to as lower ceremony. The number of people involved and the number of "sign offs" also helps to define the amount of ceremony around a particular methodology. It is important to strike an appropriate balance between the two in any given context.

One of the characteristic distinctions between XP and other methodologies is its cycle time and level of ceremony. XP recommends very short iterations between one and four weeks. XP is also a very low ceremony methodology. Minimal artifacts in an XP project include story cards, code, and unit tests.

1. 
   Planning Game: Plan work incrementally.
   
2. 
   Small Releases: Release as quickly as possible to increase time to market, and get feedback as soon as possible.
   
3. 
   Metaphor: If possible, define a metaphor for the system being developed. For example, the shopping cart metaphor is widely used to describe an online ordering system.
   
4. 
   Simple Design: Use the simplest design that will work for the functionality (user story) being implemented. Do not design for things that may never actually be used.
   
5. 
   Testing: Test everything, and try to automate the testing if possible.
   
6. 
   Refactoring: Instead of designing the entire system up front, design as you go, making improvements as needed. Change the implementation without changing the interface to the functionality, and use automated testing to determine the impact of the refactoring.
   
7. 
   Pair Programming: Programming in teams of two (or three) allow for a discussion to occur in real-time that addresses requirement, design, testing, and programming concerns.
   
8. 
   Collective Code Ownership: Anyone on the team can make a change to any code at any time.
   
9. 
   Continuous Integration: The entire code base is constantly being rebuilt, and retested in an automated fashion.
   
10. 
    Sustainable Pace: Ideally, team members do not need to work more than 40 hours per week to meet project deadlines. Burning the midnight oil is chunked by management in favor of consistent, predictable, repeatable delivery.
    
11. 
    Whole Team: The team functions as a whole. Members are encouraged to be more generalized than specialized. Learning about all technologies and requirements is encouraged.
    
12. 
    Coding Standards: In order to maximize communication, coding standards are defined by the team, and used to ensure consistent coding practices.
    
13. 
    Onsite Customer: Having constant and direct access to the customer allows the team to work at the fastest possible speed.
    

There are two primary types of planning activities that are referred to in XP parlance as planning games: the release and iteration planning games. And each planning game is characterized by three phases: exploration, commitment, and steering.

Release planning begins with the customer writing story cards and prioritizing them. Programmers then estimate the stories from which a velocity can be derived. Velocity describes how much work the team can accomplish in any given time frame. The customer then chooses a scope for the release based either on desired functionality or release date. The steering activities for release planning occur at iteration boundaries when progress towards the planned release date can be tracked and adjustments can be easily made.

Iteration planning follows a similar pattern to release planning. Each iteration begins with developers taking stories and breaking them into tasks. Programmers accept responsibility for tasks and estimating the tasks that they are responsible for. Each programmer's load is compared to their historical performance to determine whether anyone is overcommitted and to allow the workload to be balanced across the team. Throughout the iteration programmers partner to complete tasks by writing unit tests and code. Periodically throughout the iteration a member of the team checks on the progress of the team and communicates this information to all team members so adjustments can be made.

There are a small number of roles on an XP project. These include:

• 
  Customer—The customer creates and prioritizes the stories that need to be implemented. Because the customer sets the priorities she controls what will be delivered in any given release and can control the release date by adding and removing stories.
  
• 
  Programmer—Programmers collectively estimate stories, but individually accept responsibility for tasks which they estimate, write tests, and code.
  
• 
  Coach—The coach monitors the software development process, mentors team members on XP process and techniques, and focuses the team's attention on potential problems or optimizations.
  
• 
  Tracker—The tracker monitors the progress of the team and alerts them when adjustments to the schedule or a re-balancing of tasks might be required.
  

Scrum is a project management framework for managing Agile projects. Its primary goal is to deliver software that, after each and every iteration, provides the highest business value. Scrum is based on a 30-day iteration called a "Sprint." Technically Sprints can be either two or four weeks, but the generally accepted default is usually four weeks.

A fundamental Scrum principal is that project teams should be self organizing. This means that team members don't follow a prescriptive plan or set of tasks, but organize themselves initially based on the goals for the Sprint, and subsequently on a daily basis through daily scrum meetings. Recommended team size is from four to nine members.

Every day at the same time, the project team meets to discuss the project. Members are expected to stand during the entire meeting to encourage short meetings. Meetings are targeted to complete in 10 to 15 minutes. Each member in turn answers three questions:

1. 
   What did I do since the last Scrum meeting?
   
2. 
   What do I plan on doing between now and the next Scrum meeting?
   
3. 
   Do I have any roadblocks?
   

When multiple teams are involved in a project, a hierarchy of daily scrum meetings may occur, sometimes referred to as a Scrum of Scrums. An example would be where three teams are involved in working on three separate but related Sprints. Each team would hold their daily Scrum, and then one member from each team would convene together for an additional Scrum to make sure team coordination occurs. Information from this additional Scrum is fed back into the separate team Scrums the following day.

Scrum also defines only a small numbers of roles on the team:

 Product Owner—The Product Owner is responsible for representing the customer or user of the product the team is building. Ideally this is the actual customer, but when the customer is not available for a project, this role is filled by someone representing the customer's interests; he or she is also responsible for being the liaison between the project team and the customer.

 Team Member—All other members of the team are considered general team members. This includes developers, architects, project managers, testers, database administrators—everyone. The team concept is important to Scrum and only the key roles of Scrum Master and Product Owner are called out.Scrum uses the term "backlog" to refer to a list of items that are related. Three backlogs are defined by the Scrum process: product backlog, release backlog, and sprint backlog.

At the start of each Sprint, the project team breaks down items from the Release Backlog, starting at the top (most important), and adds these into the Sprint Backlog. Once enough items have been selected to fill the Sprint, the Sprint Backlog is locked. Estimates include total time to complete each item, including but not limited to analysis, design, coding, testing, documentation, etc.

There is another item related to Backlogs that is key to Scrum. The Burndown Chart (see Figure 2) is used to indicate the number of remaining Sprint Backlog items yet to be completed in the current Sprint. A daily record is maintained showing the team's progress in achieving the goal of the Sprint.

At the end of a Sprint, the team meets with any interested stakeholders to demonstrate what work has been completed, and to evaluate priorities for the next Sprint. In addition, any outstanding roadblocks are also discussed, as well as their impact and possible solutions.

One final note is that since Scrum focuses on the project management aspects of a project and specifies no technical practices, it integrates well with other Agile methodologies. It is commonly combined with XP, but will work with other approaches as well.

Derived from the Lean Manufacturing processes that companies such as Toyota have perfected over the past couple of decades, Lean's goal is to meet the challenge of defining, building, and delivering complex software systems that are exactly what the business really needs to stay competitive. Lean is similar to Scrum in that it focuses much more on the project management aspects of software development rather than the technical ones, specifically targeting the cost and ROI attributes of a project.

Lean pays a good deal of attention to gathering the "right" requirements. Requirements are measured based on their impact to the business, and must be defined in clear, complete, and verifiable ways. Incomplete, missing, wrong, unverifiable, and conflicting requirements are filtered out during the requirement process.

Due to this focus on requirements, the Customer plays an absolutely vital role in the Lean process. From a manufacturing point of view, it helps to think of Lean as being similar to new product development; this helps to crystallize the role and value that the Customer plays. Constant feedback from the Customer about the business value and functional requirements being addresses by the development team is a core component of the Lean approach.

Based on a wealth of quantitative metrics, Lean realizes that many projects fail due to their configuration and management. Projects with a silo'd, isolated, or "not my problem" attitude will face swift changes when Lean steps in. Lean attempts to also address resource issues such as the team not having the right skill sets, not enough team members, or too much turnover. In this sense Lean is very "root cause"-oriented.

Where some methodologies enforce strict definition between team roles, Lean prefers a more cross-functional approach. Team members are not only cross trained on functional and technical aspects of the system, they also team up with various team members to understand the business value for system features, and the business problems the system is expecting to solve.

Lean Manufacturing evolved from the work of Dr. W. Edward Deming's Total Quality Management (TQM), which can be boiled down to two main concepts:

1. 
   Process is important.
   
2. 
   People build and improve the process.
   

A newer addition to the Lean Software Process is the Theory of Constraints (by Eliyahu M. Goldratt, et. al.), which is comprised of two primary tenants as well:

1. 
   Identify constraints.
   
2. 
   Improve/remove constraints.
   

Lean Software Development promotes seven Lean principles. The methodology revolves around these principles, and all other aspects of Lean are designed to reinforce them. The seven principles are:

1. 
   Eliminate Waste: Eliminate anything that does not add customer value.
   
2. 
   Build Quality In: Validate and re-validate all assumptions throughout the process. If a metric or practice no longer has value, discard it.
   
3. 
   Create Knowledge: Use short iterative cycles to provide quick, constant feedback to ensure the right things are being focused on.
   
4. 
   Defer Commitment: Don't make decisions until enough is known to make the decision—a sound understanding of the problem and the tradeoffs of potential solutions is required.
   
5. 
   Deliver Fast: Minimize the time it takes to identify a business problem and deliver a system (or feature) that addresses it. (a.k.a. time to market).
   
6. 
   Respect People: Empower the team to succeed.
   
7. 
   Optimize the Whole: Use cross-functional teams to keep from missing important, possibly critical aspects of the problem and of the system designed to solve it.
   

The basic unit of work in FDD is a feature, which is defined as a small, client-valued function expressed in the form: