Requirements and Bridging the Silos (Part 3 of 3)
by Andrew Hayward
The first and second parts of Mr. Andrew Hayward’s three part series on Requirements and Bridging the Silosdescribed how, in larger development efforts, the division of resources into roles often reduces the effectiveness of communication and hinders understanding of requirements (see part 1 of Requirements and Bridging the Silos) and how to increase the understanding of project requirements within and between the testing and implementation silos (see part 2 of Requirements and Bridging the Silos).
The final installment continues with some examples of how silos have hindered communication and, therefore, understanding of requirements, and the solutions these organizations applied to resolve these problems. Following this is a list of eight best practices to bridge the silos in your organization.
| Attachment | Size |
|---|---|
| Requirements_and_Bridging_the_Silos_(Part_3_of_3).pdf | 153.38 KB |
No one designs anything on an assembly line
I'm going out on a limb here a bit, because I'm also no manufacturing guru.
However, I believe the reason the manufacturing analogy fails us in SW dev is because every software building effort is a design project. It doesn't matter how may times you've done something similar, no 2 bespoke developments are the same.
Phil Armour stated this most clearly saying that software is a medium in which business knowledge is stored. And every buiness is different, therefore every deployment carries different knowledge. And knowledge requires a process of discovery before it can be built into the software.
In an assembly line evey worker (or is that robot, these days?) follows EXACTLY the same process to fit the same components together. You can't have someone saying, "Oh, I've done something like this before, let me try it this way!". Those design decisions have been made for him and all he is doing is executing the specification.
Software, on the other hand, requires evey team member to add value by applying some design to the work they do. The only time software is "manufactured" (in my view) is when the compiled code is duplicated on media for packaging.