This week's book giveaways are in the Refactoring and Agile forums.
We're giving away four copies each of Re-engineering Legacy Software and Docker in Action and have the authors on-line!
See this thread and this one for details.
Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

XP a recipe for creature feep and crope sceep

 
Hedley Finger
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Kai Johnson
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Burk Hufnagel
Ranch Hand
Posts: 814
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Burk
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stan, great explanation.

But - what does AD stand for?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic