How do you keep a rein on new requirements and features being introduced at every iteration that blows the budget out of the water? I have seen client and developers almost at blows as late requirements cause large amounts of code to be refactored to the point of bug explosion.
As far as I can tell, a bug explosion only can happen if you don't have extensive suites of automated customer driven Acceptance Tests *and* developer driven Unit Tests. Which, to put it bluntly, means that they were definitely *not* doing XP.
With other words, automated tests are one enabler for Agility.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
While it's possible to have feature creep for changing requirements, I don't think XP leads to it naturally. In choosing what to do next, you can adopt a policy of choosing the most important features. And then you don't end up refactoring lots of code for necessary changes, but instead you can consider whether it's worth it for the nice-to-have features.
Originally posted by Hedley Finger: How do you keep a rein on new requirements and features being introduced at every iteration that blows the budget out of the water?
That's two different questions. As I understand it, the idea of XP is to expect and embrace change because the customer's needs will evolve over the course of the project. If you don't allow the requirements to change then you won't deliver the features the customer wants.
The trick is that when requirements change, so does the schedule and budget. They customer may not like it. That's fine. Let them decide whether they want the changes, or they want the original deadlines. It's also possible for them to let some other features slide to a later revision.
SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
Scrum gives responsibility for defining and achieving project success to the customer. Does that sound odd?
The AD team delivers at some velocity - points per iteration - which nobody can really change much. Scope / velocity = time is a pretty simple bit of math. Once the customer truly accepts that he can't have the impossible - more features in less time - he must adjust scope and date to satisfy his business needs. Those are absolutely business decisions. Why would he want to give up that responsibility?
Scope creep affects the date? Who's problem is that? Why would AD care? If AD wants to be successful and look good, define success as reliable velocity and quality no matter what they are asked to do. The customer will learn to manage scope creep when it hurts his success, not AD.
That's a pretty challenging point of view. I can't imagine many folks at my company buying into it. [ October 30, 2007: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jul 11, 2001
Stan, great explanation.
But - what does AD stand for?
Joined: Jan 29, 2003
AD is Application Development (in our shop) to distinguish US from THEM in the business. That's not quite "whole team" thinking, is it?
I was trying to boil an hour long Ken Schwaber video from InfoQ into a paragraph there. Glad it made sense in the end.