• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

XP a recipe for creature feep and crope sceep

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 883
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stan, great explanation.

But - what does AD stand for?
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic