The Agile Approach to Software Development: Growing rather than Building

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 Now
Want to see more like this?
Jean Pierre Lambert
Jean-Pierre Lambert
Writer, Speaker about Agile Quality - Creator of Scrum Life
Reading time: 5 min

Digital Quality Matters More Than Ever: Do Your Experiences Keep Customers Coming Back?

Take a deep dive into common flaws in digital experiences and learn how to overcome them to set your business apart.

4 Ways to Get Maximum Value from Exploratory Testing

Well-planned exploratory testing can uncover critical issues and help dramatically improve the customer experience. See how to guide testers to where exploration can yield the greatest returns.

3 Keys to an Effective QA Organization

Get your internal, external and crowdsourced testers on the same page

What is the Metaverse? And What Isn’t It?

It’s not far-flung sci-fi anymore — the metaverse is here, and it requires companies to rethink their approach to UX and testing

Why Machine Learning Projects Fail

Read this article to learn the 5 key reasons why machine learning projects fail and how businesses can build successful AI experiences.

How Localization Supports New-Market Launches

Success or failure in a new market is all about how you resonate with customers — don’t skimp on prep work