Yesterday was my first actual day in the conference here in Oulu. The day started for me with the tutorial from Mary Poppendieck about Lean (Agile) Software Development.I had read her book and learned from it a lot. In the tutorial she touched on several interesting aspects that are not very obvious from the book. The ones that I found more interesting were:A (large) defect list in a company usually acts as a buffer between the developers and testers, a bit like a SLA (Service Level Agreement) measurement between both organizations, but that effectively prevents communication from happening between both organizations. Mary pointed to an example of a project that had around 51 defects listed throughout the full length of the project (3 years), why that happened was that people went in and fixed any bug that was found. Mary advocated a "stop-the-line" policy for bugs/build failures and similar problems. When a bug is found or if a continuous integration build fails the whole team should stop committing until the problem solves.Another point mentioned was the "capacity dilemma" for managers. Normally managers like the idea of "everybody being busy", of course, according to Queuing Theory this actually means that people are a lot less productive as there is no buffer to accommodate variability in the arrival of work. She gave the example of Google that has the 20% rule - in which developers are allowed to use 20% of their time in their pet projects, but of course, when there is "crunch-time" they do have that 20% extra to absorb the extra work-load. Posted by

Yesterday was my first actual day in the conference here in Oulu. The day started for me with the tutorial from Mary Poppendieck about Lean (Agile) Software Development.

I had read her book and learned from it a lot.

In the tutorial she touched on several interesting aspects that are not very obvious from the book. The ones that I found more interesting were:

1. A (large) defect list in a company usually acts as a buffer between the developers and testers, a bit like a SLA (Service Level Agreement) measurement between both organizations, but that effectively prevents communication from happening between both organizations. Mary pointed to an example of a project that had around 51 defects listed throughout the full length of the project (3 years), why that happened was that people went in and fixed any bug that was found.


2. Mary advocated a "stop-the-line" policy for bugs/build failures and similar problems. When a bug is found or if a continuous integration build fails the whole team should stop committing until the problem solves.


3. Another point mentioned was the "capacity dilemma" for managers. Normally managers like the idea of "everybody being busy", of course, according to Queuing Theory this actually means that people are a lot less productive as there is no buffer to accommodate variability in the arrival of work. She gave the example of Google that has the 20% rule - in which developers are allowed to use 20% of their time in their pet projects, but of course, when there is "crunch-time" they do have that 20% extra to absorb the extra work-load.