Getting feedback on iterations
An important thing in iterative development is the information you generate during iterations and the feedback you get from an iteration result. Even more important is what you eventually do with it!
There are various practices that guide us in generating and handling this information. In scrum we have e.g. the daily scrum, sprint demo and retrospective. More general we see that successful agile organizations implement patterns like ‘Group Validation’, ‘Engage Customers’ and ‘Producers in the Middle’ as described in Organizational Patterns of Agile Software Development by J. Coplien et al.
One part of the feedback loop that can often be improved has to do with iteration acceptance. It would be great if after each iteration demo the results are accepted as DONE. Also very good would be having iteration results including approved requirements going to the acceptance team and having the verification in parallel with the next iteration.
What I see in projects is that iteration results are often not properly handled due to various organizational issues. This reduces the feedback loop limiting the team in their ability to adapt and improve their work.
How can we improve our iteration acceptance to give us better feedback? You could take a piecemeal growth approach. First do some exercises and get people fit, once they are fit they can become agile!
How to become fit on iteration acceptance?
Break it up!
Instead of trying to get the organization do acceptance after every iteration right from the beginning. Focus on having the organization accept the result of multiple iterations first. It is easier to get the acceptance team to accept a complete feature set of functionality instead of a partial feature set. Make sure that the end result includes approved requirements and any other required artifacts that can go to up for acceptance i.e. installation scripts, training materials etc.
It’s also difficult to go in one step from complete requirements sign off to sign off at the iteration level. Therefore you could begin by having requirements specifications signoff for multiple iterations. This is mostly better understood and not as alienated to people’s currently working approach of bigger signoffs. It helps people getting used to working on smaller batches of work. It also helps them focus on the set of requirements that they want developed first.
No dull demo!
We all know that it’s important to have written acceptance tests or requirements by example see Tests & Requirements, Requirement & Tests. The benefits here are that most people work easier from examples instead of from general often much more abstract descriptions and that it improves knowledge transfer.
To get to this point you could start with installing the iteration results on a system where the customer and stakeholders can actually use it. Show it around, let them play with it, help them using it and encourage them to test some specific cases they think are important. This generates lots of feedback and is relatively easy to implement. Once people start actively using the demo systems and try it out with some of their own test cases, you can start thinking about asking them to write their acceptance tests before the iteration.
Once people pick this up and they see its benefits you can start working on making the feedback cycle shorter by having the acceptance team accept every iteration result if it passes THE acceptance tests.