Coordinating dependencies across teams following Agile or Lean practices

When one is following Agile or Lean practices – using Scrum or Kanban framework, on occasions I have encountered what appears to be gray area when it comes to cross team dependencies. The question that comes to mind, when first encountering this situation – What is the best way to coordinate dependencies across teams and there by ensure that the right and left leg are marching in right, left, right, left … rhythm? (or left, right, left, right … rhythm)

We all know hind sight is 20-20, and having been blind sided at least once, I can say that this has a fair chance of recurring when the dependency is one way. Sure its always easier when dependencies are bi-directional as there is the give and take as both sides have something the other wants. I say blind sided, as often priorities or commitments to deliver do not match across teams. If one is aware of this at the outset then its best to negotiate early. However, in the end it is a matter of good faith or in the interest of maintaining good citizenry that the sprint/cadence for delivering the dependency and the dependent feature are synced up as desired. Of course, my intention is not to sidestep the question, which is rephrased here as –

What are the best 3 practices that can help better coordinate dependencies across teams is the question?

  1. Start with good and reliable information in the form of directed dependency graph for the software packages in the system. This helps with the object of the discussion in terms of how many dependencies exist and thus what else is likely to be at risk that may remain hidden to the team that is the provider of the package or service. I doubt if the team is unawares of the direct dependencies, though its possible given the team churn and appearance of new team members who have a relatively short history with the underlying codebase.
  2. Develop common information radiators that provide clear visibility to both client & supplier teams relating to the dependency. What constitutes information radiators?. For starters dashboards that capture the view of the product and sprint backlog, defects in the pipeline and really any trend charts capturing a time history in team accomplishments such as story points fulfilled, defects cured. It would be nice to map complexity of ideas accomplished as this can be a better measure for size of story, however quantifying complexity is difficult to do. Critically having a shared rating of the business and/or customer value that is to be delivered as a result of the dependency being fulfilled, as a component in one of the information radiators, is a powerful reminder to the teams when grooming the backlog and readying for a sprint.
  3. Have a schedule of facilitated Scrum of Scrum’s (SOS), where the standing agenda is to discuss progress and issues around dependencies, and the participants in these meetings are focused on how best to narrow the critical path seen by the one team or another as a result of the dependency and sprint priority.

As for the directed dependency graph, this is unlikely to be readily available as most development environments are running at a fever pitch to make their next release. This requires a culture of looking ahead which doesn’t come easy to those who ought to be responsible for this, namely the development management team. Often they are too busy being upwardly mobile as opposed to working with developers & architects fostering best practices that lead to such artifacts.

There is the school of thought and misplaced in my humble opinion that being Agile means you don’t need such artifacts as there is little of direct value to the end customers. However, if you evaluate the true value stream that the customer has a perspective on, then on average the cycle time for the right feature includes a portion of time spent with support as well as some time needed to repair the identified defect. In this context, time spent developing and maintaining such artifacts can only help reduce the overall cycle time. Another way of looking at this, and sticking to my earlier metaphor – would you travel on the London Underground or New York metro without a map?

Okay, really its never too late to start – have each team draft up what they believe they see the package related directed dependency graph, this will clear up the cob webs and put the teams on a better footing of common understanding. If you are starting this process from scratch then please don’t do what I have witnessed most recently – which was to get some 45-60 engineering managers, product managers and program managers in a big conference room and then ask them to map out the dependency graph for the planned work of their next release. Yep, there was no real starting point as there was no baseline to work from, and it also broke the cardinal rule for meetings – keep it no more then 7-9 people if you want it to be productive with a reasonable set of communications pathways.

Well as you can imagine 45-60 people that just ended up being a fish market and nothing useful came out of this exercise. Sure we sketched out a dependency graph of sorts, but not one which was useful as their was no integrity as to the basis of what was mapped out. Also be wary of the cargo-cult agilitas, as was the case on this occasion. They surely claimed great success for this event, based on the metric that people were seen talking. If memory serves me right this meeting went on for about 2 hours or so, with most people scrambling to put something up on the white board – very little of what was on the board had basis that you could take away from the room. This may seem consistent with the lean practice of delaying commitment until the last responsible moment, alas this was not about decision making but developing a common set graphs to tee up future discussions on synchronizing and prioritizing foundation work for dependencies.

Ideally the dependency graph should be acyclic, however this is unlikely, especially in a code-base that has evolved over time. By the way there are nice open source tools that can generate UML charts, given your current code-base as input. Of course this will be spaghetti graphs that you may have to filter through in order to have a baseline as far as current dependency graph is concerned.

Advertisements
This entry was posted in Kanban, Lean, Scrum and tagged , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s