Agile buildability

Time and again Agile technology professionals are faced with the same problem. They can’t deliver end-to-end slices of functionality because of the way the system has been designed. The result is that they can’t deliver demonstrable value early, which is one of the core principles of Agile. They end up implementing compromised approaches that usually involve component teams with dependencies between them and mini-waterfall type projects.

The net result is that the solution is difficult and uneconomical to implement. At best the delivery is slow, at worst quality problems and an inability to scale the delivery teams. Delivering large and complex projects in this way becomes very risky and expensive.

In the construction industry, there is a concept of 'buildability'. Engineers and Architects work together and pay close attention to the design from the perspective of those who will manufacture, install components and carry out the construction works.

This approach recognises need for engaging practitioners who have hard-won experience and awareness of on-site practicalities and potential pitfalls. The buildability exercise looks at ways to ways to achieve the desired final quality, meeting all the customers’ requirements, removing risk, and achieving optimal value for money.

Due to the nature of construction, the design cannot evolve in the same way that a technology design can. This represents a tremendous opportunity for IT, and usually it is wasted as we attempt to mimic the Big Design Up Front (BDUF) required in construction.

So, what does buildability look like on an Agile project?

Within an Agile framework, buildability must be an iterative exercise. Unlike construction, a technology design can benefit from evolving as it is built. Feedback on the requirements can be shared with the team at regular and continuous intervals. This requires a “just enough design” approach under an umbrella of the wider conceptual design.

The following are important considerations:

Integration: The design teams, the delivery professionals and the software engineers must work together to create a buildable design.

Engineering Knowledge: This comes from the teams who will build the software. No one can make a decision on behalf of the people who will be building the final solution. Assumptions around how things will be be constructed are a source of waste, with potential for re-work.

Recognition of Team Skills: We all want (and sometime assume) a team of “A” players, but in reality we have a mix of skills and experience on a team. We cannot assume an 'A' player outcome with all 'A' player skills. The delivery team must regularly come together as a team, to feedback into the design from a buildablity point of view.

Product Objectives: These need to be aligned and verified by the engineering team. Product Managers must learn to play to their team’s strengths. It’s great to have a product vision, but having an unbuildable dream is dangerous. The engineering team can promote approaches and techniques that are of value, and which will inform product decisions.

External Factors: These include the costs and capabilities of partners, and of software and systems that are to be integrated. It’s important to ask the right questions around capabilities of partnerships and whether working with an external dependency introduces any risk to the Agile delivery dynamic (it probably will).

Engineering Context: What is the ecosystem within which the project lives? Is a single large piece of software being built across multiple delivery streams, or will it be loosely-coupled microservices? Will there be any governance consideration that could de-rail Agile delivery, or undermine the effectiveness of the delivery team? The need for Agile scaling is important. This must be done in a way that empowers the engineers building the software.

Software Engineering Methods: Decide what the methods are to be used and implement them early on.. Going back to retrofit unit tests or automation is fraught with danger and will result in low quality and rework, and will consume cost. Rework is waste. By delivering high quality outputs the rework is minimised, the flow of value is increased and costs are saved.

Collaboration and Cultivation: Without due consideration, the latent command and control governance style may emerge and destroy the ability of the teams to deliver. This will result in component teams, and integration teams that try to put all the bits together. The race will be on to “Just get it Done”, and the result is no flow, reduced quality and late delivery of value. It’s much better to create designs that can be delivered by communities of independent development teams. Whilst this isn’t easy, it’s a critical aspect of buildability and will pay dividends in the long run.

Feedback: The most important and most overlooked aspect of successful Agile delivery is feedback. This should be a two way process between designers and software engineers to discuss opportunities for saving, resulting from new work, or simplifying designs into pragmatic deliverable units of value.

The opposite of the 'buildability' approach could be loosely called an ‘artistic’ method, where the designer hands a concept drawing to somebody else and says ‘build that’, with little concern for how the design should be built. Buildability should be viewed as the ease with which the software can be built. Let’s take a page out of the construction industry’s book and start paying attention to the designs we try to develop. Without proper consideration we face many more years of failed software initiatives.