Lean Development, Agile et all part 1

Agile has been around for some time and there has been acceptability across a wide range of teams. Lets delve a little into what aspects agile offers, some common misconceptions of agile and what a lean development takes care of.
For a long time, there has been a misconception that agile implies rapid. Well does it mean you churn out code and features at a breakneck speed. Well where does that lead. To the well known bug list and failures of projects. Not really. The intent of agile is not on the rapidness as understood by many. Its intent is on sustainable and responsive development. Development where there are feedback loops at all levels, customer goals, test results, team feedbacks. The intent is to have tangible deliverables at short intervals of time and a review process to evolve it. Agile development is a lot like a tracer bullet. Every iteration shows how far you are from the perceived goal and refine until you strike the target. Its about the planning and not the plan.
Lean Software Development encompasses a set of principles which lay a structure for lean development. These can be classified as
1) Eliminate waste - As an example, think of the common scenario where you have to people working together. Lets say a Business Analyst and a Software developer. Now in the common scenario, these two would be interacting with each other using some media as paper. They would transmit the document, approve/suggest and re-transmit. Now as humans we are not fond of reading. Some of the most known guru's of software engineering have written some wonderful books. But the most time these guys spend is traveling the world telling people what they have written in these books. The paper ways are a huge waste of time, at the point they are initially exchanged and subsequently when they are debated on. The best way would be to put these guys together and discuss. Then whatever they come out as a document is an agreement and not a work of art on a specified format.
2) Amplify learning - Walking on water and developing software to a specification are both simple processes, provided both are frozen .This was a comment made by a great man long time ago. Its funny and cute but its a bit wrong. Even if the specifications don't change or the technology doesn't change, one thing thats bound to change is you as a developer. Thats because you learn as you build software. Use this learning to improve is what amplifying learning is all about.
3) Decide as Late as possible but at the same time decide as fast as possible-Sounds contradictory but true. When are we most ignorant about the software we are building, at the start. Can guess work reduce your risks. Most definately not. Hence decisions should be made when you have sufficient knowledge. But no later than that.
4) Empower the team - Well simply put, if you dont trust your developers, dont hire them.
5) Build integrity - We are here to build software that lasts. Dont take shortcuts. Dont avoid the good practices for the behest of speed. A lot of products have a core part. A part which few people know and want to work on. Working on that core is a job noone wants to do. The reason, well lets assume you start with a speed x of working. Now due to some factors, you are falling behind. Lets say you avoid writing the unit tests, and dont follow some of the code guidelines. Ok so you got it done in the time allotted. Next time when you work, you are wodking on a bad codebase. Hence your speed decreases and you follow the same workaround. As a result, this process repeated over a period of time will bring your productivty to an almost zero and an unmaintainable codebase.


I will be following this post with later ones that carry on the same idea. Till then ...