Embrace Modular Technology & Agile Process to Deliver Business Impact (Section 5)

Agile Process Delivered in Harmony with Architecture

In the prior four parts of this series, the ways in which Modularization approaches can assist to avoid technical debt and empower the Agile development process in ongoing feature work have been discussed. There is a counter reality to this as well, namely that it is the role of sound development processes to maintain that same extensible architecture as much as possible.

Enlightened product owners will allow for some portion of sprints to undo architectural damage caused by compromises of previous sprints, although this may often be less effective than knowing how to avoid the compromise from the onset. There are times when speed of delivery dictates a well understood and controlled technical debt accrual, yet often the detrimental processes that undermine architecture are more hidden.

Consider the following scenario.

Sprint 1.

Product Owner: “I am including a story around an upcoming feature in this sprint. We’re not delivering this yet, but I know that there is an architectural problem, and I want to give the team a chance to think about it.”

Team: “We discussed this, but the person who knows the most about this is out this week, and there seems to be a solution so hopefully it is the right one.” 

Sprint 2.

Product Owner: “The spike was not conclusive last sprint, so I need us to deliver this functionality this sprint.”

Team: “The person who knows the specifics of that area is back, but has limited time. We chatted about it in a pull request. I am not sure we have time to change how we have done this.”

Sprint 3.

(A different team): “It is a shame that other feature got implemented in the way it did. We need to do something similar, but cannot follow the same pattern. And, now the codebase is going to suffer from some confusion between the two approaches.”

Reading the above realistic scenario assembled in summary form makes clear the need for an architecture document. The very nature of Agile delivery is that it relies on team members being empowered, having overlapping skill sets which allow work to continue without becoming blocked by specific individual’s expertise in a specific area. Formal statements of architecture and guiding principles act to widen the pool of developers able to make decisions that contribute to and maintain architectural integrity. Where Agile delivers small bites of functionality, architecture is by its nature a big picture pillar.

While architectural plans and documents are of significant importance, the documents are not necessarily the creation of a single or select group of developers. Rather, they represent critical elements derived from decisions taken from a vantage point contemplating important future considerations. The strategic questions which have recognized answers can be more easily moved past in the course of ordinary sprint work once determined. Where questions are reached for the first time, the architectural plan can grow and become refined.

By recognizing the strategic lines which different implementation details cross, it is easier for a development team and product owner to more successfully choose when to take short-cuts in the interest of immediate gain. In this way, the purely technical requirements needed to keep the development machine running efficiently can be given a voice to compete with pressing needs of functionality being delivered.