Agile Development - Lean

Last article I started mumbling about Agile and why companies were adopting Agile methods. The focus was on why projects were failing using traditional software development methods.

Until recently I was mostly focused on Scrum and extreme programming but I always heard good things about the Lean approach. So I went to the net and got a book that I recommend Lean software development by Mary and Tom Poppendieck(http://www.amazon.com/Implementing-Lean-Software-Development-Addison-Wesley/dp/0321437381/ref=sr_1_2?ie=UTF8&s=books&qid=1245442337&sr=8-2). This article is an attempt to summarize the ideas as I understood and give you guys started on the subject.

Lean Software Development

Let’s start with a more formal definition. Lean software development is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the Agile community.

Lean Software Development is not a management or development methodology per se, but it offers principles that are applicable in any environment to improve software development.

So in that way the tenants or principles of this methods can be mixed with the process defined by Scrum for example. More and more I feel that there is not a right method but smart leaders or managers should be able to use the best of each approach adapting to the reality of his/her group. Here are the Lean principles:

1. Eliminate Waste

Basically everything not adding value to the customer is considered waste. In other words: “In software development, waste is anything that does not improve the quality of code, reduces the amount of time and effort it takes to produce code, or does not deliver business value to the customer.

2. Amplify Learning

Constant learning will minimize the numbers of problems/bugs. The best approach for improving a software development environment is to amplify learning. The creation of bugs should be prevented by running tests as soon as the code is written (TDD). Instead of adding more documentation or detailed planning, different ideas could be tried by writing code (Spikes).

For programmers to develop a system that delivers business value, they will have to learn about many things. Some are technical some are requirements but overall the leaning will benefit both.

3. Decide as late as possible

The development process is always associated with some uncertainty. By delaying decisions to the “last responsible moment” you are toying with the possibility of avoid change. In a nutshell the principal states that you should delay decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions.

4. Deliver as fast as possible

Deliver as fast as possible has a lot of relationship with the iterative SCRUM model. We are not talking about the whole product as fast as possible but verticals that deliver value to the customer.

If we can deliver quickly we can receive feedback quicker and therefore fine tune our direction with mode certainty. Constant cross correction is important on a agile method.

5. Empower the team

The quality of a software team (the people factor) is the most important element in successfully delivering software. In order to get people to take responsibility, get motivated, and gel as a team, they need to be responsible for the outcome and authorized to make it happen.

The pyramid leadership model is long gone. You can not do everything by yourself. You have to empower your team; give them responsibilities and of course make them accountable.

6. Build integrity in

The ever demanding Customer needs to have an overall experience of the System – this is the so called perceived integrity: how it is being advertised, delivered, deployed, accessed, how intuitive its use is, price and how well it solves problems.

Conceptual integrity means that the system’s separate components work well together as a whole with balance between flexibility, maintainability, efficiency, and responsiveness. This could be achieved by understanding the problem domain and solving it at the same time, not sequentially.

7. See the whole

Software systems nowadays are not simply the sum of their parts, but also the product of their interactions. Defects in software tend to accumulate during the development process – by decomposing the big tasks into smaller tasks, and by standardizing different stages of development, the root causes of defects should be found and eliminated.

Conclusion

I will continue talking about Agile on the next article (probably some basics in scrum or tools used in Lean) but the lesson I take from this is to understand the principles and slowly bring to the methodology being used in your team.

If you can’t convince your management that Agile is the way to go at least you can use some of the concepts (TDD, pair programming, sprints, etc.). I guarantee that picking at least one will bring benefits to the overall success you the team. Next time try Test Driven Development for a while and you will see the code quality improve.

Enough for today… until next time

Reference

Lean Software Development Overview

Lean software development (Wikipedia)