4 ms·

I would honestly like to reverse this question... What sort of business can't look three months ahead?! Seriously, updating business logic rules to catch a tre

I would honestly like to reverse this question... What sort of business can't look three months ahead?! Seriously, updating business logic rules to catch a trend or adjust for changing external conditions, I understand. But for software development?!

kqr 4y ago
Sure! I often start to make things which seem like a good idea at the time but after 1--8 weeks of A/B testing (or other verification methods) it turns out the market was not what I thought and it would be a waste of time to pour more work into it. At that point I can either "stick to the 3 month plan" and do something which I know has at best no value, or... try something else.
marcinzm 4y ago
Your team is working on a dozen features for the next three months. After looking through the code to start implementing one feature (4 weeks into the 3 months) the team realizes there is need to change another team's API. The other team already has all their time booked with feature. Cue a cascading set of slightly changing priorities. Now multiply that by every team in the company hitting something like this.
- roguecoder 4y ago
  Collective code ownership is a prerequisite to most Agile processes for this very reason.
  - marcinzm 4y ago
    In my experience most companies specialize teams to various extents which makes true collective ownership difficult. An iOS team is likely going to have difficulty dealing with the ML code. This becomes even worse if the change is complex or touches the domain specific patterns.
    - drran 4y ago
      It's known as «the bus problem». Peer review is used to address this, to make someone else a bit more familiar with your code, so he will be able to help you when you are overwhelmed and need help (or when you hit by a bus). Also, built-in documentation, run books, guides, and automated test cases are very helpful for those, who are not familiar with your code base. It reduces job security tough. (I hit by that multiple times, because, for management, it feels like good developers and good administrators are doing nothing or constantly pick-up very easy tasks to do).
  - manmal 4y ago
    But the iOS team can’t know everything about the server API, the ops team has no control over App Store release processes, iOS team usually has no push permissions for Android etc Different code bases in the org might even have different process certifications they have to follow, eg in medical software or some other industries. In those cases it’s downright impossible/illegal to give every team access to every repo. SAFe is supposed to solve this. I haven’t heard anything good come out of it though so far, so I find this thread very interesting.
- theptip 4y ago
  Dream scenario - in the planning session note you depend on an external API. Prioritize an early spike/prototype of the feature to flush out dependency risks. Discuss relative priorities with the other team & schedule the work to modify their service. This requires teams to have slack/contingency time in their plans. That’s important. Of course, there will always be situations where you don’t spot a dependency until you start coding. But in the loosely-coupled mode, that is what happens every time you have a dependency on someone else, ie you have no opportunity to spot in advance. Worth some planning exercise you get an opportunity to spot the dependency and deal with it gracefully, even if you don’t catch 100%. But yeah, if there is no benefit to spotting early because the other team doesn’t have slack for the Q, then less point in planning in advance.
- tonyarkles 4y ago
  > After looking through the code to start implementing one feature (4 weeks into the 3 months) the team realizes there is need to change another team's API. On the estimation side of things, I've worked with teams that do estimates in concrete hours, days, weeks, etc, and teams that work in abstract feature points, bushels, etc. The number one factor for whether the estimates are successful is the time spent before providing the estimate to figure out what the actual scope of the task is. If you've planned and estimated a task and didn't discover the cross-team dependency during that planning, you've failed at planning. It happens. It sucks. It should be very rare. I've worked with teams where "sprint planning" every two weeks/whatever cadence is basically an entire engineering team getting pulled into a room for a morning, the manager/scrum-master/whatever pulls up their backlog and starts picking tasks off the top. The team is expected to provide estimate efforts on the fly in the meeting, and then expected to spend the next two weeks perfectly executing on the work they've committed to. How in the hell is a process like that going to allow people to really think through the issues that are going to arise (like needing an API change on another team, or even verifying that a 3rd-party API is compatible with what the task is trying to achieve)? These teams constantly run into the issue you've described and it absolutely sucks for everyone (the business, the managers, the developers), but the process just keeps being adhered to. Maybe in the post-mortem someone will say "we need to do a bit more analysis before doing estimates", and the outcome is that during the next sprint planning session the SM will say "HAVE YOU REALLY REALLY REALLY THOUGHT THIS THROUGH?" but... they're still doing analysis on 12 new tasks blind...
