Lazy-Loading as a Project Development Approach
Demanding resources and efforts is easier when it is a part at a time
Human being reacts to rewards. It is a chemical reaction in our brains and bodies. Many things can trigger those chemical reactions to make us feel rewarded. It could be eating, shopping or even marking tasks as completed.
Remember also that our brains are lazy machines that are trained to do as much as possible with the least energy and effort.
Both of the above behaviors apply to the organizations in which we work. Many projects die before being completed due to their size and complexity, and the team or company never realize their return on investment. Many other projects don't even start because they seem too expensive (in terms of time or money) compared to what the company has budget for.
Luckily, there is a way to combat these failures in product development. It’s a management practice borrowed from the code that our teams are producing: Lazy Loading.
Breaking projects into smaller steps creates a perception of easy execution. Small components are delivered quicly and easily, so the team stays motivated and the work gets completed.
What is Lazy-Loading?
Lazy loading is a technique used by developers and UX experts to deliver value to the user, as soon as possible, loading content only when the user needs it. In user-facing applications, lazy loading enables a smooth usage experience by delivering the content faster because the load time is shorter since the part of the application being loaded is smaller.
Applying this concept to project development means breaking down the project into smaller parts (atomic features) and prioritizing the execution in order to deliver value faster and based on what your client (platform user, boss, team member) really needs.
Atomic Features
Breaking down large projects into small features can be tricky. Sometimes you can break it down into more parts than necessary, which can make things overly complicated. Even worse, the parts can be made so small that they do not deliver any value by themselves.
The best way to measure how well your parts are separated is by asking yourself if each individual component is an atomic feature.
An atomic feature is a feature that delivers value by itself, so they can be released to users without other additional characteristics or business rules.
Let's go for a practical example: assume that we need to develop a coupon discount feature. The coupon may be a fixed discount value or a percentage of the total order. Managers could set an expiration date or usage limit too. The coupon must be configurable to be used across all store purchases or only when a specific product is the shopping cart.
Breaking down a project into atomic features is selecting the features that can stand on their own. For the example of our coupon feature, we could organize it as follows:
(a) create coupons with a (b) discount value as a percentage above the order total price (notice that we group to features in order to create the first atomic feature)
develop the expiration date for coupons
develop the usage limit for coupons
develop coupons with fixed discount price
develop coupons that are applied only with specific products inside the shopping cart
It is important to see that in order to make the feature atomic, we needed to group two features as one deliverable (adding coupons and setting value as a percentage). Without it, the feature would be not suitable for usage.
The above order could vary widely depending on business and user needs. And that is the extra benefit of this planning technique: if you prioritized correctly and the project is terminated or backlogged in the middle of development, you know you have already developed what is most important to your company and your users.
That way, in case of any interruptions to your project development, you can guarantee that:
The product is more advanced than before because it has new features live
No project is dropped without any outcome
The most important parts of the project for the business are already being used.
Projects that can not be published in parts
There will be cases where the project is broken down in small parts, but they cannot be published separately. This is a common scenario in one of the cases below, and to overcome them, the tech team will be your lead.
Backward Compatibility
Backward compatibility is the most common reason why you cannot publish something a component until the entire project is completed: a third party integration, a new API that needs to be rolled out, an API that needs to be deprecated, etc.
Many difficult situations with backward compatibility can be overcome by following one of the strategies below:
Set deprecation periods, and allowing teams or clients to try the new version allows you to deliver value to users without requiring them to migrate to a new version at the same time. For example, you might be developing new website interface versions where you can release a "try out" button for new interface with the option to revert to the original.
When the release is blocked by a technical issue, evaluate if it is a common problem between the majority of your customers. If it is a concern, then the best you can do is invest time and resources developing fallbacks.
If there are enough resources and time, plan to add a feature-flag architecture, so you can configure when to make new features public without releasing a new distribution because the code base is already part of the main project code base.
Developing any of the suggestions above requires more time and resources from your team. However, they are often a one-time investment, because all new features will use the same architecture. The upfront cost will be paid off by your ability to deliver value much faster.
When there is a specific release date
When a product is secret until release, or it is only relevant to be used after a specific date in the calendar, it will block you from making project parts live.
If merging code is not possible too, you are at risk of getting mentally demotivated, falling out of sync with the main project architecture, or creating a gap in delivery perception for customers. That is the moment to use some sort of ratio of resources and develop side projects (the simple or fun features that people always ask for but is never prioritized).
There is always anxiety when people are working in secret or when they are waiting for something to happen.
Go get other smaller projects to run in parallel inside the sprints. Those smaller projects will produce deliverable results for your clients or your team, and make you feel you are moving forward. That's the feeling we're always chasing when we release something new. The brain is trained to reward itself, so we must scratch that itch regularly.
If you are using the Road Framework for product development, it is a good idea to rotate between one or two other projects in the pipeline. At Ingresse, for example, we have this road we call "T.G.I.F" (Thank God I'm Fresh). Inside this road, there is a small and fun selection of projects: the kind of projects everybody would like to do, but they would never be prioritized because they are not as strategically important.
In development or in life, breaking things down in smaller steps will always make it easier to move ahead. An there is always space to breaking something into a smaller part, the only responsibility you have is to make sure the steps are moving you forward and not keeping you at the same place.
P.S.: Always deliver your sprints
Be it through internal e-mail, a planning wall, or routine meetings, never forget to announce the team last releases and recall everybody where they are in the "project timeline".
Since the projects were broke into smaller parts, sometimes it is hard for individual developers to have a global view. Like when someone is swimming, sometimes they need to stop to breath and make sure they're still on track. Reminding your teammates where the overall project is heading will keep individual contributors motivated and the team in-sync.
It is like asking someone who is swimming to stop to breath and look around to review the direction.