LostFeedback

Feedback from later development is lost rather than fed back in

Description

Feedback from later development is lost rather than fed back in. Work is passed on to the next stage, but nothing comes back.

Discussion

In certain development environments, work is ‘thrown over the wall’ from one stage of development to the next, say from Analysis to Design. Even where this effect is not so pronounced, there may be little or nothing coming back the other way.

There is a tension (discussed in Inappropriate Organization) between organizing following functionality and organizing following skill, technological layering and such like concerns that cut across end-to-end functionality. Following functionality jeopardizes peer feedback; following orthogonal organization jeopardizes feedback from the recipient of the work.

Prevention, Amelioration, Cure

Traditional

Feedback as work is produced can be obtained by having reviews. Two particular groups should be involved. PeerReview is a form of sanity check and skills transfer. However, the feedback for suitability of purpose arrives if the RecipientAlsoReviews. One variant on this latter process is DeployAlongTheGrain – if the producer of the work, in one role, is the recipient of the work, the same person in another role, then he will know intimately what is required for the product to be suitable for the purpose. Note that when taking this approach, peer review becomes more important.

Modern

Modern AgileApproaches deal far more in direct and interactive communication than in producing artefacts that get ‘thrown over the wall’. In addition, DevelopingInPairs gives the opportunity to have one half of the pair specializing in the functionality, while the other half is specializing in the orthogonal skill currently required. As the paired ProgrammingEpisode progresses, one can be giving peer-oriented feedback while the other would be giving recipient-oriented feedback, as the work is being done.