"Think big, Act small, Fail fast and Learn rapidly"
Like TPS, LSD has some key principles which somehow fulfill the above statement as follows:
1- Eliminate Waste
Unfortunately for many of us, if you look around your office you'll find some people who almost do nothing or have small positive impact in the project development and life cycle. We all more or less know why these people are there, why managers must/like to keep them and can't/don't want to get rid of them (I'll talk about my experience on this issue soon), but if you really want a lean development and can't fire them, you need to use them somewhere or somehow else, otherwise your are wasting the money.
This is good side of the story, because it is obvious and can be seen by bare eyes. The followings are some examples of hard to find wastes in a development cycle:
- doing unnecessary code
- adding more and more unnecessary features
- delaying the release because you just find out a good new feature
- having not clear idea of what we want to do or what customer wants
- having too much documentation or useless commenting ...
- changing UI as you get used to it
2- Amplify Learning
Everybody should continuously learn, this is the only way we can make sure people make best decisions at work. Things like having project wiki, code review, knowledge sharing seminars or sessions, ... help people to always be updated and learn.
But in LSD we need to also focus on learning how to have better understanding of what user wants and how user can have better understanding of what we are developing. LSD asks you instead of doing things that has small or even no positive impact on project, pay more attention on what does have positive effect on the software development. So instead of paying more useless attention on documentation or some obvious commenting, try to have a better and more effective communication with your customer.
Don't plan or design behind a closed door and then suddenly show the result to the customer and ask them their idea and suggestion. Instead, make planning and design in short iterations and in each of them go for customer suggestion. This helps you and customer to have the same understanding of what you are doing.
3- Decide as late as possible
A bit strange, but true in a way. Remember working on a medium or big project with your colleagues. There are many times you make a decision and after a while you find out it wasn't the best, then you have to correct many parts of the written code or design.
The reason is if we have a small amount of facts and information then our decisions will be based on our thoughts and assumptions. In order to not let the project changes and uncertainties fight with the decisions you made, you need to delay the decision-making time. Only, in this case, you can make sure that you are making a decision based on the facts and valid information at the time the project definition gets mature.
4- Deliver as fast as possible
I remember there was a time when everybody used to talk about SSADM, a software development methodology based on waterfall, it was the only favorite methodology for software engineers at that time.
I remember after a while when customers' needs started to change frequently it didn't have the power of fulfilling the development cycle. The reason was that in SSADM each phase of the development cycle was a big and long phase and in this long period of time, many things had the possibility of changing. Now consider this scenario, IT technologies improve everyday, the likelihood of requirements changing get higher and higher, then when software development is done, it worths nothing! Because it is not based on customer's recent requirements but many months even years ago.
Today we have changes, we have technology evolutions, none of these heavy and slow methodologies work. So the shorter the iterations of the waterfall the better chance of developing software that fulfills the customer's requirements.
5- Empower the team
Empowerment is giving the employees required motivation, skills, resources, authorities, opportunity, and ... to do work on one side and ask them to be responsible for their actions and outcomes on the other side. The idea is based on many experiences especially in manufacturing and production lines that show in such a situation people work better and get a better result from what they are doing. They feel they work for themselves on their own product.
So do not give the programmers just completely defined tasks, give them responsibilities and let them decide what to do. Do not try to do all designed, important things and decision makings by few people and consider the rest of the team just as some micro task worker and programming machines, this doesn't give you the result you are looking for.
6- See the whole
The software you are developing should work from top to bottom and side to side, customer needs to get satisfied on all aspects of the software. So every member of the development team should think about the whole software, not just the part they work on it. This is the only way they can do their part as best as possible. If they don't they may make a decision or chose a path which is right for the part they are working on it, but not for the whole system.
7- Build integrity in
You can't have a software which has a very good front-end but a poor back-end or vice versa, and there exist problems in passing data up and down the application stack, this is not what customer looks for, this development is not integrated.
Primary designs are usually good and have enough built in integrity, the problem is the primary design is based on primary features and the features change during the time. This is the place you may start loosing built in integrity. Adding new features to the software should comply the whole software integrity. You have to do tests, re-factoring and ... as much as it requires to make sure the software still has enough built-in integrity.
