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. Not that I never read anything like that, but those were never books that really influenced how I do my job. Looking at this list it seems that I’m not very imaginative, since most of these are very well known classics. Still:

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. I’m not sure whether that’s quite fair, since tracking ROI is only rarely actually done in Scrum projects, but the responsibility is explicitly there.

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. They had an idea, followed up on it, saw a possibility of creating a product out of it, experimented, poured resources into it, tried it out in the wild, publicly supported it… And when the time came, they admitted it wasn’t working out as hoped for, and in a timely manner pulled the plug. Writing the whole thing off as something that generated some useful technology, and hopefully some valuable insight in end-user wishes.

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: