Let me guess. You’re stranded. You just wanted to create a simple mobile app and here you are – sitting in front of 10 Wikipedia tabs, learning new words. You may be overwhelmed with new terms, tech names, programming languages, and concepts.
Nevertheless, you should be proud of yourself. You’ve come THIS far! Choosing software development model in hard, no joke. Scram, Waterfall, Agile, Lean, Kanban, XP, Continuous Integration, Continuous Delivery… Getting to know each of them is hard. Lean Development especially.
In fact, Lean is one of the most well-thought development models. It derived from the Toyota Manufacturing System, and it has many tricks inside.
Basic Lean Development Practices
So you’re thinking about Lean Development, huh? Without a doubt, Lean is claimed to be the most cost-effective model that can be used for organization of software development process. Nevertheless, Lean is not a magic pill.
You might be heard that Lean Development practices have been widely accepted by the Agile community. And Agile approach is so much praised by startup communities nowadays. Nevertheless, Lean does not equal to Agile by 100%, and you can go Agile way without using Lean, and vice versa.
SPOILER: Lean Software Development better suits continuous projects built by in-house team, which ensures direct communication between the customer and developers. The model reveals its full potential over long distances. Lean better suits long-terms, evolving projects that receive constant feedback from the users.
At this point, you may feel confused, so let’s just get into details and you’ll see what we’re talking about.
Values and Principles of Lean Software Development
Eliminating Waste with Lean Thinking
Eliminating waste means getting rid of Muda – non-value-adding activities. It must be acknowledged that in order to eliminate waste you should be able to see it first.
Lean philosophy determines 8 types of waste or Muda in manufacturing:
Obviously, there are no physical goods in software development. Still, app development process often has activities that do not add value to the project. Here are 7 sources of waste in software development and ways to reduce them.
- Unnecessary features – Start with specification and building of core functionality for the first release of the product.
- Incomplete requirements – User stories should be completed with detailed specs for the developer team to address with.
- Extra Steps / Iterations – Code directly from user stories and get verbal clarifications specifically from the client.
- Finding Information – Keep everyone involved in the project in the same room through regular meetings, including the client.
- Defects not Caught by Tests – Apply a test-driven development. Tests should be performed by developers, QA team, and users.
- Waiting (Customer/Team side) – Make shorter iterations between deliveries and shorter gaps between development and test.
- Talent Utilization – Developers should work close to the client side, so he/she could reveal and promote the best performers.
The practices mentioned above will help to deal with waste, but it won’t be enough if one doesn’t follow other Lean principles.
Statistically, the biggest waste producers are Unnecessary Features, Incomplete Requirements, and Defects not Caught by Tests. Those three sources of Muda can contribute up to 50% of the project’s total overrun costs.
This happens because those three sources have the greatest interconnection among themselves. Incomplete requirements result in unnecessary features, that result in unforeseeable bugs, and on, and on, and on…
That is why Lean Development encourages to adhere to the golden rule: If some activity could be bypassed or the result could be achieved without it, it is waste.
Unfortunately, outsourcing doesn’t allow clients to be in direct contact with their teams. This fact can result in miscommunication and waiting. Lean development doesn’t have a recipe to overcome this drawback.
That is why you’ve got to have a professional project manager on the project and create detailed specifications up front.
In addition, Lean requires a continuous flow of feedback from end-users. It advises making shorter iterations between deliveries of user stories. In practice, you can’t show the project before its core is ready. This situation usually occurs in secretly-developed corporate projects and apps in “stealth” mode.
Lean Development requires constant learning. Instead of blindly following specification and long upfront planning, lean process goes in short sprints: one at a time. Thus, the methodology allows trying different ideas by actually writing code and building.
In order to sustain such process, Lean Model requires direct communication with users. The pros of such an approach are that your developers will better understand problems, get maximum information, discover bugs early and grow product according to real-life challenges, not theoretical ones.
The obvious drawback is that you need to maintain this pace all the time. You can’t afford to make big milestones, or you’ll be overwhelmed by bugs and feedbacks. You should be able to divide your project into small parts. Plus, be ready to be in touch with your users 24/7.
The original mantra is called “Decide as late as possible”. And, at first glance, it advocates quite an unconventional approach to decision making. Lean advices to postpone decisions until the very late.
This mantra doesn’t encourage you to waste time. On the contrary, you should acquire as much information as possible. That way Lean forces you to keep the product clear of the unnecessary functionality and use resources only when absolutely necessary.
But don’t take this principle for granted. On the contrary, Jeff Bezos advises acting with only 70% of the information you wish you had unless you want to be slow. Get the maximum information out of the current state of things and don’t expect to be 100% sure before acting.
Let People Do Their Job
Empower the team. Lean requires complete presence at the moment. Otherwise, you’ll struggle finding Information, thus make waste. That’s why you can’t afford vertical management. “Lean” managers are taught how to listen to the developers.
Moreover, no micromanagement is allowed. People should communicate with each other directly, letting the information and feedback flow through the team.
This value is closely related to the previous one: “Decide as late as possible”. If you want to make the right decisions at the last moment, then you need to take decisions directly on the front line. There is no place for the general.
For good or for bad, not every client can provide such level of trust to the outsourcing team. Trust is earned as you work together. Because of this reason, it is advised to switch on Lean model when the project goes to the maintenance.
Lean call for short iterations and advises giving the right of decisionmaking to the team. So good so far. But this practice also means that you’ll get too many small batch pieces of code. If the work within Lean-driven project goes in short sprints, the number of builds will increase proportionally. Eventually, you risk getting lost in your own product builds.
That’s why Agile requires frequent and deliberate refactoring. You should keep the product’s parts together and balance between flexibility, maintainability, efficiency, and responsiveness. After all, the client buys a complete product, not parts of it.
In addition, integrity fends of the temptation to make edits in something that already works well. By preserving integrity your team will be forced to go ahead and develop the product instead of improving unnecessary things.
Although, there is nothing in such an approach. The waterfall-driven projects usually preform reintegration after each milestone or several milestones, depending on the complexity of the project.
See the Whole
Everyone (including sysadmin) should keep the big picture in mind over the course of Lean development. If you’ve hired a dedicated team, this is an easy task. Unfortunately, not all projects are made by an in-house team.
Sometimes your developers may work on several projects in parallel. That’s why it is advised to have a Scrum master, who will document user stories and keep the goal in mind. Project Manager can do the trick too.
This is 100% good advice. Despite the fact that it can be applied literally to any work on Earth!
Unfortunately, only a few of us can see the Big Picture. On top of it, as a product owner, you should be able to see beyond your own project. You might need your product to connect with interrelated systems so that your solution would fit into the existing ecosystem. Software developers won’t think so many steps ahead. For good or for bad, you can’t demand from a frontline soldier to see beyond the tactical map.
Without a doubt, Lean method for waste minimization is great. Unfortunately, it has its own inner constrictions that don’t allow it to become a universal development approach. The first and foremost one is the distance between the client, development team, and end-user. Hopefully, most of Lean development practices could be applied without the need to hire an in-house team of developers.
Moreover, there are many cases when it is more appropriate to use old-school Waterfall model. Both in terms of time and cost saving. In addition, there are ways to enhance Waterfall model with Agile practices and get the best of two worlds.
Contact Us to Get your Project Done