Reducing the Feedback Cycle Requires Discipline

 

Techniques that shorten the time between doing something and getting feedback about it are generally lower risk and result in lower cost to address any changes than techniques with longer feedback cycles.  Many of these techniques require agile team members to have new skills and to take a more disciplined approach to their work than they may have in less-than-agile situations.  There are several common ways to shorten the feedback cycle that are common to agile software development that are adopted by the DAD process framework.  These techniques, listed in order of immediacy, are:

1. Non-solo development.  Non-solo development strategies such as pair programming and modeling with others provide feedback within seconds.  These techniques are great strategies for reducing the feedback cycle within your team but they often require initial discipline to adopt because it can be difficult to break your former solo working habits.
2. Active stakeholder participation.  It can require significant discipline to work closely with your stakeholders, to seek and then respect their opinions, and to allow them to set important aspects of your project direction.  Working closely with stakeholders typically has a feedback cycle on the order of seconds when they are co-located with your to hours or days when you need to wait to interact with them.
3. Continuous integration.  Building, regression testing, and potentially running your work through code analysis on a continuous basis is a fairly straightforward concept which provides feedback on the order of minutes.  Doing it in practice, and more importantly the habit acting on the feedback provided from the tests and code analysis requires discipline to adopt at first because you often want to work on the next thing instead of cleaning up the work on what you’re currently doing.
4. Continuous deployment. By regularly deploying into more complex environments – to your project integration environment from your individual environment, from your project environment to your demo or independent testing environments – you put yourself in a position to receive more meaningful feedback.  Continuous deployment requires you to have the discipline to have multiple environments, to work with people external to your team (such as stakeholders and independent testers), and to seek and act on their feedback.
5. Short iterations. The length of an iteration defines the feedback cycle between promising your stakeholders you would do a bundle of work, the end result of your iteration planning session, to demonstrating what you actually got done.  It requires significant discipline to work in short iterations.  The average agile team has construction iterations of two weeks, although some teams have shorter iterations and some advanced teams have evolved beyond iterations to take a lean approach.  Then again some agile teams, particularly those at scale, may have slightly longer iterations.  The shorter the iteration the greater the discipline required to make it work because you will need to adopt many, if not all, of the techniques listed in this section.  You will also require the discipline to identify, and then address, wasteful activities that add little or no value in your current process.
6. Short release cycles.  The length of your release cycle defines the feedback cycle from promising stakeholders to deliver a new release of a solution to actual use by end users in production.  The feedback from real users is the key information to determine if you’ve delivered the right thing for them.  All other stakeholder feedback is merely an approximation up until that point.  As with short iterations, it requires increasing discipline to move from annual to bi-annual to quarterly to monthly to weekly or even daily releases into production.

This posting was modified from Chapter 21 of the forthcoming book Disciplined Agile Delivery to be published in June by IBM Press.