Saturday, January 31, 2009

Seven Principles of Lean Software Development - Eliminate Waste

Picture courtesy of Phil Romans@flickr
Peter Stevens in his newest post advices how to deal with current crisis using Lean methodologies. One of his advice is to eliminate wastes, not costs. I totally agree with it, more so it is one of the most important (at least for me) principles of Lean Software Development.

Software development organizations should always strive to produce the best products and to deliver only features that are of paramount importance to their customers. They should always try to develop those 20% of functionalities that represent 80% of the value. This need is more vivid and desired during such global business conditions. This could apply to all types of enterprises - you should eliminate all unnecessary steps and waiting periods; you should strive to get the value as soon as possible and to get only pure value without any waste.

In this post I will try to explain "Eliminate Waste" principle from "Implementing Lean Software Development - from Concept to Cash" book.

Provide market and technical leadership
Your company can be successful by producing innovative and technologically advanced products. Important thing here is that you understand what your customers value and you know what technology you're using can deliver.

You don't necessarily have to invent something that is new and unknown. Note that the richest companies just replicate good ideas adding just few features that are unique and that satisfy customers (e.g. Google Mail, JIRA issue tracker).

You can be the market and technical leader by improving existing ideas and fitting them so that the final product will attract more customers.

Create nothing but value
You have to be careful with all the processes you follow. Be sure that all of them are required and they are focused on creating value.

If you are e.g. creating lots of documents that have been always produced but nobody really knows why and you are pretty sure nobody reads them - it sounds like waste you have to eliminate. Another example of waste is when you have to wait for a long time for some other department or team to answer your questions or uncertainties and this waiting period always stops you from moving forward. Waiting is the most apparent and obvious waste - though it is not always easy to eliminate.

You should measure your process cycle efficiency and strive to keep improving it - it will probably never be perfect but it can be constantly getting better and better.

Write less code
This advice is quite aggressive and when you work in old-fashioned waterfallish organization saying that you should limit the features in your system to only those that are absolutely necessary and deliver value can be perceived as some kind profanation. Well.... it's not.

The more code you have the more tests you need thus it requires more work and if you're writing tests for features that are not needed you are simply wasting time. If you don't have tests (is it possible?) it's even worse - there is bugs in a code that is not used and they will appear in the least predictable moment. I personally remove a lot of code when I take over some projects. I focus on the required features and remove all stuff that I "may need in the future". The rule is simple: if you need it, add it - if you don't need it right now, remove it. Another argument standing for writing less code is that usually with less code the overall complexity is lower and the code base is easier to understand thus maintain and support.

Last thing - the easiest way to identify unnecessary code is to use code coverage tool. More details can be found at the provided link.

Eliminate Waste
I hope pieces of advice given above will make it easy to understand how to put "Eliminate Waste" principle, which is the most important one IMHO, in practice. If you need more detailed description with more examples and more sophisticated explanation you should definitely go to "Implementing Lean Software Development - from Concept to Cash" book.

PS. Six remaining principles described earlier can be found here:
  1. Respect People

  2. Deliver Fast

  3. Optimize the Whole

  4. Defer Commitment

  5. Build Quality In

  6. Create Knowledge

Wednesday, January 07, 2009

Seven Principles of Lean Software Development - Create Knowledge

Picture courtesy of J.C.Rojas@flickr
"There is no fool like an old fool" says popular international proverb. One of the meanings of this proverb is that people can make mistakes but they should learn from them. You are not a fool if you make mistake but you become one if you make the same mistake again. It simply means that you're not learning.

The same rules apply to the software development teams - it's much easier to work in an environment that encourages you to learn and to create knowledge. Why should you create knowledge? Well, the best way to learn something is to make mistakes by yourself but it wouldn't be wise to let all the engineers invent the wheel all over again. It's much better to teach them about what we already know, what works and what doesn't. It's much better and safer (yet a bit less effective) to learn from someone else's mistakes.

In this post I will try to explain "Create Knowledge" principle from "Implementing Lean Software Development - from Concept to Cash" book.

Create design-build teams
It is essential that the architecture of the software you're building is easily "splittable" into logical modules that can be implemented by cross-functional teams. These teams should be provided with appropriate leadership and be encouraged to engage themselves in the project and provide intensive feedback. My translation of this is that leader of the development team has to listen to his/her members and ask smart questions encouraging them to look for the answers and to get back with encountered problems or invented solutions as soon as possible. These teams should be encouraged by the leaders to share early and often, to fail fast, and to learn constantly.

It is pretty easy to imagine the contrary i.e. team members just waiting for others to fail noting every mistake and using it during 360 degree yearly evaluation. It must not happen! Team members have to teach each and help other. They should install some Wiki and put there whatever they think will be needed in the future. They should encourage each other to experiment and not to be afraid of failures - failures are great as long as you learn something from them. The last thing, though, you can learn from your failures is not to try again. Failures should be accepted by applaud - the team would know then which way they cannot go and invest in - it can save some money.

Maintain a culture of constant improvement
As a leader you must create such environment in which people will not be blaming each other for writing crappy code or designing crappy class or package structures. You must create environment in which people will be constantly improving what they are working on. People should also know that they are not and should not be perfect - they always have a field to improve and they should do it.

You as a leader must know that even if everything works fine there is always places that could be improved - encourage your team to identify such places and fix them. Such "place" can be a policy or practice, not necessarily source code, that makes development cumbersome or is basically not necessary and doesn't improve the overall results.

Teach problem-solving methods
Your team should not only learn and teach each other - they should be able to solve all kinds of problems in a structured way e.g. Plan Do Check Act. Development team should often behave like small research institute, they should establish hypotheses and conduct many rapid experiments in order to verify them. Your team should also produce concise and valuable documentation keeping up to date knowledge base of what works and what doesn't.

Create Knowledge
I hope pieces of advice given above will make it easy to understand how to put "Create Knowledge" principle in practice. If you need more detailed description with more examples and more sophisticated explanation you should definitely go to "Implementing Lean Software Development - from Concept to Cash" book.

PS. Five principles described earlier can be found here:
  1. Respect People

  2. Deliver Fast

  3. Optimize the Whole

  4. Defer Commitment

  5. Build Quality In



Originally published on AgileSoftwareDevelopment.com