Evolutionary Software Development
Jakob Jenkov |
Evolutionary Software Development is my term for the simplified software development process that I use for all my private projects. Additionally, many of the development projects I have worked on that start out as scrum projects - tend to end up using a process that look more like evolutionary software development. Finally, I believe that evolutionary development is the best process fit for the Lean Startup philosophy.
Evolutionary Development Core Principles
The core principles of evolutionary software development, or just evolutionary development for short, are:
- Deliveries
- Evolutionary breakdown
- Continuous design, architecture and quality realignment.
I will explain each in more detail in the following sections.
Deliveries
The central entity of evolutionary software development, or evolutionary development, is the delivery.
Deliveries Are Work Products
A delivery is a work product such as a product that has been produced for a customer, or a bug fix, quality improvement or new feature for an internal tool, or a change to the organizational structure or processes.
Deliveries Must Be 100% Completed
For a delivery to be considered completed it has to be 100% completed as seen from your organizations perspective - and not just from your own personal perspective. There can be no more work left for your organization to fulfill that delivery to consider it complete.
A product produced for a customer must be 100% completed, packaged, shipped and received by the customer, for that delivery to be considered complete.
A bug fix, quality improvement or new feature for a software product must be fully implemented, tested, released and deployed (if you control deployment), for that delivery to be considered complete.
Follow-up support, maintenance and service of a delivered product is not considered part of the same delivery as the product itself. However, support, maintenance and service can itself be broken up into their own deliveries.
Deliveries Are Both Work and Time Scopes
A delivery is both a scope of work and a scope of time. The work scope of a delivery is typically fixed, whereas the time scope of a delivery typically depends on its work scope.
There are no hard limits for how small or large a delivery can be - both in terms of work and in terms of time. The scope is defined by what amount of work that you believe can be meaningfully delivered independently.
Sub-deliveries
Smaller deliveries can be grouped into larger deliveries for management purposes. For instance, a new release of a software product might consist of several bug fixes, quality improvements and new features. Each bug fix, quality improvement or new feature can by itself be considered an independent delivery. However, towards the customer receiving the deliveries it can make sense to group all these deliveries into a bigger delivery. The bigger delivery thus has a set of sub-deliveries.
There is no limit to how many levels of sub and sub-sub-deliveries you can have. The number of levels is up to you. Whatever makes sense in a given context - is the right amount of sub-delivery levels.
Strictly Time Scoped Deliveries
It can make sense to have some top-level deliveries be strictly time limited. For instance, you could have quarterly release which is strictly limited to whatever sub-deliveries that get completed within that quarter. It may start out with a planned work scope (sub-delivery set) before the quarter starts, and then bit by bit have its scope updated as the planned sub-deliveries are completed. Sub-deliveries that are not completed within that quarter may get pushed to the next quarterly delivery.
Top-level Deliveries for Business People
The top-level deliveries may only be interesting for the business or project management - as a way to track overall progress and assign budgets to the development project. The technical people (developers, testers etc.) will most likely be more focused on the bottom level deliveries.
The concept of deliveries and sub-deliveries is illustrated here:
Business People and Tech People Both Understand the Concept of Deliveries
The concept of deliveries and sub-deliveries is intuitive to business people as well as tech people. On the contrary, terms such as sprints, backlog, epic, story and task may take longer for business people to grasp. They also tend to take longer for tech people to grasp initially in my perception.
Evolutionary Breakdown
When figuring out what to deliver for a big system, it is common to do a functional breakdown of the system which breaks the system into smaller and smaller sets of functionality. The smaller functionality tasks (e.g. epics, stories and tasks) are then added to a backlog and prioritized. Evolutionary software development does not break down the functionality of a product or system like that.
Evolutionary software development always breaks down the functionality of a system into actual deliveries. In other words, you start by planning what the first delivery / release of the system will contain, then what the second delivery / release will contain etc. That means, that we do not break down the entire known functionality of a system ahead of time. We only break down the functionality of the system that goes into the next delivery, (or maybe a few deliveries ahead). This is what I refer to as an evolutionary breakdown.
Continuous Design, Architecture and Quality Realignment
Just like an evolutionary breakdown only breaks down the part of a system's functionality that goes into the next delivery (or next few deliveries), we also adapt the architecture, design and quality of the system for a given delivery.
In the beginning when the system is small, you can live with a simpler architecture and design, and with lower quality than later when the products gets bigger. As the product or system grows, it will often take a better architecture, a more rigorous design and a higher quality of the code, for the development team to be able to understand and evolve the system.
To keep the architecture, design and quality of the system at a level that keeps the system functional and evolvable, you will need to continuously realign the architecture, design and code quality of the system. Thus, continuous architecture, design and quality realignment is a core necessity of an evolutionary software development project.
This means, that we do not architect or design too far ahead, but rather design for the current, and perhaps next, delivery, and realign the part of the system that do not match the needs for these deliveries.
This also means, that you will have to adapt a continuous realignment mentality, meaning a continuous rearchitecting, redesigning and quality improving mentality.
The same is true of the system's documentation, by the way. Realign it continuously with your needs.
Keep in mind that we do not typically need a perfect architecture, design or quality for a system to operate stably, or for the system to be evolvable. We can typically with with a certain level of imperfection in the system, meaning a certain level of architecture, design and quality misalignment. However, if the misalignment gets too big, the system tends to become buggy and hard to evolve and operate. Then you need to perform some realignment to improve the situation.
You may sometimes have seen or heard the term refactoring mentioned in talks, articles and books. Refactoring refers to the principle of realigning the code design to the needs of the system. I just think the term "realignment" is more descriptive, and more easily understood by non-tech people such as business managers.
Plan Realignment as Deliveries
Realignment is not optional. It is necessary to keep the project operable and evolvable. Therefore, the technical team must insist on performing realignment continuously. If you ask the business people they will often consider realignment an expense they don't get any "value" for. But that is not true. The value is realized during the subsequent development and operation of the system in terms of faster development, less bugs, higher performance, lower costs - or whatever else a given realignment results in.
Since realignment is not optional, you should plan realignment deliveries along with more traditional deliveries such as bug fixes and new functionality.
The Lean Startup Philosophy is Evolutionary
The Lean Startup philosophy is a mindset and process designed to help startups find product-market-fit quickly, to make startups grow big quickly.
The core principle of the Lean Startup philosophy is to deliver a Minimum Viable Product (MVP) as fast as possible, which can be tested by customers to see if the functionality and design match their needs. The minimum viable product really should be as small as possible - while still being extensive enough to enable a customer to test the core proposition of the product. Typically, an MVP takes from 1 day to 3 months to develop. For some types of complicated tech the MVP may take longer, but most MVP's can probably be delivered within 1 to 3 months.
Once the MVP has been delivered, a Lean Startup keeps asking the users / customers for what functionality they believe they need. Then this functionality is added, feature by feature, as fast as possible, to keep increasing the product's value to the customer. This principle is illustrated here:
As you can see, the Lean Startup process is naturally evolutionary - and thus could fit the Evolutionary Software Development process.
Product Market Fit
The way the Lean Startup philosophy determines whether the product truly meets the customer needs is by asking the customers to pay for the product early. Maybe just a small amount, but still some payment. If the customer is not willing to pay for the product early on, the product may not really provide any worthwhile value for the customer.
Having a single, or a handful, of satisfied paying customers is not a product-market-fit. The term product-market-fit means that the customers are lining up to use the product. It is described to feel like the demand for the product is much higher than what you feel like you can supply. In other words, you have arrived at a product functionality and design which makes your paying customer base grow rapidly.
Even after a product-market-fit has been found, the Lean Startup process is evolutionary. You do not stop delivering new functionality as fast as you can, just because you have found product-market-fit.
Evolutionary Development for Installable Apps
There is a practical difference in how often you can release a product depending on whether your app is a web app installed on a web server you control, or the app needs to be downloaded and installed on each customer's phone or computer.
For installable apps it make not make sense to publish new releases every day. The end users might get annoyed if the app needs to update every day - or if they have to download and install new releases too often. In this case you may group the individual bug fixes, realignments and features into larger releases which you can release when you feel it makes sense.
| Tweet | |
Jakob Jenkov | |
