When we moved into an agile methodology here at Code, a lot of us experienced that blissful feeling of thinking we wouldn't need to document things anymore.
And this method can work a treat when there's a very small, dedicated team working on the project and your clients are always available. But if (like us) you have specialists that need to be get involved at different points in the process and clients that are too busy to be readily available at all times, it's not always a smooth journey...
Our version of agile is based on a simple framework. The strategy team highlights the objectives, a product owner brings knowledge of the business rules, UX offers an understanding of the audiences and their motivation, and then the team develop the solution -- first through designs and then build.
Sometimes this system has worked really well; sometimes not.
The main issues that have cropped up for us in the past are as follows:
The client expected something a bit different, or a bit more than what they got
The people with the relevant knowledge weren't always around or available when we needed them
User stories often told the team 'how' they wanted something done, instead of 'why'.
We realised that we needed the teams as a whole to get a better picture of the objectives of the business and how it worked. As a digital agency we can establish the 'why' and 'what', and then get our team of specialists to define the 'how'. The methodologies to help us achieve this were out there -- Impact Mapping, Story Mapping, Specification by Example workshops, BDD and Living Documentation.
It has taken a while for us to figure out how to fit these methodologies into our way of working. Often the examples given are of pure software development teams working with complex business logic, able to decide on scope as the project progresses in a purely agile way. But the sites we work on are often more about content and user interface, plus we still tend to have a fixed budget and clients that want to know what they will get before we start.
I recently attended the 'Specification by Example' course run by Gojko Adzic, and it's helped make sense of how all this can better fit into our environment -- so I wanted to share a few gems of advice that have already begun helping us here at Code.
1. If something seems obvious or trivial, it's worth spending 10 minutes verifying that it is
Get together to look at examples and verify that you all understand them the same way; if there are questions or disagreements, then it's actually not trivial or obvious. A good way to test this is to all write down your understanding in silence and then compare.
2. The best way to make sure you have shared understanding is through real examples
Get started on the examples and let the structure emerge.Start with a simple example first, then move on to alternatives and realistic edge cases. Refine the examples so they're quick and simple to understand later, and then make them your acceptance tests, automated as required.
3. If there are times when you can't all be there, you might need to document
Find a clear way to share feature requirements alongside context and testable examples. 'Specification by example' done right can do this brilliantly. An online system like Fitnesse or Cucumber might help -- record features as they emerge with their context, add examples through workshops, get developers and testers to add more as they go, then automate. This becomes living documentation, always up to date.
4. Decide on the best process depending on who needs to be involved at the start then refine
Find out how much the business stakeholders will be available -- can they come to 'spec by example' workshops throughout, or do you need to document it? Think how many people are in the team and how best to pass the business knowledge on to them -- the 'why' and 'what', not 'how'.
5. You don't have to call this 'agile'
Working through examples with the client and team is a great way to understand a business, no matter what process you use. Focus on waste -- measure where the waste is and focus on reducing that first. Often that will lead you to these methods anyway but see where it takes you.
We are constantly refining our agile process, and every project is different. If you have any similar or different experiences you'd like to share then let us know.