Keeping iteration plans firm in a fast moving organization

Awhile back I wrote a post called The Cone of Sanity about how priorities can change like crazy leading up to an iteration, but that once the work hits the development team, it should stay pretty firm for the duration of the iteration.

I received a comment that raised a great (and common) question that is worth posting on its own.

The Question

I've found that this can work sometimes, but often the customer (in my case, the marketing department) demands changes now, NOT in the next iteration. This happens a half dozen times every iteration. How would you handle this kind of a demanding customer?

My Response

I agree that this can be a tough one. One of the main points of Agile is to remain flexible, but disciplined. I have worked and consulted at very fast-paced, dynamic companies where developers had 100% planned workloads but spent another x% handling ongoing requests. And while some requests were completely necessary, some were probably less pressing than some of the work already on the plan. Common examples: “But I already bought the ad space to run in 2 days!” or “We need to match a competitor’s offer NOW!” Developers were frazzled, releases were delayed and buggy.

I've found that you have a few options for improving the situation. 

• Shorten your iterations - Consider shortening your iterations, e.g. from 2 weeks to 1 week. Most high priority (but non-critical) items could wait for the next iteration. 
• Require department signoff - For the critical “rush jobs” we’d just take on easy things like misspellings, but anything that would actually impact the schedule had to be signed off by the relevant department director. This led to priority discussions within the departments. In the end, many of these critical issues had their priorities downgraded by their own division directors because they really weren't that pressing and conflicted with higher priority work already in the plan. Sometimes this led to self-selection, since on further reflection, it probably wasn't high priority enough to bother the director.  
• Build in "on-the-fly" time - As we identified how much time was spent on planned work vs. on-the-fly requests, we started building time for these on-the-fly requests into our schedule.

Your thoughts?

My CSM Training Experience

As promised, albeit a few days late, here are some details regarding my certified scrum master training experience. As I mentioned in my last post, I'm not a big fan of certifications proving anything one way or the other, but I am always trying to learn, and it seemed like a good idea to get away from the office for a few days to learn a few new things.

My instructor was Alistair Cockburn, one of the original signatories of the Agile Manifesto. He gets around a fair amount and has plenty of quotes from many others whose names are frequently bandied about in agile discussions. One of the first points that he made during the course was the importance of avoiding dogma, but rather assembling a bag of tricks, and using each only as they make sense for a given customer, team, and projects. Given that this is basically the SmartAgile mantra, I was on board.

Day 1

We covered general topics such as iterative work, close interaction with the customer, 2 people at a whiteboard vs. a document, etc. Most of the exercises served multiple purposes of realizing how things can go wrong, understanding how a best practice can apply, then applying it to experience the benefits. An effective and entertaining teaching method.

Day 2

This day was basically our Scrum boot camp, covering all of the basics of Scrum, such as the scrum meetings, artifacts, and roles. As it happens, Alistair has issues with various Scrum practices such as moving practically straight to coding (unless you employ a trick like "Sprint 0"), which I agree are a bit cuckoo. He often mentioned that some of the things he was teaching were Scrum practices enforced by the Scrum peasants (torches, pitchforks, etc.), but weren't necessarily his recommendations, depending on the circumstances. Again, dogma -- bad, best practices/bag of tricks -- good. He also covered the Agile Manifesto, throwing in some interesting tidbits about some of the discussions that led to the final version.

Day 3

This was my favorite day of the training. The main two activities were a development project exercise (five 10-minute iterations) and a project planning exercise using a "Blitz Planning" approach. One lesson of the day was the importance of breaking down work to quick slices that result in demonstrable progress for the customer. Another lesson was an approach for rapid planning with story cards. These exercises caused me to think in a different way, which is a nice compliment to the instructor and course.

Summary

Alistair pulls from a very assorted grab bag, and during the training discussed various approaches from methods/frameworks such as Crystal (the framework he created), XP, DSDM, Lean, Kanban, RUP, etc. I'm not sure I would pass a test on what exactly Scrum is, but who cares. At the end of the day I had a nice long retrospective on what I should stop doing, what I should keep doing, and I learned about a number of new tricks to take for a spin.

There were a few people in the class who were beginners. My guess is that they left with some good ideas, but that they would fall flat on their faces if they hoped that their shiny new certificates would ensure a successful implementation of Scrum at their places of businesses. Change always requires an experienced, competent champion. A few days of training won't get you there. Then again, another friend who teaches scrum master certification courses told me that he merely teaches to glean the consulting that results, so I'm sure that these beginners, having caught the vision but really not knowing where to start, could engage an experienced agile consultant, and at least they would have a clue of what was coming and could provide helpful assistance to give the effort a fighting chance.

Have any of you attended a scrum master certification training? I'd be interested to hear your stories.

Scrum Master Certification

To my knowledge, I have never earned an official professional certificate, but that will change in a few days. Over the years I've attended a variety of conferences and training sessions, read a fair number of books, googled a variety of professional topics online and followed a few blogs. I suppose I feel like I've already got both the theory and the experience, so do I really need a certificate to prove my abilities? Besides, doesn't it just seem odd that anyone can attend a course, study and pass a test, and suddenly you are bona fide? Plus, for every solid PM with a PMP who I've ever met, there was another compensating for a lack of actual ability with a certification.

Basically, nearly anyone can pay money, study, maybe document some experience, then take and pass a standardized test. At the end of the day, however, there is no way for certifications to ensure competence. I am not belittling the difficulty of obtaining some of these certifications, just questioning correlation to professional ability.

So why did I break down and sign up for a scrum master certification course? The main one was to get away from the day-to-day grind for a few solid days (3 in this case) to hear what others are doing, to take a little inventory, and to hopefully glean some good ideas to add to the bag of tricks.

Additionally, I won't pretend the certification doesn't have anything to do with it. Even if it doesn't prove much of anything, there are prospective customers who get warm fuzzies when they see certifications on our resumes, so it can't hurt with sales and marketing :)

But will it be worth the $1400 tuition? Tomorrow I'll do a little write-up on the first day.