Heather McLean

I’m not ashamed to admit that a recent post from Dave Nicolette reminded me of myself. After spending most of the past year being indoctrinated with Scrum, it is very, very tempting to start trying to apply iterative development to everything. I mean, why not? Iterative development is superior, right?

As with all things, the answer is “not always.” With my current project, the temptation is high. The organization and the project already exhibit several agile/XP qualities:

• Continuous integration.
• 30-day release cycles.
• The project has already been broken down into smaller chunks of deliverable features.
• We do daily status meetings. (Although they are an hour long and much less focused than a daily stand-up.)

As you can see, it has the potential… on “the cusp of greatness,” you might say. It would be tempting to think that we could just overlay Scrum or some other form of iterative development and succeed, and trust me, it is very difficult to resist that urge to evangelize Scrum. However, there are several factors that mean I must take a healthy dose of reality first:

• The organization has no agile history, and I would bet that 99.9% of the managers and developers have never heard of agile development, let alone practiced it.
• The “product owner” currently lacks the discipline/desire to commit to a set of requirements for any length of time. (We would be aborting sprints right and left.)
• Policy prevents us from actually working on anything until it is completely designed and documented. (Of course, the policy is not always followed 100% of the time.)
• The developers are not accustomed to self-managing.

Those are just a few off the top of my head. As you can probably imagine, trying to throw Scrum into the mix here would not work out so well. On top of the above hurdles, it would be a hard sell to management, and I have a feeling any initiative would be quickly abandoned if positive results were not immediate.

Still, that doesn’t mean I’m not going to try at some point. I just have to be subtle and introduce things one step at a time rather than going whole hog from the beginning.

I’m a little behind the times in responding to this (the “blogosphere” moves so fast), but I wanted to address an article that James Shore wrote back in November about the decline and fall of agile.

He talks about how agile is failing us, but I think the real underlying problem is that teams are failing to understand agile. Perhaps that is a failing of agile, but I think it speaks more to how teams and companies choose to implement it. In particular, Mr. Shore makes a good point:

[Scrum] also has a few mechanical things about a monthly Sprint and daily Scrum. Trivial stuff compared to the rest. But guess which part people adopt? That’s right–Sprints and Scrums. Rapid cycles, but none of the good stuff that makes rapid cycles sustainable.

I see this every day in my own organization. Project management gets so hung up on sprints and burndown charts that the team focuses too much on trying to deliver rapidly, avoiding quality practices like pair programming, TDD, and others.

It is not a lost cause, though. For Scrum to succeed, you need to think about your projects from the bottom up rather than the top down. Top-down thinking is a result of project management trying to hold onto waterfall practices while paying lip service to agile practices. The sad part of this is that typically in these kinds of environments, the team consistently points out these problems in their sprint retrospectives, and yet has no or little power to do anything about it.

Project management has to buy into Scrum and embrace the hands-off part of the practice. Determine the product backlog and the release cycle, but leave everything else up to the team. In return, the team should focus on delivering quality over quantity, i.e. following best practices rather than “get ‘er done.” If quantity is becoming an issue (missed commitments, etc.), then the team needs to stop committing to too much and focus on ramping up, or the product owner needs to stop forcing the team to commit to the pace the product owner wants rather than what the team can deliver.

As a closer, I wanted to share a response to the article that one of my colleagues sent me:

An interesting article. Here is an odd thought that won’t seem related, but I think it is.

Over the course of the past week, whenever I had a little “down time” (i.e., while people were sleeping), I re-read Malcolm Gladwell’s book Blink: The Act of Thinking Without Thinking. In one of the chapters, Gladwell talks about Agile, he just doesn’t call it that. He speaks of the commonality between highly successful combat commanders, on-floor commodities traders, ER personnel, firefighters, Improv comedians, and basketball players. Every one of these domains has this thing in common: they are agile. Here are the two primary keys that Gladwell asserts contributes to their success. First, in each domain, there is agreement with the circumstances. As in systems/software development, when we are using Agile, we take things as they are – we don’t try to tell the customer what they want, we try to find out what they want. Second, in each domain, once the action starts, the players do not maintain rigid adherence to a scripted outcome (how “waterfall” is that?); instead, they respond in each moment, according to a very disciplined set of fundamentals. Players in each domain spend their “off-court” time practicing those fundamentals, honing their skills, sharpening their tools, so that when the moment to perform arrives, they are prepared to perform at their very best.

We could learn a lot from people in these different domains As Gladwell asserts, they are our soul-mates. Agile will never decline or fall. It is an adaptive way of life for any domain where rigidity leads to inevitable failure.

And my response:

An excellent observation… it is similar to one of my favorite metaphors for agile (from Ken Schwaber): driving a car. It’s something we do every day without realizing it, but it embodies agile: adapting to change. As you drive, you continually assess the state of the road around you, making adjustments as necessary… most of the time minor, but if you hit a major “block,” you might change your route completely.

When you realize how much “agile” there is in the world around us and in your everyday life, you really start to see the counter-intuitiveness of waterfall.

I just registered to head to Agile Development Practices 2008 in Orlando, Florida. I will be there for two tutorial and two conference days, November 10 – 13. I won’t be making the APLN summit due to a conflict on the 14th. I will be posting about the conference ongoing while I’m there.

Here’s what my schedule’s looking like.

Monday, November 10

8:30 -12:00, 1:00 – 4:00: The Zen of Agile Management with David Anderson

Tuesday, November 11

8:30 – 12:00: Leading Successful Projects in Changing Environments with Pollyanna Pixton
1:00 – 4:00: Practical Agile: Real World Practices with Jared Richardson

Wednesday, November 12

8:30 – 8:45: Opening Remarks with Lee Copeland
8:45 – 9:45: Seven Years Later: What the Agile Manifesto Left Out with Brian Marick
10:00 – 11:30: Are We There Yet? Defining “Done” with Mitch Lacey
12:45 – 2:15: Pragmatic Agility with Andy Hunt
2:45 – 4:15: Beyond Best Practices: Keeping Agile Agile with Dan North

Thursday, November 13

8:30 – 8:45: Opening Remarks with Lee Copeland
8:45 – 9:45: Collaborative Leadership: A Secret to Agile Success with Pollyanna Pixton
10:00 – 11:30: When to Step Up, When to Step Back: How to Lead Collaboration with Pollyanna Pixton
12:45 – 2:15: Maximizing Team Dynamics and Overcoming Dysfunction in Agile Environments with Michael Mah
2:45 – 4:15: Scaling Agile Up and Out: A Tale from the Trenches with Ade Miller

Of course, this is just all the scheduled activities. In between there’s plenty of time for networking, discussion, and food. :)