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.

Whitepapers

The Essential Guide To Agile Testing

Discover why the hottest startups and established enterprises are turning their focus to agile development.

Read 'The Essential Guide To Agile Testing' Now
Want to see more like this?
Jean-Pierre Lambert
Writer, Speaker about Agile Quality - Creator of Scrum Life
Reading time: 5 min

Improving Digital Quality in 2023: Where to Focus

Learn the quality systems, processes and capabilities that drive outstanding digital experiences and customer loyalty

5 Highlights from the 2023 State of Digital Quality in Europe Report

Learn what's in the State of Digital Quality in Europe report this year

How Vodafone Shifted User Acceptance Testing Left

Learn how Vodafone embraced Agile and shifted user acceptance testing (UAT) left.

Benchmarking Progress Toward Digital Accessibility

Survey results show organizations are placing a higher priority on accessibility and inclusion

Advancing a Culture of Inclusivity and Equity through Inclusive Design

A look at one of the sessions from the recent Vista Equity Partners UX Design Summit

Win Subscribers with UX, Localization Testing

Either understand your customers, or try to comprehend why they unsubscribed