Hacker News Reader

Comment by marcinzm | Hacker News Reader

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.

View on HN

> 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...

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.

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.

Collective code ownership is a prerequisite to most Agile processes for this very reason.

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.

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).

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.

Reply on news.ycombinator.com