Agile, a Different Methodology

Friday Nov 13th 2009 by Eric Landes

If you wonder why you are hearing so much about the chaotic Agile methods lately, this is the article for you. We'll show you how to put the Agile method to work for you.


In the past year, Agile development methodologies have moved from the fringes to being considered a mainstream method for software development. The Agile movement started in the late 90's with the advent of Extreme Programming (XP), SCRUM, DSDM, Feature Driven Development and others. The Agile manifesto created in February of 2001 contained the core principles of Agile development. Why is this important to us?

Agile is important, because in the end, it has helped to bring business discipline to software development. Agile has a lot in common with Lean methods, exemplified by the Toyota Production System. Lean methods have begun appearing in Agile teams, bringing even more business focus to software development/IT teams.

Comparing Agile against what?

When discussing Agile, what are we comparing it against? I am comparing Agile against strict Plan driven development approaches. Often called waterfall, your company may not have a specific name for it. But if the current process involves making sure that all the requirements are nailed down before the project is started, and changing those requirements includes a request to walk on water before it can be changed this is the process we are comparing Agile against.

To get a sense of the high level view of Agile you can read the manifesto at The manifesto begins with four statements:

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

These statements may seem a little touchy, feely, so let us put some meat on the bone, to understand how to implement this in your shop.

For each of the statements in the Agile manifesto, concrete practices from Agile methods are used. Each statement is a section that will contain what practices are used to achieve the intent.

Individuals and interactions over process and tools

This statement may indicate to you that Agile has no process. In fact I have found this to be far from the truth. Agile does not throw process out the door, rather Agile says that Individuals and interactions trump the process and tools.

This shows in the frequent planning and daily standup meetings common to most Agile methods. In XP, Scrum, Lean the daily standup meeting is a staple. At this meeting all committed team members interact with each other via these questions:

  1. What did I do yesterday?
  2. What am I working on today?
  3. What is blocking my work?

The daily standup should help communicate project progress. In other words, what is communicated in the standup (individuals AND interactions), may need to supersede the project plan. It is during these meetings that hurdles are uncovered. But usually they are discovered in time to fix the problems quickly. If a technology is not working as expected, or the business logic actually conflicts with other logic, it is brought up in these meetings, and after the meeting the action plan is created.

Working software over comprehensive documentation

This phrase is best described by the practice of delivering software on a regular, fairly quick schedule. Normally in XP and Scrum, you work in iterations. The team selects the length of the iteration at the beginning of the project, and generally stays with that length for the duration of the project. Within an iteration, the team selects the stories or features they will complete. Once in that iteration, the stories that are being worked on cannot be changed. Any changes can be introduced at the beginning of the next iteration.

Normally, at the end of the iteration, there is a demo and planning meeting. In this meeting, your team demos the solution including the new features/stories to the stakeholders/customer. The intent is that if the customer likes this, the team could release that version of the software immediately. In practice this can mean that the team releases the software to QA or User Acceptance state where customers can test/use the new features. Other teams may release to production (think of all the google beta software you have used).

One note on iterations, the length is generally considered to be 1 week to 1 month. This is up to the team. Again, this decision should be made as a self determining team, it should not come from management.

Many Lean/Kanban teams do not use iterations, but they do frequent releases. The releases happen on a similar schedule as iterations. This allows the Lean/Kanban teams to release working software frequently.

The reason for valuing working software over detailed and comprehensive documentation is that the value delivered is the software. Documentation of your system should be baked into the process of delivering software. Agile does this, by encouraging good software engineering principles like Test Driven Development using automated unit tests and automated user acceptance tests.

Test Driven Development using unit tests, and acceptance tests, encourage test writing that serve as documentation. A well written unit or acceptance test should document the requirement the developer is testing for. When any maintenance is needed, different developers should be able to look at these unit tests and understand the requirements needed.

In addition, this suite of tests add a fantastic safety net for modifications later in the life of the software. If the software sits for a year before modifications, the new team can start development on new features, knowing that those tests ensure that they cannot break existing features.

