The Agile Approach to Software Development: Growing rather than Building

The term “building software” is frequently reference by tools like compilers or continuous delivery chains. Reproducibility is at the heart of these tools. If all things remain equal, they must generate the same result. We are talking about a software factory. However, building software is more about the tools rather than the development process itself. The development process can also be called “architecture work” or “software design.” In this case, the process shares more similarities with fostering the growth of a plant than that of building a house.

“Building” fits very well with the waterfall model:

• The final result and how you build it are defined from the start
• You complete each step and component in order, leaving integration for the end

This is successful because the subject is well-known and highly reproducible.

On the other hand, software usually requires Agile, or at the very least incremental and iterative development methods. In this case, “growing” is a much better fit:

• There is no predetermined end product as you adjust the software as you develop
• You develop a working product as soon as you can to get your feedback loop started

This is successful because you are improving and optimizing the end result as you go.

Building vs. Growing: A Matter of Mindset

In everyday life, we discuss the matter of perspective. In this case, the differing perspectives between building and growing are profound. The fundamental difference is reflected in multiple roles.

The Developer

The developer, rather than designing an architecture intended to meet the predetermined need of the project, promotes an architecture that can evolve over time and accommodate changes as they are needed.

This is why the developer promotes major principles such as “YAGNI” (You Aren't Gonna Need It), which consists of coding only the bare minimum for the need known today. You also have Emerging Design, in which architecture is conceived over time via the emergence of solutions, rather than anticipating what the architecture could look like.

Simply put, the ability to adjust code as you go is priority number one. It is useless to provide extension points everywhere in the code (because YAGNI!), when you could be replacing each individual piece of code to meet future needs.

Therefore, radical and frequent changes in product direction can be taken into account without it being a nightmare for the developer. Everything is done to let the team follow the evolutions of the need.

In a "growing" approach, the developer promotes an architecture that can evolve over time and accommodate changes as they are needed.

The Product Owner / Product Manager

In the same vein, the Product Owner (or Product Manager depending on your organization) adapts the way he or she works. Instead of imagining an ideal hypothetical solution from the beginning of the project, he or she starts with a minimal viable product that can probe the need then iterate on it with the continuous feedback from users. On a daily basis, the PO/PM designs the smallest possible features and tests them before developing them - “growing” them.

The watchword is "you know nothing," meaning the only truth is in the hands of the users. The team must reach these users as quickly as possible -- just as a seed does the sun -- to get rapid feedback that will render the software stronger and help it grow. Without user feedback, you are working in a vacuum and using your limited energy to go in a direction that may be useless.

Encourage Adaptation over Firm Directions

Finally, growing the software means adapting the development process to its very nature: versatile, flexible, and easy to update. This state of mind is essential and can be found in each role. Rather than defining all the parameters from the beginning, we foster evolution.

How can you put this into practice? Check out my second article - it focuses more on the concrete implementation in your projects and products.