Individuals & interactions over processes & tools
Lets explore interactions and in particular dependencies that people / teams have.
In a previous article I explored the Individuals part of the title (Should every team be cross-functional?).
I recently stumbled upon (thanks to Charles Betz, Joshua James and Troy Magennis) a taxonomy of dependencies which is a useful frame to think with. It is common for people to think about dependencies as relating only to the work another team has to do. Depending on another team is not the only type of dependency and if you are looking to improve the flow of work you might want to consider some other type and how to handle them.
People often track work dependencies, which is a start, that doesn’t actually eliminate or improve them. Dependencies inhibit flow and since there’s more than one type of dependency to consider, you should really be putting a lot of focus on your dependencies and working as a team to manage and solve them.
Diane Strode — Taxonomy of Agile Software Project Dependencies (2012)
Diane Strode authored a seminal paper on dependency taxonomy in 2012 and then updated it in 2015 (although I’m not able to find an updated copy). A list of Diane’s other papers can be found on her Google research page https://sites.google.com/site/dianestrodepublic/
Troy Magennis — Managing Dependencies
Troy Magennis adds a fourth type of dependency which I think is also quite useful. That is ‘product dependency’ — where you may need to wait to release your product or an update to your product so that other component pieces are also available at the same time.
Troy’s example is a team waiting for Apple to release an updated version of an operating system version before a team’s app can be released / published in the app store. That is out of the team’s control but is critical to understanding and managing.
Troy also talks about blocker clustering which lets you assess what can be solved by the team doing the work or external factors.
Once this clustering is done, the number of days each cluster contributed to flow being blocked. Next, start by breaking down and analysing the problem — 1 understanding the problem (using the 5 whys), 2 finding solutions to the problem.
Once you’ve got solutions in mind, your team should experiment to see if they can reduce or eliminate the blockers. Be aware that if you fix one dependency or blocker, it is likely that another one, may pop up in its place.
The blockers can then be tabulated in a 3x3 matrix: items that are easy — hard to solve vs. the time items have been blocked e.g. high — low. You then focus on the easiest to solve with the highest time blocked and then go from there.
One point really stood out, that is worth repeating!
If it costs more to fix a blocker than it costs in the delay, then it SHOULD NOT be fixed — Troy Magennis
Team topologies — Team APIs
Another source of inspiration is from Team Topologies book and their recent workbook (Remote Team Interactions Workbook — by Matthew Skelton and Manuel Pais) talks about the notion of Team APIs as a way of visualizing and managing dependencies and interactions as interfaces.
Remote-first Team Interactions with Team Topologies - Team Topologies
Remote-first work is the "new normal" for companies around the world. There is no shortage of advice on how individual…teamtopologies.com
They have some great resources on the above page, the Team API template and Team Dependencies Tracking templates, however I suggest becoming familiar with it all rather than cherry picking.
Summary
If you are writing or slicing stories (described in Be a samurai, not a lumberjack), understanding and managing the dependencies are as important as the stories themselves from a flow perspective. If you aren’t managing each type of dependency (see above) in an active way, you are allowing blockers to impede flow, which means you won’t be able to improve your time to market.
For learning and knowledge dependencies, you should invest and prioritize time in your teams, so that you aren’t just building a culture of learning (check out Getting better at getting better) - instead actually creating a culture of continuous improvement that can be linked to the blockers your team is facing. This is a more compelling reason for people, giving that learning and improvement a driver. Is that new certificate / online course really going to help the team, or just puff up someone’s LinkedIn profile.
So visualize items on your backlog for continuous improvement that unblock other items. Highlighting an item with a red flag is a first step but not enough. Most modern tools are terrible at creating the necessary data behind being able to effectively track the types of dependencies so you might have to resort to simpler systems until you find an approach that works.
Dependencies must be managed and eventually resolved through several different techniques. More time should be spent on this aspect of creating flow!
What do you think, and how do you manage the types of dependencies? I know SAFe uses red string to track dependencies across teams, which is really only one type, I’m not sure how much further it goes. I’d love to see what others are doing!
The below reminds me of a murder mystery, rather than anything else…
How it seems…
