silk and spinach

The latest edition of the Carnival is brought to you by Pete Behrens, with a distinctively “management” flavour. And having myself been called an Agile Nazi - and worse - I gained some support from the posts I had missed first time around, particularly Julie Brooks’ Who Coaches the Coach?.

The next Carnival is due in the first week of August; subscribe to this blog or a search feed to be notified of future Carnivals of the Agilists.

Hal Macomber is a lean construction consultant who is currently developing a responsibility-based planning approach for a firm that designs high-tech manufacturing plants. The resulting process will be a hybrid of lean’s Last Planner System with Scrum. And Hal is managing the development of that process using Scrum. He has even hired a ScrumMaster from the world of software development to help with the iterative focus of the project.

I believe this is the kind of application for which Scrum is ideally suited. It brings a clear and simple structure to the process of developing something, and expects the application’s domain to provide the tools and techniques that will deliver value each iteration.

I’ll be watching with interest as Hal’s experiment unfolds.

John Brothers has posted the latest carnival, which is somewhat brief because I fiddled with our publishing schedule this week. I found the linked article by SM Kripanidhi particularly thought-provoking; while I like the simplicity of the Scrum concepts, I too am disappointed by the overt commercialisation in and around the Scrum Alliance. I can understand the industry’s appetite for certification - and indeed the whole cookie-cutter approach to new ideas. But it seems to me that that kind of shrink-wrapped and commoditised packaging is the antithesis of agility. I don’t mind anyone getting rich from a good idea, but surely agility will mean something entirely different in each organisation that truly seeks it?

February seems to have been a quiet month for agile bloggers everywhere! Nevertheless, this issue of the carnival consists entirely of agile-related Britblogs. Here are the seven posts that gave me the most to think about during the last month:

In When is Scrum not Scrum? Tobias Mayer challenges some of the orthodoxy of Scrum and recommends alternative practices (all of which have worked for me too); full marks from me for reminding us all that agile methods themselves need to be agile in a changing world.

Dan North has sketched a great idea to automate some aspects of exploratory testing: RMonkey will use keywords such as ‘usually’, ’sometimes’ and ‘rarely’ to introduce an element of randomness into the behaviour of a test script. Contact Dan if you can help out with RMonkey’s development.

Have you read Simon Baker’s Agile Zealot’s Handbook? No? “Then you have compromised your agility!” The ‘handbook’ is a clear and forthright re-working of the (ideas behind the) agile manifesto, and now I’ve seen it I’ll be using it as my preferred rolled-up newspaper. And for the historians, Pragmatic Dave Thomas has unearthed some of the notes he made at Snowbird during the 2001 “summit” meeting.

Are there any obvious signs that the company you work for is never going to be agile in a million years? Rachel Davies has started a list of anti-agile patterns. It would be hilarious if it didn’t give me nightmare flashbacks…

Are you sitting comfortably? Good, because Jason Gorman wants to tell you a story about the villagers of Goaltown and Metricsville, who conspicuously failed to do the simplest thing that could possibly work.

Okay, now that you’ve been sitting down for a while - take the ARSE test. Mark Levison riffs briefly on the “No Asshole Rule”, and at greater length on the agile-sounding Rules of Engagement at SuccessFactors.

And finally, the other Thomas Otter passes on ‘the quote of the year so far’:

“software estimation is a bit like growing ear hair” — JP Rangaswami

At my time of life this is becoming an important consideration. (I wonder if my barber will shave my project estimates too…?)

Thanks to everyone who sent in suggestions for this edition of the carnival - please keep ‘em coming. If you have something that you think is worth sharing - especially from a blog we haven’t featured before, send us a link by emailing agilists.carnival@gmail.com, or use the carnival submission form. All previous editions of the Carnival are referenced at the Agile Alliance website.

This week’s April meeting of the AgileNorth group was a book review. Kevin Dockerill reviewed Mary Poppendieck’s Lean Software Development and Ken Schwaber’s Agile Software Development with Scrum. We spent about forty-five minutes discussing each book, and then half and hour or so comparing the two methods, particularly in relation to applying them in Kevin’s own small team.

