When I facilitated the Product Owner Value Game at IBADD2016, I asked the participants to suggest some things about the activity, or product ownership in general that puzzled them. One of the items was one word written on a sticky note.
There is a lot involved in that sticky note. Dependencies have always been an issue, but until self managing teams and stand-back leadership became popular, teams could always look to others to handle dependencies. This didn’t always work very well, but at least the teams had plausible deniability.
What I suspect the person who wrote that post it note was really asking is “how do we deal with dependencies in an agile environment”. I have found a few strategies that work well for dealing with dependencies, and generally put them into four categories:
- Get rid of as many dependencies as you can.
- Deal with dependencies inside your team
- Deal with dependencies between teams working on the same project/product
- Deal with dependencies with teams outside your project/product.
Get Rid of as Many Dependencies as you Can
The best way to deal with dependencies is to not have them at all.
In reality You won’t be able to get rid of all of your dependencies but you can get rid of quite a few. The trick to doing that is uncovering the source of the dependencies.
Dependencies occur because work is divided up between the team in a way that requires one thing to be done before another item can be done. Organizing teams based on activity – Analysts, Designers, Developers, Testers – where you have a team of analysts do some work then toss it over the wall to designers, and so on causes this problem. Building a cross functional team can often help this issue. You may also run into this problem when you divide the work up along architectural layers – one team does all the database work and another team does all of the user interface work. More often or not, this is still dividing work based on activity, but in this case it’s mostly on technology lines. Proper story splitting can help prevent these type of dependencies.
Dependencies also occur based on the number of people involved in a project. Sometimes you can avoid having a large number of people on a project, sometimes you can’t. It depends on the size of the problem, the size of the solution, and how quickly you’d like to solve it. I’m inclined to believe if you dig deep to understand the problem you are trying to solve in the first place, you may avoid dependencies by gaining better clarity on the problem they are trying to solve in the first place. If you don’t need a big team, don’t use one. Identify a very limited, very specific problem and identify a specific solution to resolve it.
Finally, dependencies come about when you split the work based on the steps of the business process you are supporting. This approach often leads you to believe that you have to deliver the functionality in the same order in which it is used. This belief results in perceived dependencies that don’t really exist. Instead of building things in the order that they will be used you can pick an order of implementation based on which way will help you learn the best and require the least amount of coordination as opposed to doing it in a very specific order which may call for more coordination.
There are going to be some dependencies that you can’t avoid and will just have to deal with. You have some options for dealing with them, and those options vary depending on if the dependencies are:
– inside your own team (within your span of control)
– with other teams working on the same project/ product (within your span of influence)
– with other parts of the organization.
It’s instructive to look at all three scenarios because the strategies for dealing with dependencies differ in each case.
Dependencies Inside Your Own Team
If you have to have dependencies, these are the ones you want to because they are completely within your span of control.
Assuming you’ve gone through the though process described above and still have dependencies within your own team dealing with them becomes a matter of identifying the dependencies and discussing with the team what’s the best way to sequence the items to minimize their impact.
The way you approach sequencing depends on what approach you are taking toward your work. If you are taking a time boxed approach (i.e. Scrum) where you plan the items you are going to work on for the next time box (i.e. sprint) and then lock down what you are working on until the end of that time box, your basic decision is whether it makes more sense to bring the items with dependencies into the same sprint, or to explicitly schedule the predecessor in one sprint, and the successor in a subsequent sprint. The route you go there depends on the size of the items that have the dependency and what the nature of the dependency is. Dependencies of this nature occur where you create some initial functionality and then have future work to expand upon that functionality. If you go this route, you will see some value in delivering the foundational functionality to your stakeholders and get feedback before expanding capabilities too extensively. The feedback you get may tell you that you do not need to extend your capabilities, or will at least give you guidance on what capabilities to expand.
If you are approaching work in a continuous flow manner (as suggested by Kanban), your decision basically comes down to when do you tackle the predecessor, and how long do you wait to deliver the successor items, so in many cases the decision may be a little more clear cut. The suggestion about pausing between delivery of the predecessor and the successor to get some feedback still holds true in this case, and you may find you have a bit more flexibility as to how long do you go between delivering the base functionality and the extensions.
Of course, this line of reasoning assumes that you have explicitly identified the dependencies that exist between items and your team has had conversations about how you would like to handle them. I’ve found it helpful to include consideration of dependencies (both inside and outside the team) in my definition of ready so that it acts as reminder of the team to at least discuss whether any dependencies exist before they launch into delivery on an item. You may want to go beyond merely identifying that a dependency exists and discuss the nature of it as a team, or at least with the relevant members of the team involved, so that you have a clear idea of the impact of the dependency when you start delivery work.
Dependencies on Other Teams Working on the Same Project/Product
Dependencies outside of your team are more involved to deal with primarily due to the amount of control or influence the teams have on each other. If the dependency is between two teams working on the same project or product, you should at least have some influence over whether the other team picks up the dependency and delivers their end of the bargain. This is mostly because both teams are (hopefully) working toward the same goal.
The Scaled Agile Framework (SAFe) provides guidance for dealing with this type of dependencies in their program level. One of the main activities in Program Increment (PI) Planning is for all the teams working on a product to identify dependencies with other teams, note what those dependencies are, and discuss those dependencies with those teams. The idea of getting people talking together to note dependencies is a great one, though I still wonder about the effectiveness of it is to bringing over 100 people together for those 2 – 3 days. Yes, it gives everyone a say, but when you have that many people involved you find that you have several people who are not involved in the discussions. But this is not a post on the merits of PI Planning in SAFe.
Identifying dependencies is one thing, but the rubber really meets the road when it comes down to what those teams do with that information once they start delivering. Just as inside the team situation, the idea of getting together and identifying and discussing dependencies is so that the people involved can come up with a plan for addressing them and make the appropriate decisions along the way. The same is the case in the dependencies between teams, and the part that you may easily forget is to KEEP TALKING to the teams that you have dependencies with after planning. Touch base on when the team is going to work on the dependency. Discuss any key interfaces or agreements that the teams need to have – it’s in this case where having discussions, and then writing the agreements down can prove to be very helpful. Documentation still has it’s place.
Dependencies between two teams within the same project or product are within the teams’ span of influence because an effective project/product team generally establishes agreements on how teams with dependencies will work together to get those dependencies cleared. Failing that, the teams most often work in the same part of the organization, so problems with inter team collaboration can be escalated when the teams themselves seem unable to work it out, and those escalation paths are clearly identified. In a lot of cases, the project/product team may have people whose main responsibility is making sure that those conversations happen (for example Release Train Engineers).
Dependencies on other Teams Outside the Project/Product
The dependencies that you have with teams outside of your product or project prove to be the most difficult to clear, primarily because you certainly don’t have any control and rarely have much influence. These dependencies arise when one team relies on a central services group to perform some task for them, or when one product finds that the easiest way to address a need is to use functionality produced by another product.
The key strategies to deal with these types of dependencies remain the same as with teams working on the same product:
- Identify the dependency
- Establish an agreement between the teams of each others responsibilities (for example, documented interfaces)
- Communicate while work is under way to make sure all the teams involved understand the current state of any work.
The big difference is that if one of these steps does not occur, or the teams have a breakdown in communication, the escalation path is often not as clear, and internal politics become a bigger hinderance in dealing with any issues.
The best way to avoid this problem (other than not having dependencies with other teams) is to openly discuss how the teams will work through any challenges they run into and in effect agree to their escalation path before one is needed. This type of conversation rarely happens because teams generally believe they won’t need that type of arrangement. Ironically, it’s those teams that most often find themselves some way of resolving disagreements.
Yes, I’m effectively suggesting that these teams work out a contract of sorts so that they have an agreed upon method of addressing challenges when they arise.
Folks could say that flies in the face of Collaboration over Contract Negotiation. Perhaps, but what I’m suggesting is establishing some agreements when teams first start working together so that they can collaborate effectively before the relationship deteriorates in such a way that all of the interactions between the teams becomes contract negotiations. I have found when working with outside vendors that a bit of well thought out discussion about how the organizations will work together at the beginning will make the interactions after the fact much more productive.
Common Sense, Not Common Practice
There really is no silver bullet, no magic technique that teams can use to address dependencies. It comes down to avoiding dependencies as much as possible, and when you do have them, communicate about them. Discuss the dependency when it’s first identified. Discuss who is responsible for what. Let those who are dependent upon you know where things are at. Confirm that those you are dependent upon have actually addressed the dependency. This sounds easy to do. It sounds like a no brainer. But like many other things, when teams get in the heat of the moment, they often forget those common sense actions. If you deal with a lot of dependencies, you may find making some of these ideas common practice will make your work go much smoother.