The project I am in right now is a fixed bid xp project. Now I am sure this might raise few eyebrows but that's how it is in most of the enterprise environment these days. They want to be agile/xp but is not ready to change the way they write contracts with their vendors. There are few better alternatives out there but I am not sure whether that's a starting point for an organization to be agile?
So given the suituation our team is in right now, we are all puzzled with one question, how to track change?
This is really hard because I see my customer/product owner changing his mind every hour.
We don't want to stop that because it is adding more value to the product by making it better. The more customer is able to see the evolving product, more it is helping him to make the right choices. That's why upfront planning doesn't work to begin with. But at the same time we don't want to be in a position where we don't get our product done before a big trade show. We are doing the prioritization of the stories but I am not sure whether that's enough. I guess it helps to know that if you make this change than something else will not get done because other two ends of our pyramid is fixed, time and budget. But I am not sure what is the simple solution to this problem? Maybe build trust....
Stuff about software development, agile and testing
Tuesday, April 14, 2009
Labels
- agile (4)
- agile testing (1)
- build tool (1)
- design (1)
- DSL (1)
- duck typing (1)
- eclipse (1)
- ejb3 (1)
- Fluent Interface (1)
- grails groovy (1)
- groovy (1)
- gwt (1)
- hacking (1)
- haskell (1)
- java (1)
- javascript (1)
- jvm (1)
- languages (1)
- mac (1)
- pipes (1)
- programming (1)
- qa (1)
- rant (2)
- ruby (6)
- sas (1)
- scala (3)
- scripting (2)
- software rewrite (1)
- statically typed (1)
- testing (4)
- two phase commit (1)