While reading the books in preparation for the meeting, Kevin had created a little summary leaflet for each. Each leaflet was in two parts: the first stepped through the book’s chapters picking out the main points, while the second provided Kevin’s commentary and opinion. (In the case of the Scrum book, Kevin also rated each chapter out of 10 - from which we discovered that the first half was much more to his taste than the second!) The format of Kevin’s little leaflets worked extremely well, and I would recommend this kind of approach for any subsequent book review. I particularly liked the idea of chapter ratings, which gave us an at-a-glance view of Kevin’s opinion and also highlighted the two very different halves of the Scrum book.

As the meeting progressed, the discussion moved away from the books and on to comparing and contrasting the two methods - Scrum vs. lean. I was too engaged for taking notes, but I recall some main themes emerging in the opinion of the group as a whole:

• Scrum is likely to serve well in a traditional, structured, command-and-control organisation, where strong project management and reporting lines reign. Whereas the Lean book offers a bag of tools, and so will probably appeal to more ‘fluid’ organisations.
• The mapping of software development to manufacturing is not helpful to organisations that aren’t used to growing their own processes and adapting them regularly.
• The Lean book maps specific practices from lean manufacturing into software development, without providing enough background on why those practices are appropriate.
• It seems unlikely that many software projects could go 30 days without changing their requirements; so Scrum seems to be targeted at bigger projects.

This was an enjoyable evening, made very productive by Kevin’s thorough and thoughful preparation. I’m looking forward to the next one, on May 15th!

What were your first impressions when you read these two books?

Today I became a Certified Scrum Master! The two-day course was taught by Himself, Ken Schwaber, and Ian Shimmings of Conchango - and I thoroughly recommend it. I should have done it a long time ago. Woof!

In the product owner must pull I described what can happen when there are not enough stories in the pile. Here I want to look at the same problem from a slightly different angle: in terms of the Theory of Constraints.

The development team’s throughput is low. TOC says that the organisation must therefore include a Constraint (a bottleneck). The Constraint is the major factor in causing that poor productivity, and our first step is to IDENTIFY it. In software development, one of the easiest ways to find bottlenecks is to look for stuff piling up. In this case we find that the constraint lies outside the team, in the person/process/team that creates the story pile. There are piles of visions, wishes and capabilities waiting to be analysed, but downstream there’s no work for the developers to do. The constraint is the analysis function.

Our second step must be to EXPLOIT the constraint - to get it functioning on full power. In iterative backlog management I adopted Scrum to help the analysts generate stories and incrementally build a pile of stories for the developers to work on.
Read the rest of this entry »

Mike Cohn’s description of a task board is the clearest I’ve seen. And it fits well with my preferred ways of working.

When the Product Owner doesn’t have enough stories to drive development, try running an incremental analysis project that keeps one iteration ahead of the developers. The deliverable from each analysis iteration is a modified Product Backlog, ready for the upcoming development iteration’s planning meeting.

Whatever the reasons, it’s sometimes a fact that the Product Owner just doesn’t have the backlog prepared in time for the next development iteration. This can have a destructive effect on the development team’s morale and productivity, and must not be allowed to continue for too long. So something we’re trying on a current project of mine is to set up a parallel “analysis” project, to be run using the Scrum process. (This is certainly not a new idea; for example, Martin Fowler talks about this technique in Planning and Running an XP Iteration.)

I expect the mechanics of the two projects to work something like this:
Read the rest of this entry »

Bad things can happen to a project if the Product Owner doesn’t manage the story pile. And consequently bad things can happen to the software development team that is cast adrift in the doldrums.

There are many reasons why a software development team might lose productivity. One that is often overlooked - especially in discussions of extreme programming - is when the Product Owner fails to drive product from the team. Maybe the market research hasn’t been completed. Or maybe the project stakeholders can’t agree. Maybe there is no clear vision. Or maybe this is a research project with a “let’s see what turns out” approach. Whatever the cause, the effect is a Backlog with too few stories in it. Or worse, a Backlog with conflicting stories, and stakeholders who bicker at the iteration review meeting.
Read the rest of this entry »