- drran 4y ago
  It looks like risk planning was not done by your project manager. Risk planing includes risk prediction, calculation of possible time and/or monetary damage, risk reduction. For example, if we see that Foo can cause problem in near future with probability of 10% and can delay project with 5 members by 3-40 days, then average risk of lose is `0.1 * (40 - 3)/2 * 5 = 9.25` man-days. If we can reduce risk probability by factor of 10 by spending 2-man days of work early (1 man day of project manager + 1 man-day of a developer), then we will reduce cost to `0.01 * (40 - 3)/2 * 5 + 2 = 2.925` man-days, so 6.325 man-days are saved.
tikhonj 4y ago
You can predict some things, sure—but there's a massive leap from that to planning "the entire next 3 months"! If you can get a bunch of people into a room and plan out what everyone on a software team is doing for the next three months, there's a pretty clear cap on how creative or adaptable the work can be. What is everyone doing for the rest of the quarter? "Executing"? Just filling in the "obvious" implementation details to program exactly what they're told?
- brightball 4y ago
  I guarantee your product team has enough things that they want done to plan your next 3 years. Getting a clearer picture of the next 3 months should be a piece of cake. As a bonus once it’s planned you should get to focus without a sudden shift in priorities.
  - kqr 4y ago
    Oh the product team has good ideas for the next decade. The question is how many of them have they actually had a real chance to validate with real users in production? Close to zero, in my experience. That's one reason why you want to be able to change priorities quickly. (Note: quickly, not suddenly. Bad performance in market validation should never come as a complete surprise. It always slowly dawns on you over the course of days/weeks.) Another reason for changing priorities quickly is that the specification drawn by the product team happens to be technically very complex because it interacts in unforeseen ways with other functionality, and this is discovered early in implementation. Basically, in product development, you're constantly running into things that either provide less value than expected, or cost more than expected. That's when you should do something else instead. Once you have a great idea, yes, you should sink all of your effort and focus into that to get it to market quickly. But the idea is that if you start cautiously and change your mind early and often, you can actually implement the winners with blazing speed later without looking back.
  - hackerfromthefu 4y ago
    This goes out the window if your org does any sort of sales or strategic initiatives that weren't in view of the product people you're working with. Which is most orgs I've worked with.

kqr 4y ago

Sure! I often start to make things which seem like a good idea at the time but after 1--8 weeks of A/B testing (or other verification methods) it turns out the market was not what I thought and it would be a waste of time to pour more work into it. At that point I can either "stick to the 3 month plan" and do something which I know has at best no value, or... try something else.

marcinzm 4y ago

Your team is working on a dozen features for the next three months. After looking through the code to start implementing one feature (4 weeks into the 3 months) the team realizes there is need to change another team's API. The other team already has all their time booked with feature. Cue a cascading set of slightly changing priorities. Now multiply that by every team in the company hitting something like this.

roguecoder 4y ago
Collective code ownership is a prerequisite to most Agile processes for this very reason.
- marcinzm 4y ago
  In my experience most companies specialize teams to various extents which makes true collective ownership difficult. An iOS team is likely going to have difficulty dealing with the ML code. This becomes even worse if the change is complex or touches the domain specific patterns.
  - drran 4y ago
    It's known as «the bus problem». Peer review is used to address this, to make someone else a bit more familiar with your code, so he will be able to help you when you are overwhelmed and need help (or when you hit by a bus). Also, built-in documentation, run books, guides, and automated test cases are very helpful for those, who are not familiar with your code base. It reduces job security tough. (I hit by that multiple times, because, for management, it feels like good developers and good administrators are doing nothing or constantly pick-up very easy tasks to do).
- manmal 4y ago
  But the iOS team can’t know everything about the server API, the ops team has no control over App Store release processes, iOS team usually has no push permissions for Android etc Different code bases in the org might even have different process certifications they have to follow, eg in medical software or some other industries. In those cases it’s downright impossible/illegal to give every team access to every repo. SAFe is supposed to solve this. I haven’t heard anything good come out of it though so far, so I find this thread very interesting.
