The Agile way: grow instead of build

Put it another way: living organisms is a better analogy than house building

Jean-Pierre Lambert
Jean-Pierre Lambert's blog
6 min readJun 11, 2018

--

Creating software is often compared to building. Yet growing is actually a much more accurate analogy.

Photo by chuttersnap on Unsplash

Building software is a very common term used by many software tools like compilers, continuous integration and continuous delivery software. It goes back to the idea of software factories where their job is highly reproducible, running in loop the same jobs.

Yet this part is just about the tools themselves, not about the development process itself. You might want to call it architecture or software design too.

Indeed the development process is more alike to growing plants than to building houses.

Photo by Daniel McCullough on Unsplash

Specifically, building fits very well with the waterfall model:

  • We define in advance what must be built, and how it will be built
  • We proceed step by step, focusing on components and leaving integration for the end
  • Overall, it works because the subject is very well-known and highly reproducible

On the other hand, software usually requires Agile or at the very least Incremental & Iterative Development methods. In this case growing is a much better fit:

  • We don’t know in advance what the result will be like; the whole process will adapt along the way
  • Focus on getting something working end to end as soon as possible to make sure we got it right, but also to get early feedback
  • Overall, it works because the process acknowledges and takes into account the fact that we don’t know where we’re headed

Growing software?

What’s growing?

Photo by Evan Kirby on Unsplash

Bootstrap software

At the beginning of a new project (or at the beginning of a new feature, if you’re part of the lucky ones into the product world) your first focus is to have a single use-case working end-to-end.

It has to be vertical: the goal is to traverse all the layers of the software, requiring a little slice of each layer.

It must be typical in the sense that the most biggest challenges will be tested upon by getting this use-case to work. For instance if the software has a database, you want your use-case to make sure we need the database. You want to make sure that risks are under control. This also includes integration of the various layers of the software: software is integrated at all times.

You want it to be as basic as possible: while it is vertical and typical, you want the use-case to bring as few novelty as possible. Because the goal is to get it done quickly! So you’ll get the first use-case to be basic so that you get feedback early.

When you have implemented this first use-case, it might not sound as a big deal since the new feature embryo is very basic and barely brings any value… Yet:

  • It is bringing value, even if it is only a little
  • It is demonstrable, meaning that the little value is real value that makes sense to everyone, plus you are able to gather feedback on it!
  • It helped designing the software for the major challenges, ensuring that risks are handled and thus that upcoming development will go smoothly
  • And finally it brought this value quickly, which compensates vastly for the small amount of value

And then, growing software

Now that you have this embryo up and working, you can go full steam with the growing process:

  • Add small changes that always bring value
  • Changes and their value are always demonstrable
  • Changes are always integrated with the rest of the software
  • Changes can be done on various parts of the software, without endangering the whole software

Really, think of it like a plant. Don’t add a whole new branch with leafs and fruits:

  • Add a single new small branch
  • Make an existing banch stronger
  • Add a single leaf
  • Add a single fruit
  • Make the roots stronger

At any point, if you get it wrong, you can revert to a previous well-known state. It’s easy because the steps are small, and should you trash your code, that’s OK because you trash only a small amount of work.

Adaptable

What happens when a plant encounters a fence? A rock? Another tree?

Well, it goes around. It may take a weird shape but it’ll grow nicely around.

Or maybe it will grow another way. It’ll take the easiest route to the best place with both sun and water.

That’s adaptation in all its glory.

Story splitting & product management

Growing brings clear backlog item splitting guidelines

In case I were not enough explicit, this metaphor is giving clear guidelines on how to split backlog items:

  • Make sure the software is living at all times: demonstrable, fully integrated
  • Make sure that all backlog items are bringing value
  • Split backlog items to get small workable tasks that enable to get feedback quickly

Growing is the proper software development mindset

This way of thinking also bring an interesting mindset:

  • Make sure that the initial phase of work will deliver a living software but also that the software design is sound and relevant
  • But don’t overplan: get the software moving with as small as possible pieces of work
  • And be always open to trashing code to make the software grow into its next step

Growing is how product management works

In the end this is deeply aligned with product management:

  • Design small features, test them and then get them better and better
  • To get there, work with the smallest possible increments and iterate as quickly as possible
  • Make sure that risks are handled or else speed of product development will be impeded
  • Non-visible/non-demonstrable work has no value
  • Don’t waste time doing it if it doesn't bring any value

It’s actually much deeper than the growing analogy

We could dig in deeper and deeper in the growing analogy… And see that Agile can be successfully compared in many ways to nature itself:

  • The default rule is distributed governance and taking decisions at the lowest possible hierarchy level
  • Resilience is paramount; redundancy is rarely seen as a problem
  • Each environment leads to its own best answer
  • Adaptation capacity is more valuable than planning ability

Nature is king of complexity

Photo by Tj Holowaychuk on Unsplash

Having life on Earth is incredible by itself.

Think about it: even the simplest organisms are already very complex.

Can you only imagine the level of complexity in our world?

  • Each of our cells are complex
  • These cells create complex organs together
  • All these organs makes a complex living being
  • At each of these levels, the interactions between the elements is also complex
  • Think of our brain: we don’t even know how it really works
  • And now we can speak about how the various living being are living together…

In a few words, nature is so full of complexity that the core elements that allowed life to flourish are certainly the right way to address complexity.

We’re just rediscovering what nature found out by itself billions of years ago…

Liked this article? Show it!

Please clap 👏 and share the article! It is because of you that I put my heart and soul into writing.

And follow me on my blog to be notified when I publish new articles!

Thank you so much!

--

--

Software engineer with special interest in quality and business value, now a technical/Agile coach helping teams to deliver high-value, high-quality products.