In Architects & Agile Like Zen Monks & Cell Phones, I questioned the relevancy of software architects in agile.
This morning I recalled two additions we’d made to our home. Both efforts were done by a superb craftsman who, in both instances, urged us not to engage an architect.
Both projects were completed on time, within budget, and, to our ongoing satisfaction, the results are functionally and aesthetically pleasing.
The trend toward agility in the software business is mirrored by the construction industry which has been evolving for more than a decade toward a Design-Build (DB) approach. In their version of DB, one contracting firm does the design and the construction; in contrast to Design-Bid-Build, or DBB, where one firm does the design (architecture) and other firms (construction) bid on the design specification to do the work.
Is an additional advantage of DB for the construction industry
the ability to change on the fly?
In days of yore before agile, I questioned the wisdom of separating designing and building into buttoned-up packages that marched in succession. I knew that
we learned things as we built
we adjusted accordingly
This is his first opportunity to build a structure that will provide decades of utility to others. I wondered if it would be his last opportunity to build a structure as opposed to conceptualizing a structure.
A side-benefit of agile is the organizationally-imposed distinction between architect and developer is blurred, if not irrelevant. In well-oiled agile teams, people wear many hats. As such, successful teams behave like start-ups (i.e., from necessity, they’re too small to segment specialties, so everyone does whatever needs to be done).
Design-build is personally satisfying, even if my design contribution is only to confirm what my more conceptually gifted team-mate, was thinking.