Fighting the tyranny of the Functional Spec

Just when you think you have a problem licked...
We've effectively transitioned 2½ teams to Scrum (the ½ team being Test), casting out the Functional Spec in favor of the Product Backlog, it rears it's head again.

The other day I sat down with our product owner for a chat since she was in town (our product owner works on the other side of the country - don't get me started) and talked about where the product was going, etc. Somewhere along the line she uttered those words that are the bane of any development team, most functional companies, and many dis-functional companies: "We're going to be improving our process."

Oh crap. I thought I was done fighting this battle. Now that we're somewhat functional as a software dev group, someone (undoubtedly one of the PMs who never attends any of our meetings and never comes by to find out how the product development is going) is again pushing for more documentation and more structure. What a god damned waste of time. If you must have a functional spec, make it the last thing you do, after the product is written to the features from the backlog and will match the product, not the first thing you do so that the entire development team is sitting around with their thumbs up their asses while you debate if the OK button should be in the upper left or lower right corner of the screen.

At Agile 2006 I sat in on a talk by Michele Slinger from Rally Software. She had a great quote that went something like (if I may paraphrase)

"
I was a project manager for years, PMI certified, the whole thing. For years I tried to follow the waterfall process, write functional specifications and keep them up to date, follow the cycles, and it never worked. All I could think is What am I doing wrong?
"

She then went on to detail how things improved naturally and dramatically when they started doing agile (Crystal Clear, I believe). But the takeaway is that the SDLC methodology we have been taught for the last 30 years does not work for software and has never worked.

Good News

Great news, in fact, from the other team. At the end of this sprint cycle they'll be feature complete (we're not yet a "pure" scrum shop). That puts them a full three months ahead of schedule, giving the test group a full four months to test.

Never before have they finished with more than a month for QC. Why? Well, the business group approving the features just finished their work three weeks ago. Traditionally, that would mean another month to write a functional spec, then they could start coding. That would place them starting at a point which will be later than completion under the new model. How did they do this? They took a leap of faith and identified all the features with a 80-90% certainty of being approved and began working on them.

The moral of the story is to flush your functional spec and use a backlog for development task management. If you need a functional spec, have someone write it at the end, after development has made what will be in the product.

So if you still work under the tyranny of the Functional Spec, print this short story out, walk into your boss' office, throw it down on his/her desk, and say: YO! It's called parallelism, biyatch! Look it up under computer science.

Common demo mistakes

I was invited to the demo by the parallel team recently. They were quite well organized. Perhaps a little too organized for my tastes (they took a 45 min rehearsal before the demo), but it played quite well. What they did that was nice was to summarize the sprint objectives, in a printout, prior to each segment. We always came up short in that department. What they did that was bad was they demoed features that weren't finished.

So class, does anyone know why we shouldn't do that? Of course you all do, because we've all tried to pull this one off. You spend three weeks busting tail and get just within spitting distance of completion. Close enough so that part of it is showable, even though there's still another week or two of code cleanup before it's ready to go. Not wanting to look like a slouch who got nothing done for the entire cycle in front of the boss, you show it anyway.

So what's the problem? Now that item is crossed off the backlog and won't be taken into account when planning the next sprint. But you know there's at least two more weeks of work hiding in there. What happens? Either you try to overbid your next sprint goals, making up the missing code with your slack, or that feature winds up shipping (or making it to final testing) in an incomplete state. Or a combination of the two. Regardless, it's bad news and these problems build on each other and compound themselves until there's a big, explosive day of reckoning at what should have been the end of the product cycle, kind of like what happens in tradition SDLC development.

Q: So how do we avoid this? A: Every way you can.
This can be easy or hard, depending on your organizational environment.

#1. Developers must show courage and be ready to admit when they mis-judged. We too often fall into the arrogant mentality that we're the smartest people on the earth and somehow our brilliance will overcome all adversity. This leads to misrepresenting the status of a task in the standup in the hopes that we'll be able to overcome and no one will be the wiser.


#2. The scrum master must be truly aware of what is going on with the project. If you as the scrum master have a solid rapport with everyone and complete faith in what everyone tells you, I have a bridge for sale in Brooklyn. I don't mean to distrust, but if one of your devs is failing every sprint cycle, but says things are great every standup, you need to actively work with them and understand what is done and what is left. The buck stops with you, scrum master.

#3. Kill features early, kill features often. If something appears to jeopardize any aspect of the cycle, kill it immediately and rechannel your devs to working at a more methodical pace on fewer features and focus on quality. When you start rushing on anything, quality suffers across the board. Next planning meeting, evaluate why you had to kill it and reduce scope on the suspect features.

Cross team communication

There isn't much. While the scrums have dramatically increased intra-team communication, inter-team communication is almost non-existent. I realized this as I was speaking with to scrum master of the newer, parallel team. We very rarely communication. Early on I was to work closely helping them define their project and smooth out the meetings. But they mostly went off on their own and defined their own project style. Not that it is necessarily a bad thing, but there hasn't been much sharing of knowlege.

I've been lobbying for an "outside expert" for a while and almost have final approval. Hopefully that will seed more communication and joint learning. And maybe push agile deeper into the organization.