All modern software development methodologies are focused on increasing the feedback and taking advantage of it. One of the fundamental assumptions is that trying something out (getting feedback) is more valuable than the cost of doing it wrong. This works fairly well if we are getting quick and reliable feedback. However, does this equation still apply if we are not getting timely/quality feedback?
If we are like Google or Facebook who release stuff daily and are able to immediately measure the impact of each feature then there is certainly more room for experimentation than if we are releasing once per month or even less frequently.
So what to do about it?
Essentially there are two variables that can be modified – the frequency and the quality of feedback.
Most obvious answer to frequency is releasing more often. Unfortunately this is typically not that easy as it requires change in thinking that go well beyond development team or even whole IT.
If we cannot increase release cycle then we can at least increase demoing cycle. This is typical solution used by agile development teams working in non-agile organizations. Obviously this is not as good as releasing. Furthermore in some cases it can actually build quite dangerous illusions about the feedback you are getting.
The problem is that such organizations are quite used to the way how software development has been done in the past. Typical understanding is that first you do a lot of analysis. You figure out what needs to be done. Then everything is implemented. Actual business users start using the system only when everything is “ready” because they are too busy to test “half-ready” solutions.
At the date of release everybody is in for quite unpleasant surprise. Business users are surprised that requirements they wanted are not implemented as they assumed. They are also surprised that many things from their wish list have been dropped since these just didn’t fit into project schedule. Management is surprised that business users are not happy. Development team is surprised that everybody wakes up only now. Even though regular demos have been conducted every two weeks and most unwanted behavior has been agreed by everybody months ago.
Some ideas that help to alleviate the above problem:
- acknowledge the fact that nobody actually using the stuff you are producing introduces significant risk
- find at least one person who will later use it to continuously try it out
- make all stakeholders understand that they are as responsible for the success or failure as the development team
- find a person in organization who is actually interested in getting better results as opposed to getting as many items from initial wish list done as possible and let him/her help you with the former two points.
Ürgo Ringo's blob 