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 softwarefor 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.
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