John Cutler’s Post

View profile for John Cutler, graphic

Product Stuff ex-{Company Name}

Blocked by another team? There are better and worse ways to deal with the situation👇🏼 Let's take a fairly common scenario. Imagine for a moment that your team relies on another team to complete certain requests. They've set up a system whereby you submit requests, and then they complete those requests and let you know. You're not the only team that relies on this team; other teams submit requests as well. Lately, it has been taking longer and longer for that team to complete the requests. In a couple of retrospectives, team members bring up the fact that it's taking longer for the team to complete the requests and that this is jeopardizing some of the team's goals. What do LESS experienced teams do in this case? ▶ They start putting more pressure on the shared team—asking them for more specific deadlines, checking in on status repeatedly, etc. If you've done this for a while, you know that these things are unlikely to ease the burden and may even make the situation worse for that team. ▶ They start spinning up all sorts of random, lower-value work while they are blocked. Unless these are very small batches of work, the problem with this approach is that quickly you have too much work in progress. ▶ They start complaining about the shared team, undermining confidence in that team, and probably making it harder for that team to address the challenges it's experiencing. ▶ They spin up work-arounds that will ultimately undermine the shared team in an effort to hit their goals. What do MORE experienced teams do in this case? ▶ You offer to help that team in a way that isn't condescending or makes them feel bad. It's one thing to offer to help in a positive way, and it's another thing altogether to offer to help in a way that makes a team feel terrible about their work. ▶ You avoid making any assumptions about how that team will perform. You have to proceed under the assumption that things may take an undetermined amount of time. ▶ Don't play Tetris with an unknown quantity. You establish a queue of very small batches of work, and as a team, you pull from that queue when you're blocked. These have to be very small, though. ▶ You craft a blameless assessment of the impact on your team that doesn't throw that other team under the bus, but that clearly lays out the impact of the situation. Every communication should assume that the team is doing its best given the situation. Stick to the facts and what you can observe. ▶ If the problem is going to persist, you'll need to propose an alternative, and you'll have to make sure this alternative is feasible and respects the physics of the work we do. Most importantly, you need to assume good intent, control what you can control, and don't make the problem worse for either your team or the other team in a quest for short-term results.

Alex Crossley

Agile leader and coach. SAFe | Scrum | Kanban | PRINCE II | ITIL | Jira | Azure DevOps

1mo

As a leader, I refuse to see it as blocked by another team and see this as a failure in planning I have to take greater responsibility for. All the Agile frameworks have ample practices to handle this and it’s almost always a failure to plan together. https://www.agilecoach.com.au/Training/dependencies

Richard Ng

Healthcare Data Analyst

1mo

Project manager should be accountable for tracking dependencies and slippages. Help the project manager upfront to do her job, rather than backdoor escalations.

Like
Reply
Kent J. McDonald

I help organizations build the right software | Product Manager | Writer | Mentor | Specialize in IT, B2B product management, agile software development

1mo

John Cutler thanks for sharing this great reminder of what More experienced teams should do. Those actions are difficult to do in the heat of the moment. What are some positive ways you've found particularly helpful for offering to help another team?

Simonetta Batteiger

Product Leadership Coach, Executive Coach, Leadership Coach, Author, Speaker

1mo

Honestly, this is where I see leadership play a role. This is where I as a product leader seek a conversation with my peer in that team to understand what's going on, how they prioritize their work, how we might help, what other business goals might conflict with our needs, etc... Based om those insights we (my peer there and I) can suggest changes that will unblock my team. I always assume they have made sane choices that lead to this current setup.

Ian M.

Victory Through Observation - Guest on Vasco Duarte’s “Scrum Master’s Toolbox” Podcast!

1mo

Look at the tool and the standard deviation of the time it takes for them to complete any given work item - and do your own estimates of when it will be delivered based on what else they say they have to do first. The non judgemental position is very effective because even a team may not know where all it’s time goes: you could attend the scrum events to see who’s showing up and demanding the teams attention also, see what else they can actually accomplish per sprint just to help have evidence inform your own expectations. Try to also see the relative impact and importance of your work vs any other work and perhaps cobble together a persuasive case of why other prioritized work is being taken in first or why yours should be next. Lastly if the team can’t finish the work it could be the lead dev is getting the handoffs from devs who can’t complete work in general, in which case, you’ll have to discuss the lead dev who may have their own internal, separate backlog of stuff getting done in different order due to communication and coordination effects.

Like
Reply
David C. Holley, MBA

Product Leader | Senior Consultant

1mo

Not to mention that the more experienced will work to raise visibility to the dependency (up front before work begins) and provide a means for ongoing visibility to the status across the board. My team got burned because we needed another team to complete some foundational work. We inadvertently lopped it over the cube and washed our hands to it. About 2-3 months later, it turned into a fire drill when our VP brought it up and we all realize that the other team was essentially sitting in it due to more pressing priorities.

Rodrigo Sperb

Better outcomes with better ways of working

1mo

I think something quite powerful can be to agree to some policies in dealing with dependencies. For example, there can be agreed class of services, for capturing different risk profiles. For anything with same class of service, you can define the underlying principle for what goes first (e.g., longest in WIP).

Team dependency is an age old problem. While many agile frameworks tried to solve it, its still a pain in most cases and teams hesitate to plan safely with dependencies. If you have to choose the worst case scenario for all dependencies, your plan is not going to be realistic. What seemed to work for me in my experience is when I paid attention to two things. Shared outcome: When there is a dependency, make sure there is a clear shared outcome that both teams are accountable for. This will create a good amount of ownership for both teams, as opposed to one team being the 'requestor'  Collaboration, collaboration: Do everything to make sure both teams are communicating clearly and collaborating well. I feel like we are using this word a lot that the meaning is somehow lost. It really means working together towards a common outcome. 

What also can resolve situations like these, is to take the pure human, relational, factor into account. So much unnecessary aggravation can be avoided by simply have a relaxed discussion between the teams, ventilating each position. Conversely, just assuming the other team's intent or incompetence will just lead to building new levels of prejudice, adding to the encumbrance

Mike Virdone

VMware Tanzu Labs - Platform Product Management Consultant

1mo

I'll add another suggestion for what MORE experienced teams can do to get un-blocked: ▶ Re-evaluate the "definition of done" for the dependency. The original ask might infer that "done" requires steps X, Y, and Z to "close the ticket" however completing step X might be all that is needed to get un-blocked and buy both teams some time Having lead platform teams that often ended up in the unenviable position of being the dependency for app teams, this dialog would look something like this: * App: We need a database instance * Platform: Got it, one fully tested, production-grade, resilient, scalable, secure database coming right up * App: Where is it... We need it ASAP * Platform: A fully tested, production-grade, resilient, scalable, secure database takes time, probably a few weeks * App: We just need an endpoint to make sure the app can hit the API in DEV ASAP (and we won't have production traffic for a while) * Platform: OH! We can spin up a DEV instance today if that's all you really needed

See more comments

To view or add a comment, sign in

Explore topics