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.
Very fair point, David. I’ll throw out a couple hypothetical reasons: (1) an investor suggested it to the CMO at the charity golf tournament Saturday and it became Marketing’s Priority Uno the following Monday to prove how nimble the company is. (2) the company signed a deal with the McGuyver people 4 weeks ago. The CFO pursuaded Marketing yesterday that leveraging the deal’s seven-figure annual rev share ASAP had a higher priority than unveiling their planned new homepage redesign. In both examples, the problem is a combination of attention deficit disorder and HIPPO management (Avinash Kaushik’s brilliant term for Highest Paid Person’s Opinion), but realistically, how many companies are so process-disciplined that this never happens? I agree with you that these situations are problems that are really disruptive when they occur – but I am less sure they can always be solved without impacting the software team, particularly when the pressure to switch gears is top-down.
Cathy,
I think you captured it originally: “figure out what’s method is right for the business and set realistic protocols on how change should happen within that method.”
The changes you used as examples are all based on improving revenue, but the HIPPO also needs to told what the cost of change is. That is the method I use when faced with a change to requirements when development has started; this includes the cost of figuring out the cost, because someone is not doing what they planned to be doing when you need to evaluate a change that comes in.
Given the true ROI of a change and deciding it is worth it, the last thing is to get the project plan changed to incorporate the change. If IT won’t change until a fixed date, then your sponsor (with the money) needs to talk to IT management.
(Afterthought: it may be true that the cost of changing the current sprint may in fact overwhelm the benefit of doing so, but that should be the basis of the decision, not “no changes to current sprint” stubbornness.)
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.
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.
Pingback: Tweets that mention A Marketer’s Guide to Agile Development – “Welcome Changing Requirements?” Who Does That?cathycarleton.com | cathycarleton.com -- Topsy.com
Came across your web site via google the other day and absolutely adore it. Keep up this fantastic work.
Pingback: A Marketer’s Guide To Agile Development – There Are No Dumb Questions – Oh, Sure There Are… | cathycarleton.com
Great thread. Enjoyed the posts..