If you’re a fan here, or if you’ve had more concrete experiences of working on Agile software teams, you probably have a good sense of how well the Agile values and practices can really work.
Problem: Not everybody sees that. Especially (perhaps) your boss or project sponsor.
So I threw this question out on LinkedIn earlier this year:
How much Agile have you been able to get away with? How?
One response in particular stood out for me. Lou Storiale wrote:
Sometimes Scrum can be implemented without anyone knowing it…. At first, I asked my staff (2 others) if they could meet 3 times per week for 15 minutes or so? They of course said yes. So we began meeting, I didn’t keep a specific regimented routine of “what did you do, what can you do, what is getting in your way,” I asked what’s on your plate for today, how much do you think you can do by “Friday” – anything going on (meetings) that might keep you from doing that?
That’s not a true Scrum, but it embraces the essentials of the standup meeting concept. The boss came along quite a bit later, says Lou, and asked what was going on. Lou (the project manager at the time) admitted he was doing what I call “Stealth Scrum.” The boss–not a big innovator or early adopter type–rolled her eyes and said, “Uh, okay.” And that was it.
Lou said. “That is what matters.”
This sort of thing, the bottom-up movement towards adopting happier development practices, happens all the time.
After my presentation on “Why Your Software Project Sucks (and how to make it not suck)” at NOTACON7 a couple of months ago, several participants hung around to ask more questions. One of them was really interested in Test-Driven Development, but he was looking at a million-line “big ball of mud” legacy system to start with. I pointed him at Working Effectively With Legacy Code, a book I blogged about in the past. At last report he’s awaiting shipment on the book. Rah!
Along those lines, one of the nice things about test-driven development is that you can sometimes (not always) just start doing it without permission from anyone. In a .NET environment, it means you have to download (for free!) NUnit and add a reference to your Visual Studio project. (Everyone who maintains the same project will have to do the same in order for their builds to work.)
Back to Why Stealth Scrum Works
Stealth Scrum works because, like many of the most effective Agile practices, it’s just a slight formalization of the things smart people are already doing to be as effective as possible. Whatever your formal methodology, or even if you don’t have a methodology at all, you probably check in periodically to find out what everyone is working on and whether they have any obstacles. If you don’t, why not?
Stealth TDD works because smart developers do unit testing anyway. The only difference is when you write the tests.
Stealth Pair Programming works because the best developers review each other’s code anyway. The only difference is that a pair does code review constantly, not just once a day or at week’s end.
What’s in a name?
Just as there are many shops that call themselves “Agile” but insist on top-down control of everything, there are shops that would never call themselves “Agile” but are actually doing a decent job of implementing the principles of maximizing the amount of work not done, adjusting and tuning, and making frequent iterations.
So if management won’t let you do Agile, don’t fight it. Just say “We’re gonna hang out and code in the same cube for a couple of hours.” Or say, “I’ve got this code written that will test our new features before the integration steps.” You might even get to deliver working code every couple of weeks as long as you don’t say the word “sprint.”
The Agile Principles are important. What you call your technique is not.
Have you tried Stealth Agile? How well has it worked for you? What are your suggestions?