Have you ever caught yourself thinking after finishing your software development project that you could have done it way simpler, faster and better? “Tell me when I haven’t!” – you may joke. If so, have this quick read to find about 7 Lean Software Development Principles that will help you deliver simpler, faster and better. We want it to be fun for you, so we asked Mrs. Doggy Dog to make you company.
Mrs. Doggy Dog is a top manager at Ruf-Ruf Software Development Company. She’s been wondering for a while how to improve the software development process at her company to add more value for the customer. So she found that the Lean Software Development Principles will do just fine for the purpose and is eager to share her knowledge with you. Have a good time together!
Before we start learning about Lean Development, let’s find out where it comes from.
A history of Lean Software Development Principles
Classic Lean Principles in Production were first introduced by Toyota in the 1970’s. Back then Toyota applied the principles of Lean production to fight General Motors – its major market rival at that moment. It managed to do it successfully, by the way. You can find more details about how Toyota got on top of GP in The Machine That Changed the World by James P. Womack, Daniel Jones and Daniel Roos, which is considered the classics of the Principles of Lean Production.
How did the principles of Lean Production make their way into software development?
Lean production was too great an idea to stay solely within automotive industry. It actually spread among various fields, such as medicine, retail, – anywhere where repetitive processes occur. Tom and Mary Poppendieck, the authors of a best-seller Lean Software Development: An Agile Toolkit were the first to introduce it to the software development industry.
Waste is horrible. What waste you can get rid according to Lean Software Development Principles?
Unnecessary functionality. Over 60 percent of functionality is never or rarely used. At the same time, to produce it, the software development team needs time, resources and feedback.
Delays. Wasted time results in low team spirit and reduced efficiency. How can developers shine when the project is interrupted all the time?
Vague requirements. Unclear requirements give no guidance to the software development team. Be 100% specific about the final product, otherwise you won’t get what you want.
Bureaucracy kills the projects.
Poor communication (especially to stakeholders) is wasted communication, as it doesn’t deliver the message so you have to double check everything or harmonize issues endlessly.
Handoffs, partially done work and task switching are definitely a waste to get rid of. It diffuses employees’ attention and reduces efficiency.
Defects. Everything that should be redone steals your precious time and should be eliminated.
Build quality in
Quality issues have been already referred to above, in defects, where they were called waste. Yet, it is also a standalone component of Lean Development. How to build quality in then?
High quality work is a matter of discipline, high commitment and great team play. Combine these three elements and also give a try to the following tried and tested practices:
- Pair programming. Two heads are better than one
- Test-driven development. If testing criteria are written prior to the development stage, the chances are high the code will meet them.
- Develop in increments and ask for feedback. These two recommendations belong to the Agile family of methodologies. Agile is great, be Agile.
Why are we talking about such an obvious thing as knowledge and how it can refer to the Lean Software Development practices?
- Common corporate knowledge gives all your employees access to your accumulated expertise. Thus, newbies don’t have to reinvent the bicycle, thus solving the problems faster and more efficiently.
- It enables smooth onboarding.
- Common knowledge base safeguards your software development team from critical team members’ departures.
Things you should have to create knowledge in your company:
- In-house trainings, seminars, webinars, other in-house education activities.
- Corporate knowledge base
- Mentorship (code reviews, progress management)
- Pair programming.
In the age where we all want commitment from the start to defer commitment sounds weird, doesn’t it? However, it’s not exactly about loving the things that you do or being not fully committed to the project success. Deferring commitment is about timely (or late, to be exact) decision making, and the best decisions are made after a good deal of thinking. i.e. closer to the end, not start.
In his lecture on Lean Development, Boris Nadion quotes himself: “Leave the decisions to a smarter person. It’s you, only later”, he often says to his clients. With the course of time, when more data is available to you, more blank spaces are filled and more clarity is added up as to the project’s TA, budget, deadlines, etc. decision-making process will be more efficient. As compared to the project initiation phase, closer to the end you have reliable input data to project the outcomes, rather than intuition and enthusiasm.
“Hey, dudes, what was that? I thought I need to take my time…” Yes, this was what we meant. At the same time, the software development team should deliver fast in order to achieve max efficiency and enable lean development. There’s nothing controversial about it.
Hackernoon has a great passage describing this particular lean highlight. “Lean teams don’t work endlessly or over-engineer. Lean teams enact simple solutions, receive and incorporate feedback and keep moving forward.” That is by delivering fast we don’t mean delivering thoughtlessly within tight deadlines, without due care about the resulting product. On the contrary, such dynamics kills team spirit and projects.
Thus, by this point we mean eliminating handoffs and partially done work, task switching, reducing WIP, breaking down communicational barriers between the teams, promoting autonomy to achieve max focus, engagement and efficiency to deliver one specific feature lightning fast.
To learn to respect your talents, learn first to
- Create a favorable environment for each software development team member
- Lead by example
- Empower your people
- Give them innovative freedom in tools and approaches
- Never blame your talents for project failures.
As long as these five measures are in place, point six from the lean software development list is implemented.
Optimize the whole
Optimizing the whole workflows, procedures, development methodology, etc. is more of a bottom line, not a standalone Lean Development Practices list item. If you don’t need a procedure – get rid of it! Your talents are suffering from too much control from you? Optimize that thing, too! Eliminate communication barriers between your teams, say good-bye to delays, defects, too long steps, handoffs – anything that doesn’t add value to the customer. This requires a little bit of brainstorming and observations. However, in the end, when all the redundant stuff is out, the air gets fresher and healthy ideas start flowing in.
- Waste (after you get rid of it, you’ll have more space for quality work) 2. Quality (once you’ve done the task right for the first time, you have the knowledge how to do it right again) 3. Knowledge (accumulate the knowledge to take the right decisions at the right time) 4. Late commitment (great decisions allow achieving success fast) 5. Fast delivery (talents deliver from the first shot (which is fast) if you respect them) 6. Respect for your talents (committed talents produce great outputs and leave minimum waste) 7. Optimize (leave as little trash in your project/everyday life activities as possible).