Click here for larger image

Figure 1: Example of what unit testing frameworks look like

Customer Collaboration over Contract Negotiation

In many plan driven environments, the customer sits down with analysts, and they put together a comprehensive document with their requirements. This document is handed over to a vendor or internal IT group, and an estimate is expected. The vendor/IT group can ask questions about the requirements, and once answered, they come back with an estimate.

At this point the customer is done, except for occasional contacts for milestones. Then when the agreed upon time frame is complete, the vendor/IT team delivers the software. For many, this is the first time the customer team has seen the software. In this scenario, many times, the customer asks to add features, or feels that what they wanted was not delivered.

When Agile methodologists talk about customer collaboration over contract negotiation, there is an expectation of close customer involvement. This means in the planning meetings held after every iteration, stakeholders are present. This also means that the customer is expected to assist team members in verifying requirements. So they may need to participate in creation of automated acceptance tests.

These acceptance tests, using tools like fitnesse, selenium, rSpec, define the tests using an agreed upon format. The tests are written in a business like language to call and test the software components that implement the business logic.

In other words, the Customer Collaboration over Contract Negotiation does mean that the customer is more involved with development. The customer commits more than the example given at the beginning of this section. And that collaboration is designed to foster more trust between the customer and development team.

Responding to change over following a plan

This is my favorite statement on Agile. It also cuts to the heart of how a business can differentiate itself over the competition. When your systems and processes are configured to respond to change quickly and effectively, your business has a good chance to prosper and make a difference.

Practically this philosophy means that during the development of the software, expect and embrace changes. In XP, requirements are met by creating them in small sizes called user stories. Other Agile methods may break the requirements into features. No matter what the size of the requirement, each method allows customers to make changes before the start of each iteration.

For example, when working on an ecommerce site, one of the requirements may be that a customer of the site can bookmark the product, to be available in their shopping cart after they come back, in 1 day or 1 year. At the beginning of an iteration, the customer has a new requirement. Their research indicates that a new feature that adds a recommendation engine to the site will increase sales. During the planning meeting the customer now asks to put the new feature for the recommendation engine as the first one to work on in this iteration. The team is fine with this, and the customer understands that their other feature may not get in soon or ever.

Taking care of changes so close to the process ensures quick response to customer needs. This allows Agile teams to work without cumbersome change committees, just the stakeholders in the planning meeting.

This does mean that in theory the customer could start out with say 150 stories for their requirements. They could through the course of this process get rid of 100 stories and add 200. But Agile processes are transparent enough to show what the cost of those stories is. The customers in the planning meetings see how much the team completes, and the stories left to complete. When the customer wants to change direction, they can, but then old stories that have not been worked on yet, will be pushed to the back.

As noted above, those stories that do not get into an iteration may never get worked on. During the planning meetings and daily standups, customers/stakeholders begin to see the cost of each feature. As they become familiar with the process, less important features may not be worked on, if there is no budget. This whole process helps the team focus on features with the most value to the company.

Agile is not Chaos

Through the description of the methods used to back up Agile principles, you see that Agile is not about chaos. Instead the Agile name is pretty apt. It is about responding quickly to change, through a process. And that process is generally about delivering good value to the customer, whoever that customer is.

As Agile methods mature, there is a movement incorporating more lean values and methods into the process. Lean fits perfectly with Agile in its pure sense, and helps focus the teams even more into the business side of software/IT. In the end, the focus is about your customers, and your people. Agile is a way to get there.


Robert C. Martin "Agile Principles, Patterns and Practices in C#"
Mike Cohn "Agile Estimating and Planning"
David Anderson "A Kanban System for Sustaining Engineering".
Mary Poppendieck and Tom Poppendieck Lean Software Development: An Agile Toolkit

About the Author

Eric Landes is a Project Manager/Project Lead for a large corporate IT department, specializing in coaching Agile teams. He has 4 + years experience using Agile/Lean techniques to bring customer value and a team focus to projects. See his LinkedIn profile for more information

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved