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 |
production method debate
A discussion about the production type analogy in software is allways interesting. Is it waterfall, is it assembly line, or R&D? Most people in software prefer to call it R&D, which should explain why projects run out of planning and over budget. Most often only used as an excuse. The assembly line is often disgusted because of the rigid place an operator has in an assembly line and the limited field of operation. Software developers don't want that. But, as stated nicely in the articles, success of a project - however you do it - depends on communication.
I think the assembly line analogy can be implemented in an organization, if only the analogy is well understood and communication is adjusted to it. Even the original paper about the waterfall analogy stated the importance of feedback and communication. That part of the waterfall is often lost in bad communication.
The original paper on the waterfall tries to address the same problems as addressed in these articles. We are about thirty years later than the waterfall paper, but still...
I prefer the contractor analogy, where every sub-contractor knows what to do from a rough drawing under the guidance of the general contractor and every sub-contractor has a specific place in the planning. The general contractor would be the business analyst together with the architect and the sub-contractors would be the developers with specific coding skills such as performance, security or network communication. To implement the contractor analogy, you would need books with building codes and building code inspectors (who do the technical inspection with the interest of the customer in mind). I see a growing awareness and willingness to comply to building codes in software.
Albert Zuurbier