Mary Poppendieck: What’s this thing called “Pull”; Mary Poppendieck had the second talk of the first day of the conference. She talked about “The power of pull”;. She started the presentation with a story on her introduction to pull at the video tape factory where she worked when video tape was still current. I didn’t make too many notes here, since this story is very well documented in her books (which I can thoroughly recommend: Implementing Lean Software Development and Leading Lean Software Development).

I attended the Lean and Kanban Europe conference last week, and I thought I’d do a little write-up to share my impressions. As an Agile Coach and Scrum Master, I was going to this conference to find what parts of Lean and Kanban (in that order) could be of use for me when helping clients improve their way of working. I was in particularly interested in ways of extending the values and principles of Agile into the non-IT parts of an organisation.

When discussing books on software engineering with colleagues, I got the idea of listing the best books I’ve read in the past 15 years. Because it seems useful, but also because that will allow others to tell me which ones I should have read… Let’s start with some technical books. I’ve never had much taste for books on too specific technology subjects, so there’s no ‘J2EE Internals’, or ‘Jini Programming for Dummies’ books here.

Peter Stevens has a nice write-up on the differences in responsibilities between Scum projects, and traditional project. As can be expected, responsibilities are distributed broader in an Agile team, with much (or all) of the responsibilities of a project manager being spread over the Product Owner, Scrum Master and the development team. Especially interesting is that they found some responsibilities not being clearly defined in a traditional team (ROI, process improvement), while it was there in Scrum.

The retirement of Google Wave is pretty big news. There’s a lot of discussion on how Google failed. Failed because they misjudged the acceptance, failed because they overhyped, and failed because they waited too long before finding out whether users would actually like it. And all those things did happen, and some of them were probably mistakes. But the main thing that I get out of this, to be honest, is quite a bit of respect for Google in how they handled this.

Pete Deemer has written an article on InfoQ, Manager 2.0: The Role of the Manager in Scrum which disucusses the role of the manager in an Agile organisation. The situation sketches that he gives are all too familiar, and anyone working on a transition to Scrum (or any other Agile practice) would be well advised to read this article. The quote that rang the most bells for me was: “If there exists a fundamental belief in the effectiveness of the “command and control” approach within the management and executive ranks, and a heavy dependence on intimidation, threats, or punishment (such as shaming or humiliation) as a management tool, it is going to be particularly difficult to make the transition to a new way of thinking.