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 community 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. There are 7 sources of waste in software development.
- Unnecessary features – Start with specification and building of core user stories.
- Incomplete requirements – Addressed with detailed specifications user stories.
- 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, including 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. Make a shorter gaps between development and test.
- Talent Utilization – Developers should work close to the client side, so he/she could reveal and promote 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 project’s total overrun costs.
This happens because those three sources have the greatest interconnection among themselve. 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 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 approach is 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 making big milestones, or you’ll will be overwhelmed by bugs and feedbacks. You should be able to divide your project into small parts. Plus, be ready to being in touch with your users 24/7.
The original mantra is called “Decide as late as possible”. And, at first glance, it advocates quite unconventional approach to decision making. Lean advises 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 contrary, Jeff Bezos advises to act with only 70% of the information you wish you had, unless you want to be slow. Get the maximum information out of 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 in 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 to each other directly, letting the information and feedback flow though 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 to give 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 amount of builds will increase proportionally. Eventually, you risk to get lost in your own product builds.
That’s why Agile requires frequent and deliberate refactoring. You should keep 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 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 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 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.
Tony Sol is the business development manager of GBKSOFT, overseeing the production of all writings for both internal blog and external platforms. He is technical-driven person always looking for new benefits of merging business and software.
Other Articles of Tony
Similar Blog Articles
Agile Development 101 – Story Points Estimation
Frankly speaking, humans are really bad at making estimates. Especially, absolute estimates. Which is why estimation is often called an art of guessing. Fortunately, agile story points are here to fix this.
Discovery Phase: How to Explain Your Idea to a Developer
If you’ve ever tried to explain your idea to a programmer you probably faced some difficulties. This is why there is a dedicated development stage called “discovery phase”. You may say this is just a fancy naming for what’s called: find a common ground. And you’re probably right.
App Development 101 – Software Requirements Specification
Every software project needs a really good specification in order to succeed. Just like every construction needs a specification. But it takes a lot of time and patience to write down all the details on the paper. Plus attention to detail and mindfulness will help a lot. It must be acknowledged that specifications (software requirement...