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

No comments: