The seven principles of lean software development provide a toolkit that can ensure more software functionality delivered in substantially less time, elimination of all unnecessary activities, cost reductions, while also inducing lateral thinking and enabling team empowerment.
Lean software development is an agile framework that focuses on optimising time and resources. The lean approach is more like natural selection, where one of the many designed products is chosen and developed through trials and customer feedback. The process of creating a minimum viable product (MVP) can be streamlined using lean principles, which focus on the rapid development process while ruthlessly cutting away any activity, feature or resource that might not affect the final product.
Minimum viable product
The idea of an MVP is that you should develop an actual product or service (which can be no more than a landing page — a service with an appearance of automation, but which is completely manual behind the scenes) that you can offer to customers and observe their actual behaviour with it. Learning from what people actually do with respect to a product is much more reliable than asking people what they would do. The main benefit of an MVP is that you can learn about your customers’ interest in your product without fully developing the product. This encourages teams to do the least amount of work possible for useful feedback. It helps them to avoid working on products that have not received good feedback. This is complementary to two other principles of lean software development — eliminate waste, and deliver as fast as possible.
In 2003, lean manufacturing was being closely studied by different industries including the IT industry. At this time, Tom and Mary Poppendieck published their book ‘Lean Software Development: An Agile Toolkit’. This book is still considered the all-in-one practical guide to lean software development and also gave us its seven main principles that are briefly discussed in this article.
1. Amplified learning
How can a species ensure its survival in the natural environment? The answer to this question is: natural selection. Now if only we could use some technique analogous to natural selection in software development. Sounds weird? Amplified learning is a good analogy to the biological mechanism of natural selection. In its most basic form, it can be defined as a method to initiate lateral thinking which generates alternative approaches to a single problem — the more the number of alternatives, the more is the chance of getting a better quality solution. It places huge emphasis on exploring all ideas at one’s disposal, before taking a decision.
User requirements are crucial yet complicated and evolve continuously; failing to understand these requirements can cause the project to fail. Amplified learning can help here. It also encourages open source developers to learn and implement new technologies that can help them gain experience in new ways to solve the same problem.
Amplified learning places heavy emphasis on prototyping and the concept of building an MVP, which can be directly tested as a working prototype with its key elements and features giving an insight about the market and users for the product.
Open source prototyping tools include Alva, pencil, Quant-UX, UXBOX and Akira. Almost all companies place great emphasis on fast but qualitative prototyping techniques, and some of them have developed their own methods of prototyping. For example, Apple uses an approach that it calls ‘pixel-perfect prototypes’ or ‘10-3-1 prototypes’. It starts with creating 10 independent concepts, from which three are selected, and from these the final product is created. Google uses a different approach called the ‘design sprint’ where a 5-day sprint (sometimes less than that) is divided into components called understand, diverge, decide, prototype and validate.
2. Delivering as fast as possible
Imagine having a revolutionary open source software idea that you are determined to make a reality, and all that hard work going to waste because someone somewhere came out with a solution to the same problem before you. That sure is a bummer. Lean MVP software development guarantees the release of the software as fast as possible while ensuring that the first iteration is robust, minimising the after-launch bugs. Through amplified learning and deciding late we have a fool-proof plan of what we want to do and what the product should look like. So while implementing open source, developers have to only focus on evolving a working product through rapid iterations.
There is fair evidence that suggests the software that comes first to the market often becomes the leader in that domain. Also, coming with a product first helps you create a loyal customer base and get faster user feedback for better feature and requirement adoptions.
Key factors that need to be kept in mind while delivering as fast as possible is the software’s high dependency on previous principles like amplified learning and deciding as late as possible, and focused productive work which can be hard to achieve if the team doesn’t have the synergy or the motivation. To summarise, one needs to have the right team while keeping it simple to deliver the product fast.
3. Building quality/integrity
For an open source product manager or developer, quality is crucial. It is very important to set a clear quality standard at the beginning of any project, which in turn streamlines the quality, integrity and maintainability of the project. Building and maintaining the quality of a product starts at the very foundation of a project with the definition of Done.
Done is a set of rules and practices defined at the start of any project by the developers, and approved by the stakeholders and the product manager, of how each module of the project should perform. This definition can be extensive and general or short, according to the level of quality the project requires.
4. Deciding as late as possible
Deciding as late as possible means that final decisions for further directives should only be made when they are required. This helps us in keeping the options open for as long as possible and leads to the following benefits. First, it gives us more time to acquire knowledge and explore other potential options in depth. Second, it helps in knowing and learning more about which option to Choose, based on product feedback and other changes.
Deciding as late as possible optimises the upside reward by delaying decisions until more knowledge is secured. However, this is only one of the two major benefits of this principle. Another major benefit of deciding late is that it limits the downside risk by eliminating the cost and time allocated to resolving uncertainty. Let us understand this with the help of an example.
HP sells printers all over the world, but it couldn’t accurately forecast how many printers it could sell in each country. There were always some excess printers in one country and not enough for another country. Moreover, they couldn’t sell printers configured for one country in another because the electrical configurations were different for each country. Then the company decided to do the final electrical configuration in the warehouses after the printer was ordered. Even though costs rose for a single unit, HP saved US$ 3 million a month by more effectively matching supply to demand. This is a classic example of deciding as late as possible to limit downside risk.
5. Optimising the whole
‘Optimising the whole’ encourages open source software developers to eliminate vicious cycles by operating with a better understanding of their own capacity. What is a vicious cycle, one might ask. A major vicious cycle that leads to sub-optimisation works as follows:
- Users demand some new features/bug solutions urgently.
- Developers are under pressure to get the changes ready instantly and at all costs.
- This results in sloppy changes to the code in the developers’ respective modules.
- Complexity of the code base increases.
- Complexity of integration increases exponentially.
- Number of defects in the code increases.
To get rid of this vicious cycle, we need to zoom out and look at the bigger picture. If we do so, we soon realise that most big delays, communications issues and misunderstandings are caused when the work of one developer is handed off to another developer. Thus, it is extremely important to focus on integration, one of the wastes explained in ‘eliminate waste’. Moreover, using kanban for workflow visualisation, measuring flow, prioritising, and managing flow goes a long way in optimising the whole process. Other than that, open source developers should organise teams by modules rather than by skills. This may help not only in optimising the workflows and integrating handoffs, but also by letting developers have a better sense of ownership for the modules they are working on.
6. Empowering the team
Timid teams and new developers can often wait for a long time for trivial decisions from more experienced developers. This can introduce a lot of delays. A good team leader should always extend some decision making freedom. However, the extent to which decisions can be made by new developers without the approval of experienced developers/mentors/managers should be clarified beforehand. Team members should not require approval where post-monitoring actions and feedback can work. More importantly, proactive team members should be recognised and developers should be encouraged to network, so that they can have a broader perspective of the organisation.
Eliminating spoon-feeding and encouraging new developers to do their own research can go a long way in building their confidence. Every member of the team should have clear instructions as to what they are accountable for and why they are an integral part of the project. Developers should also be clearly told what is mandatory and what is not, so that they can prioritise their work.
Most importantly, face-to-face communication over video calls or in person should be encouraged wherever possible. In these meetings, experienced developers should ask questions to specific developers instead of generally floating a question to the entire team.
7. Eliminating waste
‘Eliminating waste’ consists of seven categories, each of which is mentioned below.
Partially done work: This type of work is done haphazardly without any concern for the definition of Done (discussed earlier in build quality). This work, as a result of this bad practice, cannot be used by the development team in the final software, and thus the manpower and the resources used in making the module are wasted. Correctly defining Done can eliminate this waste.
Extra features: The Pareto principle or the 80/20 rule implies that 80 per cent of users will most likely end up using only 20 per cent of the features. The MoSCoW method is a type of prioritisation technique used widely in product management, where each feature is categorized into Must have, Should have, Could have and Will not have. This solidifies the priority of each feature and when it should be implemented.
Relearning/extra processing: Relearning occurs when different members of the team have to go on learning or creating a task/work that has already been done by some other member of the team. Seeing the project as a whole (discussed earlier in ‘optimising the whole’) can help with feature and module relearning. Other practices like daily stand ups and weekly meetings can help the team to get in sync with all the work being done for the project.
Handoffs: Handoffs occur whenever work is passed from one role to another. Another seemingly simple solution is to minimise the number of handoffs necessary to complete one full iteration — from the analyst to the tester. This can be done by making cross-functional teams. Product-oriented teams have other distinct advantages because they also share a common goal, which helps with another lean principle of ‘optimising the whole’.
Delays: Delays are anything that act as a hindrance to the commencement of a value adding process or elongate it. If team members don’t know what to do, they can either sit idle or switch to other tasks, either of which results in a loss of flow. This leads to partially done work. Delays can also extend the duration of feedback loops. To deal with delays, smaller iterations should be adopted as they require shorter deadlines, leading to faster feedback loops.
Task switching: We only have to look at one word to understand why task switching can be an issue that creates waste, i.e., flow. Every team member and, more importantly, programmer needs a free flowing chain of thought to optimise output. It takes a good amount of time to get into this flow, but it can be broken with the slightest disturbance or lateral thoughts. Jeff Attwood, the founder of StackOverflow, has said that by the time you add a third project to the mix, nearly half of the time is wasted in task switching. Mixing up fewer projects at a time is the best way to avoid this waste.
Defects: This one needs no definition because it is self-evident. However, what we can define is the waste created by a particular defect. This is given as: Waste = (Impact) x (Time). We can reduce defects by antibody tests. Whenever a defect is detected, the first step should not be to remove it. Instead, the first task should be to write a test which would fail in the presence of the newly found defect. This test should be added to the archives of tests. Whenever another developer reintroduces the same defect, it will be detected by that test.
Lean software development is a new practice that focuses on higher quality products made on the principles of efficiency, innovation and social empowerment. Principles like amplified learning and deciding as late as possible fuel innovation in a project, which is complemented by delivering as fast as possible and building integrity, focusing on the implementation of these innovative ideas and building a viable product. The principles of optimising the whole and empowering the team are focused on overall empowerment of the open source software developers, project owners, users and all the other stakeholders a project can have.
Lean principles are evolving and being refined constantly. The intertwined and complementary nature of these principles makes them very successful when managing any project.
