Planning ahead in software development – just enough
Big Design Up Front (BDUF) is dead. There may not be too much agreement about any one thing in software development, but the industry has pretty much concluded that BDUF doesn’t work.
As Agile practices and mindset took hold, up-front architecture was essentially looked down upon. And for good reason: in many cases, a system architecture can evolve and be adjusted over time as the system matures. We call this emergent design. (On the far side of the continuum of up-front planning, opposed to BDUF, lies “Just start coding”, which is still practiced quite a bit too, with varying degrees of success as it is more the extreme case, but may be sufficient in simple cases.)
Another mantra circulating in Agile circles is to focus on and start with the easiest thing that can possibly work. This approach allows us to focus on solving the immediate problem at hand while ensuring we are not pursuing an overly complex solution. The theory is that – with the help of emergent design – the implementation can be adjusted down the line.
However, as organizations scaled their development teams and systems grew more complex, problems started to surface. It became problematic for several teams working on the same large solution to let design simply “emerge” in real-time, at the team level. After all, an application architecture is not fully malleable and might be resistant to change. And several teams working on the same application require coordination, agreement on architectural approach and at least some level of planning. A more intentional architecture was needed, without resorting back to the BDUF days. And therein lies the key, which is more art than science: finding the sweet spot between emergent design and intentional architecture (see Agile architecture).
The SAFe folks coined a term which I find quite useful due to its graphic nature: architectural runway. The mental picture that comes to my mind is this: a car (the development team) is moving rapidly on a freeway. In order to run smoothly and at high speed, it needs a solid road (architecture) to drive on. This road cannot be paved in complete real-time (emergent architecture), but working ahead of the car and paving the road just enough is required. This is what the architectural runway, created via enabler stories and features, is about. They provide the runway that is subsequently consumed by functional features and stories that rely on it. To avoid too much early architectural complexity, the phrase mentioned earlier could be re-written to say “what’s the easiest architecture that can possibly work”?
I believe this approach is a good one and solves for the architectural needs of more complex solutions without the challenges of BDUF. However, I do really like the notion of “runway” and would like to extend this metaphor a little. While architectural runway often only extends a few weeks or maybe a quarter (PI), there may be (or even should be) a longer-term vision to help guide the way. While not as concrete and defined as the immediate “pavement”, this vision provides a direction for the future. The manifestation of that vision is the product roadmap. (The fact that this term again alludes to transportation may or may not be coincidental.) The roadmap provides a directional map for where the product will go over the next 6-12 months. While not fully fleshed out and with lower level of fidelity, it may provide just enough information to allow for better design and architecture in the short-term. It is like a map for where – at a high level – the runway / road will have to be extended and the territory ahead. When faced with near-term architectural decisions, having this long-term direction may be the information needed to break the tie between various competing approaches.
In addition to extending the concept of runway (mid-term) to roadmap (long-term), I’d also like to apply this concept in one other area: user experience (UX). Similar to how small architectural decisions can easily be made in quasi real-time within a small team, minor UI/UX decisions can be made in the same way within the team (and in the current sprint). However, more complex new features require more forethought and intentionality. Furthermore, good UX should include iterative discovery to validate problem and solution space. This process involves outside entities (such as users, focus groups, existing & potential customers) and may result in significant iterative changes to the solution (pivots) or even disqualify it, which could be a good thing because eliminating a bad idea early on in the process is much easier and cheaper than developing, launching and supporting a product or feature that’s doomed to failure from the beginning. Due to this variability, discovery is often much less predictable and “plannable” than architecture work. One approach for dealing with UX ahead of delivery (development) is dual track development, in which UX discovery and design happen ahead of software development. This – in essence – is another form of runway, in this case focused on user experience (UX runway).
In summary, nobody really wants to engage in BDUF any more. But we have also learned that doing everything just-in-time has its own significant drawbacks. Therefore the concept of a runway, be it architectural or UX-focused, is useful as it attempts to strike the right balance between emergent and intentional design. While runways tend to be mid-term only, having a roadmap will be helpful to see what’s further out and on the road ahead, so that better decisions can be made in the short-term.