I hope I don’t end up with a seized engine on the side of the road, but if I do, I’ll know I should have had that oil change. I hope I don’t end up on the Worst Dressed List, but if I do, at least I’ll know I should have given away those old shirts. I feel sorry for those on the “Worst Agile Implementation” list who don’t even know they’re there.
In the past few months I’ve had the privilege of talking to approximately fifty organizations about their Agile implementation. Most of them are doing well, and many of them have great insights about how they customized Agile to fit their process requirements. But some of them really Say the Darndest Things.
“We do Scrum, it’s just the rest of the company doesn’t.”
“So first we break the requirements specification into pieces and call each of the pieces a story. Then we do our iterations and pass them off to the release team. We’d sure like to get Product Management, QA, and the customer involved, but they don’t want to.”
There are a lot of places an Agile approach can add value, and I’d hate to adopt a “waterfall approach to going Agile”, but you’re really not doing Scrum. The biggest chunks of value, the incremental use of customer feedback, and going from “completed state” to “completed state” in each iteration are lost if you can’t get more support.
“We’re Agile until the development is done.”
More than once I’ve been speaking with an earnest development leader who’s describing the Scrum process. They’ll launch in, with obvious pride, and tell me how they’ve gone to two week iterations, do standup meetings, and work from a backlog. “Terrific! And how do you do QA?”
Oh, yes, of course they do QA, silly! In fact, they demo the completed development to the QA team every sprint review and send it off to get tested. Sometimes, unfortunately, QA actually finds some bugs that need fixing. So that’s why they put the sprint on hold for a while to fix the bugs and loop them back into QA “’cause we don’t want to wait an entire sprint before they can restart the testing.”
The other side of this one is the guys that take the old “Release Tail” loophole for all it’s worth. “Yes, Lorne, we’ve been agile for three years now. We do Scrum, unit testing, standups, and play in the World Series of ‘Planning Poker’. We do that for about six weeks, or until the release. Then we have a three month release testing tail, which follows a ‘modified Scrum process’ … the project leader estimates the amount of work on each bug QA finds, and assigns it to a developer. Sure, sometimes we have to work on new functionality during the “release testing tail” … you can’t expect the customer to stop needing improvements for three months!”
Folks, I don’t think I’m sharing any great trade secret when I tell you the QA process needs to be completed before the story is considered “done.” I don’t want to be Klaus Fuchs of Scrum, but here’s the secret: you’re going to have to invest more in testing up front.
“We do continuous integration every night.”
I blame the education system: how’s an engineer supposed to know what “Continuous” means when we have “social promotion!” Now some people understand the idea of continuous integration, and made a conscious effort to make it more “Discrete”. Some companies I talked to had broken builds that lasted for a week. You’d rather have a child repeating “Mummy” every 30th of a second before you’d like to get an email every five minutes saying the “Build Failed.” I get it. And if the email was going to your boss too, well, you don’t have to be Dogbert to know that’s a bad idea.
Builds are going to fail. Get used to it. The problem is not that the build failed, but that you couldn’t fix it. Good practices are to have the team drop what they’re doing when the build fails and hop on fixing it. If they can’t fix it, it needs to get escalated *pronto*. Better is to have the team do local builds and unit testing before they check in. Best Practices are to divide up the build process by team and stage of development, so your team only pollutes itself, not the rest of the development org.
“We don’t need training since we can use the internet.”
Uh huh. So I guess the schools will be shutting down any day now. Not that the Internet might not turn out to be a useful aid someday, but the software development process is a hands-on activity. And similar to other hands on activities, like dancing or carpentry, you can’t learn to do it by reading a book. You’re going to need to get some experience with the process before you understand how to run a sprint review or a stand up, how to estimate stories, and how to work with your QA partner.
Now if you’re a hobbyist and working for free, your time is cheap, and there’s no reason not to use trial and error as a learning method. But if you’re getting paid, and your work is important, you really don’t want to waste four sprints figuring out what someone can help you get right in sprint two.
I’m hoping my surgeon, pilot, and barber got a few lessons before it was my turn.
Finally…
No one has to pass a test to call themselves “Agile,” nor should they. Agilistas don’t have a monopoly on the right way to develop software. But when people believe they’ve made it to Agile without using critical Agile concepts like time boxing development or getting to “done”, they’re missing the real value.
Yup. It’s true. The tried and true development approach of Waterfall that we’ve been using for years was an example of what NOT to do for software development.