Agile, a Different Methodology, Page 2
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