One of the misconceptions I’ve made while working with software development teams using agile methodologies is that I initially confused bugs with problems and I tended to believe our agile process was Lean, as it made bugs visible. During the last few months, this idea has cleared up a bit and, in retrospect, I now believe that our agile team producing bugs was not a Lean system producing learning opportunities : it was a team having quality problems, which is something I have seen with many teams.
Ladies and gentlemen, it is a huge honor for me to announce that I have an article published on InfoQ.
Back in the days when I was an airline mainframe developer whose career had been violently hit by Spetember 11, I was desperate to switch to Java professional world and was an avid reader of theserverside.com. Floyd Marinescu was its creator. He also later became the author of EJB Design Patterns – one of the first book where I read something linking the way we work with the quality of life (even if one may argue that it might be challenging with EJB, anyway …).
In 2006 he went on to create InfoQ with a strong focus on agile methodologies : it soon became my main source of information of all things agile. Having an article published on this site is probably as great an honor for me as it would be to jam with Johnny Marr.
The article, a rather technical one, is about the path I followed while slowly moving from Agile to Lean as I was getting to understand the key role of problems in continuous improvement. It also somehow is a more detailed follow-up of a previous article on Agile and Lean.
Many thanks to Regis Medina for introducing me to Ben Linders, to the latter for his great editing work and to Ana-Maria Ciobotaru for making it look neat and professional.
#hypertextual 