Lean philosophies and principles for project management.

This is our early lean philosophies and principles for our project management.

We have spent quite some time in deciding how we want our team to deliver a feature, how to keep our cost low by avoiding wastage.

Thanks to Avi Cavale (Shippable Co-founder), I met him at DevOps Days, Bangalore. He gave a quick walk on “The Toyota way”. This was an eye opener, took hard and long effort in understanding the nitty gritty of the lean principles from Toyota, yet to learn a lot as it is more of a practice. In 2 years of practicing it, we have derived our delivery model to meet what we define as lean and value driven focus.

All our decisions are driven by the 14 principles of the Toyota way, while we have our reservations and changes to the original principles as it may not meet for all the cases in a startup, the changes are accepted by case, only when needed.

The DevOps, our release model keeps changing based on our continuous learning and business needs.

Here are few thoughts we had in our early days to start with, the following are not organized and drafted for strong principles but guidelines and was from the early days, we are still shaping and making changes to it. Most of them are part of the 14 principles.

“Much of the stress that people feel doesn’t come from having too much to do. It comes from not finishing what they’ve started.” — David Allen

• Focus on one item and deliver it properly, rather taking too much and not able to complete most of them, ensure the team members work with only one task at a time.

“The more inventory a company has, the less likely they will have what they need.“ — Taiichi Ohno

• Small batch of changes to production or each single change to production, which ever works but avoid inventory of completed work, each hour of delay or waiting is actually an inventory, this can be completed work or work waiting for others to test, certify or approve.

“Use visual control so no problems are hidden.”
Principle 7 — The Toyota Way

• Pick or design tools and process to show the problems visually, so we can act quickly.
• Take decisions based on data, if we don’t have data, start collecting them, introduce a system to collect data, we can improve its accuracy over time. Improvements are measured based on metrics, if we don’t have metrics, consider no improvement.
• Automate when you are doing mundane repeated tasks, may be boring tasks often. Use people to solve problems creatively than just doing without much intelligence.

The above guidelines force us to have process everywhere (added over time). So we don’t have the same problem repeating again, the process slowly improved to address various issues, introduced by changes and by the process itself.

We started to log everything we do, may not be a perfect one, but the time spent and what we do were properly logged, so we started analyzing them later. The log produced data, which helped to improve our process, measure the metrics, watch the change.

We used kanban board and just sticky notes as paper cards, this helped us to visualize the problem and take decisions faster, but this did not give all the metrics we need, we had various input to visualize our problems, which actually improved over time, while the simple tools are good, there are problems with our scaling, we need to handle the growing team and tasks that we do.

Watch for continuation on the project management with more details on the tools and process, how our DevOps process and culture work.