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?.
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 firstname.lastname@example.org, 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.
Third, we must SUBORDINATE everything else to the constraint. In this case we decided to stop development for one iteration. In lean manufacturing terms the development has no customer pulling features. So instead the development team will carry out some maintenance work: refactoring the codebase (tidying gemba), improving test coverage, installing new tools etc. (As things turned out, analysis generated some high-value stories quite quickly, and so we were able to re-start development on those stories before the end of the current iteration.)
Fourth, we must ELEVATE the constraint. Which means we must look for ways to make the current constraint more productive, or else eliminate it from the production flow. In our example this probably won’t be an issue. As the analysis team settles into being proactively managed it looks to be capable of creating stories faster than they can be developed.
Which leads us to the final step: we must PREVENT INERTIA and re-start the process with step one. Now that analysis is creating a story pile and development is working on it, we need to IDENTIFY the system’s constraint all over again. This time it will be somewhere different, and again we’ll find it by looking where things seem to be piling up…
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:
Your team holds a daily scrum or stand-up meeting. But for some reason you all decant to some other room for the meeting itself. Maybe you don’t want to disturb the other teams who share your bull-pen. Or maybe you’re used to meetings being in the Boardroom, so you just head off there out of habit. Or maybe someone once told you that a change of scene helps meetings to focus. Whatever the reason, don’t do it!
The daily stand-up should be about the tasks on the board. If the board isn’t in the room with you, the meeting will lose its structure. Sure, everyone will still take their turn in describing what they did yesterday and plan to do today. But without the task board there are no visuals for the listeners, no cues for the speaker and no controls for the coach or tracker. No-one can point to the tasks, so it becomes much harder to discuss tasks, disconnects, blockages etc. It is also now impossible to re-plan during the meeting. Finally, your task board should also be the place where you display your big visible charts. If you hold your daily stand-up somewhere far away, you can’t discuss them. No tactical analysis or retrospectives. No daily update to maintain momentum. Huge loss of communication. Huge loss of focus.