4 ms·

I would love to hear more about that... Were you working on a single product or multiple products, each with new customers, or something in between? Who is the

by annnnd 13y ago

I would love to hear more about that... Were you working on a single product or multiple products, each with new customers, or something in between? Who is the judge as to whether the target has been hit? Do you lay the rules in advance? That must be a lot of work just to define what needs to be done... When developing a new product the specifications are bound to change during development, how do you tackle that? I am genuinely curious how you approached these difficulties and would love to hear more about it.

marcus_holmes 13y ago
The internal customer was as involved in the development as they need or want to be (usually not much, actually, with a few exceptions), but the target was usually a specific feature or capability requested by an end-user customer, so it was pretty easy to determine when the target was met. There'd be the odd wrangle over what had actually been agreed but it wasn't a major problem. Generally speaking we kept each milestone small, ideally each dev would be hitting 1 or 2 milestones each week, not necessarily on the same project. I measured schedule time in quarter-day blocks and had a weekly 'schedule' that showed who was working on what each week. This meant our smallest schedule block was 2 hours... if it was a 5-min job we either did it for free or charged the customer 2 hours, which really helped reduce the mass of tiny jobs into manageable requests. For new products we iterated a lot and involved the customer in specifying the next steps. There was one project that needed a lot of architecture up front, and that got a bit tricky as we had to spend a lot of time building with nothing to show for it, but usually we were able to do it in small sprints (this was before "Agile" hit our corner of the world!). This is pretty much a solved problem now.
- annnnd 13y ago
  Marcus, thanks for the answer! It sounds like a useful tactic... We are trying to push for a similar system so it is good to know how others cope with it. Thanks again!

by annnnd 13y ago

marcus_holmes 13y ago

The internal customer was as involved in the development as they need or want to be (usually not much, actually, with a few exceptions), but the target was usually a specific feature or capability requested by an end-user customer, so it was pretty easy to determine when the target was met. There'd be the odd wrangle over what had actually been agreed but it wasn't a major problem. Generally speaking we kept each milestone small, ideally each dev would be hitting 1 or 2 milestones each week, not necessarily on the same project. I measured schedule time in quarter-day blocks and had a weekly 'schedule' that showed who was working on what each week. This meant our smallest schedule block was 2 hours... if it was a 5-min job we either did it for free or charged the customer 2 hours, which really helped reduce the mass of tiny jobs into manageable requests. For new products we iterated a lot and involved the customer in specifying the next steps. There was one project that needed a lot of architecture up front, and that got a bit tricky as we had to spend a lot of time building with nothing to show for it, but usually we were able to do it in small sprints (this was before "Agile" hit our corner of the world!). This is pretty much a solved problem now.

annnnd 13y ago
Marcus, thanks for the answer! It sounds like a useful tactic... We are trying to push for a similar system so it is good to know how others cope with it. Thanks again!