Lean Software

Tonight I attended Mary Poppendieck's talk about Lean Software development that the Calgary Agile Methods User Group (CMAUG) was putting on. It was interesting - Lean Software Development essentially boils down to streamlining the whole process so that software is made when requested by a client and is developed with the client in mind. It takes the larger view of the development cycle where Agile development is a part of the process, rather than being focused purely on the development.

I was wanting to talk in depth about it but my ISP was down for a while and so my thought's have gotten mixed up unfortunately. Regardless, one of the things she talked about was Just In Time development. In a manufacturing environment, a company wants to have as little inventory of finished product as possible on hand - better to create as needed (as Dell has much to its success). From a development perspective, Mary argues that inventory in software is any piece of software that is exists in a semi-finished state (i.e. code that addresses a goal and is tested) that is not making money. I realized that this was essentially what the project that I recently finished was - and it was a failed project.

Another concept was that of releasing software as soon as it addressed a basic goal. Once this has been done, features can be added in any order. From this perspective, the timeline between iterations would be very small. Also, Mary believed that the organization of human resources in software projects was in itself wasteful, wanting teams to stay together through different projects, allowing for greater cohesion and specialization.

My thought on this goes a step further - a team as a whole should follow the project through all cycles, from design to implementation, to testing, and finally deployment. While I recognize that there is the need for some specialization and people have different strengths and weaknesses, my thoughts are that as a worker in IT, I already have to know the basics of everything. I'm a developer, and not only that, a contractor who handles custom projects. So, I have to be able to take a project through all the cycles. Also, as everybody in the industry knows, it is a constant learning process - new technologies and new methodologies. So my suggestion is this - have the team work together throughout the various stages, but the person(s) who specialize in the area lead for that section with the project manager to keep the project focused on the needs of the client. So the architect would lead for the design of application, the developers would code the design with the architect looking on, and all taking part in testing with the QA people designing the tests for the application, with the others implementing the tests. Keep the team in a smallish area (but not cramped - just not spread out through a building) and allow them to work on very short cycles.

Just some thoughts...