Reading the Scrum Development mailing list is always a good for some inspiration. Today there was some discussion on how to split user stories. These are meant to be sent out to prime mail boxes of registered memebers. Although paper mail has begun phasing out, we would like to keep it going. Next to some good examples in the mailthread, Charles Bradley also provided a link to Patterns for Splitting User Stories by Richard Lawrence.

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.

Scott Ambler is in the habit of doing some very interesting surveys. One that caught my attention this morning was on Enterprise Architecture. The interesting part is the tables on success and failure factors. The highest rated success factors are about involvement and communication with both business, management and the development teams. The highest rated ‘reasons for cancelling enterprise architecture programs’ are getting insufficient time, not being able to prove any benefit, and rejection of the EA work (and sometimes the EA) by the development team.

In Agility, Or A Pig On Roller Skates? Ken Schwaber comments on the role of product management / ’the customer’ in Agile projects: The backlog is the result of actual work managing a product, and should be used to increase agility (ie. flexibility in getting higher value items out first), not just to adapt to a different development process. Usually, the introduction of Scrum is initiated by the development organisation. Whether it is completely bottom-up, initiated by the developers to get more grip on their process, or more top-down by development managers interested in increasing productivity and work satisfaction, the initiative is mostly from development.

I’ve just finished watching a Google Tech Talk by Ken Schwaber: Scrum et al, through the ‘running agile blog. This was the first time I’ve seen Schwaber talk, though I’ve been reading his blog. It was a good talk, with plenty of humour, and some very recognisable stories. Some highlights (paraphrased from memory, I’m lazy): “In Scrum there’s this role called the ‘ScrumMaster’. Otherwise often known as ’the prick’. This is the guy who needs to ensure that the team does not compromise on quality.

I’ve been reading up on Test Driven Development, starting out with Kent Beck’s book, then finding his screencasts, first the teasers at vimeo, and later the official release through the pragmatic programmers. There’s also a nice free example available on vimeo from Bret Schuchert of ObjectMentor, of which I watched the ‘Getting started with TDD in Java using Eclipse’ one. The nicest introduction on TDD, and on why you should use TDD, and how it helps you create better designs, emerging from the test driven approach, has been Neal Ford’s articles on IBM’s DeveloperWorks: Evolutionary architecture and emergent design: Test-driven design, parts 1 and 2.

Ron Jeffries has a nice new article on whether agile implies effectiveness, and vice versa. The way he describes this is that an agile approach gives more opportinity for effectiveness, but if you can’t follow the agile approach you can use non-agile measures to still reach a certain point of effectiveness. I think this resonates with some other things I’ve been reading and thinking about. The road to creating a full working agile implementation can take quite a few turns before ending up with the type of completely self-organising team that we’re aiming for.