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)