I usually answer by telling that the requirements need to be clearly defined before the project starts, and if there is any change during the project then it has to go through a change control process which involves the change control board, etc etc
Your interviewers are right — this isn't agile.
The point of agile is that requirements change. Your understanding of the problem changes. Your understanding of the market changes. The thing you thought you needed to build in January is not the thing you know you need to build in June.
If you insist on defining your requirements up front, one of two things will happen:
- you’ll build to spec, and find you’ve built the wrong thing
- you’ll ignore the requirements, making the requirements-definition process wasted effort and the requirements themselves a dead document
(There are certain exceptions, involving extraordinarily well-understood engineering problems, extraordinary constraints, and extraordinary budgets. If they're asking you these questions you're almost certainly not on one of those projects.)
Now: scope creep. To a first approximation, there’s no such thing as scope creep in a smooth-running agile process. There's new scope — new priorities and new requirements, which lead to new work — but there’s no creep.
The first problem with scope creep in a traditional process is when the organization lies to itself. You’ve promised to deliver features F by time T at a certain quality level Q. (Q probably wasn't ever made explicit, and you probably were never going to make T anyway, but never mind.) But now you’ve silently redefined F to mean F+1, F+2, all the way up to who knows, 2F, 3F worth of effort, without ever explicitly making the tradeoffs to T or Q. So T is going to slip, and Q is going to slip, but no one’s admitting that no one outside the development organization even knows it’s happening, so somewhere after crunch time when you finally admit it to yourselves and finally give your stakeholders the bad news, they’re going to (justifiably) flip their lids.
This is the problem your change control board, etc., are designed to prevent—that cycle of denial and flip-out.
But, even with a change control process that keeps the organization honest, you have another problem. You set out to deliver F by T, and now you’ve increased the scope and pushed out the timeline and you’re on track to deliver 3F by 3T. From the point of view of the development team, everything’s fine.
The larger organization, however, is in deep trouble, because you haven’t shipped any software. You’re losing sales (or mindshare, on an open source project) to your more agile competitors who have, even if they’ve only shipped F/2 worth of features. You’re missing out on the opportunity to get feedback from users, so your assumptions about what features your users want aren’t being marked to reality, and if you do finally ship 3F you’re likely to find out it isn’t what they want; you’ve wasted 1F–2F worth of effort and you have another 2F–3F ahead of you just to catch up.
This is why the Agile Manifesto says Working software is the primary measure of progress. Fundamentally, agile development is pretty simple:
- you build a small thing
- you ship it
- you build the next small thing
The details are all about figuring out what the next small thing should be, and making sure that it’s built to an acceptable level of quality.
Where agile breaks down, it is often in the form of scope creep. That small thing becomes bigger, and the time it takes to ship it gets longer, and then it gets bigger still, and the next thing you know you haven’t shipped anything for three months and even if you’re still having daily standups (or scrums) and breaking work into iterations (or sprints) you can’t honestly call yourself agile any more.
Different agile practices defend against this problem in different ways.
Test-first design, test-driven development, continuous integration, and continuous delivery, when properly applied, ensure the software is always ready to ship.
High-level planning poker and low-level task estimation encourage developers to think features through and make sure they and the product owner have a common understanding before they start development.
Iterative development (allowing new tasks to enter the work stream only at iteration boundaries) limits the rate of scope change, incentivizes product owners to think through features before asking developers to deliver them, and minimizes developer thrash — the cognitive whiplash and context-switching overhead of being pulled out of your flow to drop one task and start another. Velocity tracking and evidence-based scheduling keep your iterations realistic.
Lean / kanban–type processes do away with iterations but “pull” features from the backlog only when developers are ready to work on them — which is to say, after their previous feature has moved on to QA and/or has shipped.
The real way to answer your interviewers is to turn the question around on them. When they say “scope creep”, what are they really worried about? Are they worried the product won’t ship on time? Are they worried quality will suffer? Are they worried about developer burnout? Are they worried about all of the above, and also that they won’t find out till it’s too late? These are related but different concerns, and a good process will address all of them in related but separate ways.
In the lean world, they say that if you want to find the root cause of a problem, you should always ask “why” five times. Ask your interviewers why they care about scope creep, and you’ll find your answer.