The Agile Approach to Software Development: How to Grow (Not Build) Your Software

In my previous article I explained the concept of growing your software in contrast to building it. In growing, you are able to take advantage of the very nature of software -- its versatility, flexibility, and ease of updating -- versus a more rigid building approach. Today, we will examine the practical implementation of this “growing” approach.

Growing the Software: How to Get Started?

Step One: The Use Case

At the beginning of each new project, your first focus is to have a single use-case working end-to-end. For this to be most effective, your use case should exhibit the following three qualities: vertical, typical, and basic.

It should be vertical in that it involves and crosses all the layers of the software, requiring a little slice of each layer. For instance, a web application should involve both the front end (data and presentation layers) and back end (database and data processing layers).

It should be typical in that the biggest and most common challenges are tested by its completion. For example, if the software has a database, you want it to be tested to ensure that risks are under control.

Lastly, it should be as basic as possible to introduce as few variables as possible. The goal is to get this use case done quickly so you can get feedback early.

At first glance, this use case is only an embryo of functionality that provides little value. And yet:

• It adds value, even if only a little bit.
• It is demonstrable, which means that the value is clear to users -- and you will be able to get feedback on it.
• It helped design the software by taking into account the major issues and ensuring that risks are managed -- helping the remainder of development to proceed smoothly.
• This value is realized quickly, largely compensating for the small amount of value actually produced.

Step Two: We Grow the Software

Once you have this functional embryo, you can move on to the growing phase, as described in the previous article. This means that you:

• Add only small changes that always add value.
• Ensure that changes and their value are always demonstrable.
• Always integrate these changes with the rest of the software.
• Must impart these changes on different parts of the software without endangering the entirety of the build.

At any time, we can make a mistake and quickly return to our previous state. It's easy because the steps are small, so if you have to throw away your code, that's no problem. You only end up throwing away a small amount of work.

Product Management: Work in Small Increments

When growing software, working in small increments is key to the product development process. To do so, the following directions should be followed:

Provide Clear Backlog Splitting Constraints

• The software must be alive at all times -- demonstrable and fully integrated.
• All of the backlog elements must add value.
• To obtain feedback as quickly as possible, it is necessary to split out elements of the backlog.

Adopt the Right Mindset

• The first phase of work must make it possible to obtain a live build but also ensure that the software architecture adapts to the project.
• While producing functional software, provide no more than the bare minimum.
• Be ready to throw away any piece of code that would prevent the software from easily ‘growing.’

Stick to the Principles of Product Management

• Design small features, test them, then optimize them -- which is the Lean Startup approach I described in a previous article.
• Work incrementally and iterate as quickly as possible.
• Ensure that risks are properly accounted for, so as not to jeopardize the speed of product development.
• Do not waste time doing what does not add value.

The Risks of Ignoring the Grow Mindset

If you continue to operate in a build mindset, you limit the progress you can make towards implementing a truly Agile practice. Even worse is if you believe you have adopted an Agile practice, but your product operations remains unchanged. Here are the consequences you may encounter:

• Your ability to bring your product into production is limited. You explicitly plan production release times rather than having a potentially deliverable code base at all times. The immediate result is each production launch comes with its share of unexpected and unpleasant surprises.
• The product is not designed to be modifiable. The more the code base grows, the more difficult it becomes to modify it. The team becomes less and less predictable while production time estimates skyrocket. The consequence is developers complain as soon as a new request arrives.
• The system rebels. Faced with a lack of flexibility, the whole system rebels against the business and its users in order to limit evolution (and efforts) as much as possible. For example, the definition of ready becomes increasingly strict and procedural. The team begins to talk about "scope creep," referring to unplanned requests that will delay launch but are actually critical to the end user.
• Doer vs. Strategist. Your team develops the mindset of the ‘doer’ rather than thinking about the real meaning behind the product and the service it must provide.

When you think about it, becoming Agile while continuing to build rather than grow means that you are most likely just working the same way as before and probably doing ‘faux-Agile’. You cannot make any real, tangible progress.

An Analogy to Live By

To conclude, making an analogy between software development and the way elements grow in nature makes sense. Nature is so complex that analyzing the fundamental principles that have allowed life to flourish is certainly the right way to address the complexity of software development projects.