Yeah….maybe “welcome” is a strong word. Then what’s the right word? Tolerate? Humor? Laugh and point? If welcoming changing requirements, even late in development, is a key tenet of the Agile Manifesto, why does the marketing team feel about as welcome as Keith Olbermann at a Tea Party rally when they try to get changes done?
Here’s the thing. Say you’ve got a six-week release schedule. The backlog priority meeting was three weeks ago, and Release 5 is scheduled 3 weeks from now. You’re getting mucho static when you try to convince the development team that your new McGuyver Social Media functionality absolutely has to be part of Release 5. You say there’s three more weeks – plenty of time to squeeze the change into the schedule. They say they’ll get it into a future release. “So much for welcoming changing requirements!” you say.
But here’s their view. They’ve got to get Release 5 out, and the deadline for completed code is next Friday. And another tenet of Agile is to “deliver working software frequently”. So they keep working toward the sprint instead of implementing your change so they can make the delivery. That’s what their boss is grading them on. If your enhancement is important enough, it will get into the next sprint, right? So they’re not saying “no”, they’re just saying “yes, but later’. Right?
No. This ain’t your first time in the rodeo. You know that “we’ll include it in a future release” is the IT equivalent of “the check’s in the mail”, “I’ll fight for you in Washington” or “Facebook values your privacy”. You know that once the original version is coded, there will be zero interest in plucking the enhancement out of Backlog Purgatory. “Iron Man VII – Recycle or Die” will be in theatres before you see it implemented.
The problem isn’t one of process but of trust. Both Marketing and IT need to trust the standard of requirements and appropriate use of backlog.
Requirements are a funny thing in Agile. Some requirements, even in an Agile environment, still go “thump” when printed. Extreme Programming proponents say that a requirement should fit on an index card. Others have questioned the very nature and necessity of requirements. Consider this quote from Scott W. Ambler: “Is something really a requirement if it evolves over time? Is something really a requirement if it gets deprioritized and as a result never gets implemented? Is something really a requirement if it gets reorganized into smaller pieces and then only a subset of the pieces is implemented?”
Marketing and IT have to align their expectations. Whether requirements in your shop can fit into a single tweet, or they’re wav files in a database, or they’re printed, bound and given a Library of Congress number, figure out what’s method is right for the business and set realistic protocols on how change should happen within that method. If you don’t, this conflict will happen in every sprint. As for the backlog, its effect on the perception of requirements change will depend on its reputation. When a requirement goes there, is it considered bound for the bullpen or the showers? Fix the way the backlog is perceived and you’ll fix a lot of this conflict between marketers and developers.
Really decent post… I love it. Keep ’em coming… 🙂
Hi, Cathy – loving your blog entries about agile! Humor, accuracy and sharp darts make it all good.
Totally agreeing so far… keep it up.
About “Requirements” … I’ve given up looking for a noun word for the topic, these days I try to use the verb form: “Deciding what to build”.
Saying “We’re deciding what to build”, you get the need for collaboration, changing priorities, etc. The dusty basement files you refer to are only filled with old conversations, not pending requirements. The thing is (as you write) for both groups to work together to decide What To Build – Now – for the pending crisis, and What To Build – Now – to keep the investment in the future alive.
all the best,
Alistair
Good points within the context you described, but let’s change the context with this question: why did you not know three weeks ago that the “McGuyver Social Media functionality” was needed in a release due in only 6 weeks? That is the real problem, and can be solved without impacting the the software team.
p.s. I forgot, to your opening question… “Tolerate” is what it is for me. “Welcome changing requirements, even late in the project” still makes my blood run cold. Couldn’t manage to get that softened in the 12 principles. shudder.
My view is that the world will rain enough changes on the team without them asking for extra.
anyway,
Alistair
Keep up the good work, I like your writing.
Hi Eric, Sounds like that was a very interesting diuscssion. One comment: Scrum isn’t iterative waterfall because it doesn’t prescribe any particular way for the team to work within each sprint; that is left up to the team to decide. Some teams run their sprints like little waterfalls, but there’s nothing in Scrum that requires it.
Forgot to say, “aahhh…. Mr. Ambler.”
Let it be known that all requirements are NOT created equal. You don’t derive requirements from your goals, you derive them from your process or product, and then see which of them support your goals and which don’t, that’s priority setting. … but to get one of your important requirements met, you may need to include some of the less important ones, logical build sequence and all that..
I remember at at a past job, my CEO at the time being presented to about a new system being delivered, and some one asked him (lord knows why) what part of the system did he think should be delivered first, and he answered quite sincerely, “the reports”. I don’t know who ever told him that you the need the system that creates the data first before you can do reports; I just know it wasn’t me.
Came across your web site via google the other day and absolutely adore it. Keep up this fantastic work.