Lean Development and Agile et all Part 2

Ok so we discussed parts of Agile and Lean Software development in the last post. In continuation with the same, we will cover the different aspects related to these terms so as to get a better understanding over the next few posts. In this post we will talk about Iterations and Increments, Testing and Test Driven Development.
Often the terms iterations and increments are used interchangeably. However there is a difference in what these terms mean when talking in the agile perspective.
Iteration refers to the process, the actual way in which you develop. Its basically defining a fixed cycle of a development period. Why fixed, well we will go into the details of why the cycle needs to be fixed as we continue discussing. Normally the cycle varies from a week to six weeks. If the cycle is longer, it is recommended to have a shorter cycle to maintain a hierarchy.
Increments refer to the product. How much of the product has been delivered since the last iteration. Now what is the measure for determining how much? Is it the lines of code, number of classes, number of components. These terms are pertinent to a developer. What we instead look at is the consumable/usable functionality that has been added to the product since the last iteration. This functionality has to be complete and usable by the user of the system.
Iteration need to be time-boxed and have a ritual. A few common traps to fall into is well, lets say we have an iteration cycle of 2 weeks. Lets say at the end of the cycle, we are not quiet done. So we say lets say the iteration is complete but continue it till Monday. Now a small thing but unfortunately this is an addiction most teams fall into. Iterations need to be serious. After the end of the iteration cycle, we should have a demo. Lets talk a little as to what went well and what didn't. What functionality is complete and whats missing in part. The intent is to learn from each cycle so that there is improvement over cycles. Everyone needs to know when an iteration is complete by having a demo and some retrospection. The intent of the retrospective is to correct what is not right. There's no point knowing it unless you take corrective action. Also the intent is to be fail fast. We should know where we going wrong fast and not wait till the last. The feel where we are going to be complete for an iteration has to be there.
Increments need to be visible. Its about functionally complete slices, not abstract deliverables or work in progress. We need to work towards a list of prioritized items. There are different ways of prioritizing. Some follow the DSDM(Dynamic Systems Development Method) way, where the categorization is MoSCoW - Must have, Should have, Could have and Wont have. Although you can come up with your own categories. This also applies to projects which have a strong architectural perspective. And most importantly, the increment needs to be tested to be considered complete.
Test Driven Development is often confused with unit testing. Well let me clarify. The intent of TDD is not the Test but the Driven and also the Development. TDD does not intend to check the functionality of your code. Rather, it defines what functionality the code should implement. Tests drive the development. They allow the design to be explored. Tests are meant to check the specification of a unit's behavior. Well the difference in having a specification in a document as opposed to a test is that as a test you have a specification which can be run, which is executable.
I'll try and follow up on the same principles in later posts.
(Followed From Lean Development and Agile et all Part 1)

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 ...