|
Diagram
|
|
|
|
|
Title
|
|
|
Feedback Loops
|
|
Building Architecture
|
|
|
As observed by Christopher Alexander, nature has "very small feedback loop adaptations". Structures that are good are built dynamically. This process can be found in both nature and man-made structures.
|
|
Architecture Intensive Disciplines
|
|
|
Feedback in projects involve communication. There must be a balance between technical work undertaken and feedback (to project managers, users or sponsors). This is a form of dynamic interaction rather than intervention. In Extreme Programming (XP), having the Customer as part of the team helps to create this dynamic interaction. In the Rational Unified Process (RUP), this feedback loop is expressed through the 4 phases of each iteractive life cycle - inception, elaboration, construction and implementation. The water-fall life-cycle of the Structure Software Development Methodology (SSDM) did not properly address this dynamic feedback loop. Rapid Application Development (RAD) and Agile methods such as XP can also fail without the forces that provide feedback - hence the need to involve the customer dynamically.
|
|
Case Study A: Large Corporate IT
|
|
|
|
|
|
Although a Project Office was established, each project manager in the organisation had a unique approach. In particular, there were contrasting styles of handling feed-back loops. The teams had discussed these and there was a common view as to which approach was perceived as best or worse. Project managers that looked over your shoulder or repeatedly asked the question "when" were considered the most irratating and often did more to slow people down. Just as bad were those who only popped in once a month. Those who had a clear idea of priorities, made informed decisions and estimates and interfaced with the team informally and formally at least once a week were considered the better. More importantly, the feedback between business units and technical teams was critical. The worst type of project managers were simply the ones who could not say "no" and constantly changing the direction of the team or worse (send it into a spiral).
The projects were often broken down into project iterations and sub iterations until we had build cycles spanning between 1 to 3 weeks of construction. Due to the nature of some systems (large transaction processing), only a few builds per month could be managed.
|
|
Case Study B: Small Commercial Team
|
|
|
|
|
|
The first 2 to 3 months involved refactoring and re-engineering the development domain. We were then able to establish an environment where we could do at least one build per day. We also managed to break down project deliverables into smaller tasks - some down to a few minutes - others one or two day estimates. The key was to create a work break down structure that could provide short feedback cycles so that the project manager could get a handle on the technical work involved.
|
|
|