- concepted
- implemented
- documented
- communicated
Here is how it usually goes down:
You have a huge application, with tons of interrelated features. And/but the customer/product manager has yet a new idea about a relatively small enhancement that would make the customers' lives much easier. (You know it's small because you hear phrases like "It shouldn't take more than a day", "It's just an extra checkbox that we can even hide optionally". ) It gets specked out. It turns out that it's not that simple because many surrounding feature, that seemed unrelated at first, are interfering. The effort start to seem more like 10 days now. This is an important moment because you have to make a choice:
- Option A: you go ahead and do it anyway
- Option B: you build lots of limitations around the new feature as to protect it from all the interference that would screw up the initial estimation
The problem with Option A is obvious: you mess up the original equation of cost < return. So you are left with Option B, and now you are in real trouble, because you didn't even notice, you just got into trouble.
The trouble is that a half-baked, poorly concepted feature is very hard to communicate. The harder it is to communicate, the more questions and complaints you get, typically placing you at the beginning of the loop: "And/but the customer/product manager has yet a new idea about..." And to make everything worse you just added yet another feature to your system, that will once again increase the interference with the next new thing.
You do this loop enough times and even the really small enhancements will take ages to implement. I wouldn't be in your shoes, man.
Is there a Option C? Think about what that could be? In the next post I want to talk about my Option C.
Read full post...