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)

Agile Development

It has been a while since I wrote my last article. I am going to a transition period and trying to identify which will be the new area I will tackle.

Since I’ve always had my weakness on studying development processes I’ve decided to pause the technical articles and talk a little bit about Agile development.

On this particular article I will talk about why more and more companies are adopting some form of agile process.

Causes of Software failures

In most of unsuccessful projects the following factors are identified as causes:

Frequently and Rapidly Changing Customer Requirements

The problem with conventional software development such as waterfall is the assumption that customer requirements are static and can be defined by a predetermined system. It is interest that although throughout the years we slipped the schedule or had to make inhuman efforts to deliver the software on time we never stopped and realized that something was wrong with the process. That requirements were changing and we put out foot down and said you can’t change this because it is not in the functional specification.

Requirements change, and change frequently throughout the life of most systems, they cannot be adequately fulfilled by a rigid design. "Do It Right" has also been misinterpreted as "don't allow changes”. If the changes are not allowed customers are not satisfied. If the changes are allowed the company will have problems in delivering the software in compliance with the project base line.

Supreme control on one hands

At large the software development companies still follow the central control model where decisions “need” to come top down. This method actually increases the lead-time and makes the whole process rigid and slow.

Agile process favors a more democratic decision chain where the “soldiers/team” in the field are the ones responsible and accountable for the decision.

Rigid Project Scope Management

Holding the project scope to exactly what was envisioned at the beginning of a project offers little value to the user whose world is changing. In fact, it imparts anxiety and paralyzes decision-making, ensuring only that the final system will be partially outdated by the time it's delivered.

The way to build software today should be prepared for changes and allow the user to do so at any time. Of course changes in the requirement may incur changes in schedule or delivery order but nonetheless the goal is to deliver a final product molded accordingly to customer asks.

Traditional methods favors linear development

Most of the quality issues in the software components are also because of the linearity in the development process that does not allow the iterations and quality checks to occur before the components move to the next stage in the development cycle. So the development progresses even there are some quality issues ' Bugs'.

Conclusion

This article presented the common problems found in the most traditional development processes. Traditional development has always been rigid, not promoting requirements changes, democratic decision making and not engaging QA sooner in the process.

Next articles I will engage on talking about some of agile development that I was exposed: scrum, lean, eXtreme Programming. The goal is to present personal experiences in such methods exposing the good and the ugly hopefully open up the article for discussions.