theptip 4y ago
Dream scenario - in the planning session note you depend on an external API. Prioritize an early spike/prototype of the feature to flush out dependency risks. Discuss relative priorities with the other team & schedule the work to modify their service. This requires teams to have slack/contingency time in their plans. That’s important. Of course, there will always be situations where you don’t spot a dependency until you start coding. But in the loosely-coupled mode, that is what happens every time you have a dependency on someone else, ie you have no opportunity to spot in advance. Worth some planning exercise you get an opportunity to spot the dependency and deal with it gracefully, even if you don’t catch 100%. But yeah, if there is no benefit to spotting early because the other team doesn’t have slack for the Q, then less point in planning in advance.
tonyarkles 4y ago
> After looking through the code to start implementing one feature (4 weeks into the 3 months) the team realizes there is need to change another team's API. On the estimation side of things, I've worked with teams that do estimates in concrete hours, days, weeks, etc, and teams that work in abstract feature points, bushels, etc. The number one factor for whether the estimates are successful is the time spent before providing the estimate to figure out what the actual scope of the task is. If you've planned and estimated a task and didn't discover the cross-team dependency during that planning, you've failed at planning. It happens. It sucks. It should be very rare. I've worked with teams where "sprint planning" every two weeks/whatever cadence is basically an entire engineering team getting pulled into a room for a morning, the manager/scrum-master/whatever pulls up their backlog and starts picking tasks off the top. The team is expected to provide estimate efforts on the fly in the meeting, and then expected to spend the next two weeks perfectly executing on the work they've committed to. How in the hell is a process like that going to allow people to really think through the issues that are going to arise (like needing an API change on another team, or even verifying that a 3rd-party API is compatible with what the task is trying to achieve)? These teams constantly run into the issue you've described and it absolutely sucks for everyone (the business, the managers, the developers), but the process just keeps being adhered to. Maybe in the post-mortem someone will say "we need to do a bit more analysis before doing estimates", and the outcome is that during the next sprint planning session the SM will say "HAVE YOU REALLY REALLY REALLY THOUGHT THIS THROUGH?" but... they're still doing analysis on 12 new tasks blind...
drran 4y ago
It looks like risk planning was not done by your project manager. Risk planing includes risk prediction, calculation of possible time and/or monetary damage, risk reduction. For example, if we see that Foo can cause problem in near future with probability of 10% and can delay project with 5 members by 3-40 days, then average risk of lose is `0.1 * (40 - 3)/2 * 5 = 9.25` man-days. If we can reduce risk probability by factor of 10 by spending 2-man days of work early (1 man day of project manager + 1 man-day of a developer), then we will reduce cost to `0.01 * (40 - 3)/2 * 5 + 2 = 2.925` man-days, so 6.325 man-days are saved.

tikhonj 4y ago

You can predict some things, sure—but there's a massive leap from that to planning "the entire next 3 months"! If you can get a bunch of people into a room and plan out what everyone on a software team is doing for the next three months, there's a pretty clear cap on how creative or adaptable the work can be. What is everyone doing for the rest of the quarter? "Executing"? Just filling in the "obvious" implementation details to program exactly what they're told?

brightball 4y ago
I guarantee your product team has enough things that they want done to plan your next 3 years. Getting a clearer picture of the next 3 months should be a piece of cake. As a bonus once it’s planned you should get to focus without a sudden shift in priorities.
- kqr 4y ago
  Oh the product team has good ideas for the next decade. The question is how many of them have they actually had a real chance to validate with real users in production? Close to zero, in my experience. That's one reason why you want to be able to change priorities quickly. (Note: quickly, not suddenly. Bad performance in market validation should never come as a complete surprise. It always slowly dawns on you over the course of days/weeks.) Another reason for changing priorities quickly is that the specification drawn by the product team happens to be technically very complex because it interacts in unforeseen ways with other functionality, and this is discovered early in implementation. Basically, in product development, you're constantly running into things that either provide less value than expected, or cost more than expected. That's when you should do something else instead. Once you have a great idea, yes, you should sink all of your effort and focus into that to get it to market quickly. But the idea is that if you start cautiously and change your mind early and often, you can actually implement the winners with blazing speed later without looking back.
- hackerfromthefu 4y ago
  This goes out the window if your org does any sort of sales or strategic initiatives that weren't in view of the product people you're working with. Which is most orgs I've worked with.