Business people and developers must work together daily throughout the project.
One of the big things that makes Agile so effective is trying to figure out what things we do add value to the project and maximize doing that thing while minimizing doing other things. It turns out that communication is really one of the hardest hurdles on a software project, perhaps on any project. In the past we have attempted to fight this with comprehensive documentation that covers all aspects of the software. The idea was that if we write software requirements with enough detail up front then we can just hand it off to the developers and our software will be built correctly. Every time I have seen this done I have seen it not work. Inevitably the requirements change. And, the bigger the project the more likely that the requirements will change. I actually had a customer tell me in a post-delivery meeting that “you built exactly what I said, not what I want.” My companies contract lawyer smiled because that was the admission she was looking for to justify our bill, but it wasn’t really a great way to win repeat business. The problem was that the customer’s understanding of what they wanted the software to do changed as soon as they saw what the software was capable of doing. This was a military customer, so I’ll use a famous military quote “No plan of operations extends with any certainty beyond the first contact with the main hostile force.” The point of this quote is that your plan can’t anticipate everything that will happen during the project therefore you must have a good way of adapting.
Agile Practice 4.1 : Talk
As a professional software developer I am fond of saying that we developers tend to be a little introverted and weird. I know, it’s a stereotype and there are definitely developers out there who are not introverts but based on the developers I have known a larger number of us are bad communicators who are more comfortable with a keyboard than a social gathering. This is why we make it a part of the team’s standard operating procedure to talk to each other. I implemented a policy for my team to have a “pre-production meeting” for each requirement they were going to implement. Before the developer starts coding, they give the customer a call and discuss the requirement. When I say “the customer” I mean the person responsible for accepting or rejecting the result of the developer’s work. This may be an actual end user, a member of your marketing department, or someone else. You’ll have to find the right person for your project.
During this conversation, the developer and customer discuss what the customer’s expectations for a successful delivery mean. This is kind of like cheating on a test by asking the teacher what the answers are before the test. If the developer knows what the customer is going to be looking for then that developer will be sure to meet that expectation. Remember Practice 2.1, well, this is a great way to elaborate the requirement further and do it at the last responsible moment.
Agile Practice 4.2 : User Stories
Since we know that comprehensive documentation doesn’t work as well as we would like it to, we will need an alternative. For most Agile projects that alternative is the User Story. This is a short, one or two sentence statement that describes a feature the software should have. The point is for this not to be comprehensive documentation, but to serve as a placeholder for the discussion that will follow. These stories quickly become the “track-able requirements” for the project. We put them in our task tracker and we use the to build burndown charts. When it comes time to implement that story into the software, we use Agile Practice 4.1 : Talk to elaborate on the details of the story. Most teams will still write down the elaborations and I think it is a good idea. I encourage my teams to use Gherkin Scenarios to document the details and generate automated test scripts in one step with a tool like SpecFlow or Cucumber.
Agile Practice 4.3 : Feedback
Feedback is critical in Agile processes. We go through a lot of effort to make sure we can deliver a new feature or change an existing feature very quickly and feedback is how we turn that agility into a competitive advantage. Agile projects strive to put the product in front of customers as soon and as often as possible and make the developers and customers talk about the good, the bad, and the ugly of the product. Discussing this will teach the team about the product and color all the discussions that happen when progressively elaborating the remaining requirements.
For more information about the origin of the Agile Principles, see the Agile Manifesto site.
