Organizations need to move fast and receive ongoing feedback from customers to drive sustainable innovation through continuous discovery and value delivery. But there is a problem — dependencies.
Dependencies are knowledge gaps
According to Michael James, dependencies in knowledge work — as in software development — are caused by knowledge gaps and not by the laws of physics.
He's right. Putting on our socks first before putting on our shoes does not apply to knowledge work. We can start writing a book with the second chapter if we know the content of the first. Knowledge creation is constrained solely by the ability to discover and create knowledge, not by physical dependencies.
If there is any ambiguity about the requirement and the Product Owner is not available, if guidance from a database administrator is required to make a schema change, if development can only begin after the development environment has been provided, if work can only be continued, after the change to an API by another team has been completed, if a Product Backlog item cannot be completed because the Change Review Board has to approve the change first, then these are not physical dependencies for teams, but dependencies that are solely due to a lack of knowledge.
What causes gaps in knowledge? Are they inherently there, or do they emerge over time in an organization? Who is responsible for their creation?
Management of dependencies does not resolve them
Progress in development can only be made tangible through the delivery of software. If teams do not regularly make new versions of the product available to users, user feedback is missing. Without feedback, development progress is not visible to the organization. Managers counter this loss of control by divide and conquer.
If requirements are unclear, a requirements engineer must document the customer's needs before handing them off to the teams. If more and more problems occur in the test, a test manager is hired to coordinate the test activities across teams. A separate quality control department is set up if there are quality problems, which validates the teams’ work and approves if it conforms to the requirements. When teams are deprived of the ability to do their work independently, they must hand off work to others. That makes teams dependent. By creating new functions, units, teams, and coordination roles, managers reinforce specialization and division. More division leads to more dependencies.
On the other hand, if we understand dependencies as knowledge gaps, managing them cannot bring improvement. Knowledge cannot be shared, moved around, or ordered. It can only be discovered and created where it is missing.
How can organizations discover knowledge gaps?
Uncover knowledge gaps with refinement
Scrum teams use refinement to do this. Refinement helps teams continuously uncover knowledge gaps by regularly discussing the upcoming work. If multiple Scrum teams work together on a product, cross-team refinement has proven effective for constantly identifying knowledge gaps across team boundaries.
After identifying the dependencies, can't we then find an execution order that takes all dependencies into account?
Organizations are heading down a dangerous path trying to anticipate dependency in detail upfront to plan the team's work around it.
Nick Tune describes the end of this path as waterfall. Deep anticipation is at the heart of the scaled agile framework. Waterfall the end of this deep anticipation. Deep anticipation is a water faucet: the more we turn it on, the closer we are to the waterfall, no matter what we call our process. In a constantly changing environment — where product development occurs — organizations moving down that path lose the competitive advantage of reacting quickly to changes.
How then can knowledge gaps be closed?
Having team members collaborate across teams, reallocating work to other teams, rearranging Product Backlog items, or making teams own only certain features can address identified knowledge gaps in the short term.
This short-term mindset comes at a price: the Product Owner can no longer order the product backlog according to what is likely to deliver the most value. This mindset robs organizations of opportunistic value discovery, of which agility is at its core.
That is why organizations have to close knowledge gaps in the long term without restricting the Product Owner's decision-making abilities. What are the ways to do this?
Sociotechnical learning is the sustainable elimination of knowledge gaps
Only learning eliminates knowledge gaps. Learning in an organizational context is a sociotechnical activity. We cannot think about the collaboration between people and teams or the advancement of development practices in isolation here. It’s symbiotic. Instead, we should focus on creating adaptive organizations by constantly removing the technological and organizational barriers between teams to deal with cross-team dependencies rather than further dividing the organization.
How can sociotechnical learning be implemented? I observe that among organizations of all sizes, the following practices are gaining popularity:
Inner Sourcing. If Team A needs changes to team B's code, but Team B has other priorities and therefore blocks Team A, Team A can make changes to Team B's code and submit a pull request. Open source within an organization is referred to as inner sourcing and is thus an approach based on open collaboration and self-managing work. It helps organizations to enable collaboration across team boundaries.
Communicate in Code. Teams use continuous integration, which means that each developer checks all their code into the central repository. Everyone syncs with the repository several times a day and gets to see all the changes others have made. After updates, each developer can look through everyone else's changes and can see what they are working on. Branching, on the other hand, delays integration and thus centralized knowledge sharing and should be avoided.
Component Communities of Practice. If Team A and Team B are working on the same code component simultaneously, they need to know about each other to ask questions and review each other's code changes. Component Communities of Practice help enable this communication through mailing lists, chat, occasional meetings, and other channels. These communities are organized by component mentors, who are ordinary team members and take on the additional responsibility of mentoring other teams as they evolve. They do not approve changes to the component but support developers with design workshops, code reviews, and as contacts for implementation questions. These mentorships promote the distribution of knowledge within the organization.
Organization-wide Pair Programming. Many forms of pair programming can be beneficial. For example, if we see a dependency between Team A and Team B, members of Team A could temporarily work closely with members of Team B to jointly solve the problem and learn from each other. Rather than collaborating only on acute problems, pair programming has become the state of development in many organizations, even across team boundaries. There, developers sign up on a company-wide calendar to find partners for their Pair Programming sessions. This practice promotes continuous knowledge building and exchange between developers organization-wide.
Team Rotation. With team rotation, one member of Team A rotates to Team B, and one member of Team B rotates to Team A on a regular schedule. Regular rotation provides greater awareness of the big picture and improves the skills of the individual and, thus, the entire team. From my experience, at least one person should rotate on each team every two to three months. This insight is also consistent with the case studies presented by Heidi Helfand in Dynamic Reteaming. If a cross-team dependency arises, the knowledge of the other teams’ systems and the strengthened personal relationship helps to reduce possible knowledge gaps and friction points in the collaboration at an early stage.
Organization-wide learning eliminates dependencies
Is your team suffering from dependencies and the resulting delays? Is the Product Owner no longer able to order the Product Backlog according to the highest possible value?
Then the counterintuitive insight from this article should be that more management doesn't eliminate dependencies. It increases them!
The best way to create even more dependencies is to further divide the organization through dependency management. Therefore, it is better to create an environment for sociotechnical learning. In essence, a learning organization means that each individual is constantly learning and passing on their knowledge to others. In the long run, the way to eliminate dependencies is to focus on organization-wide learning.
Want to learn more?
Hopefully, this article was useful for you. Cross-Team Refinement is one of the many interesting topics that is covered in the Scaled Professional Scrum course. If you’d like to join the Scaled Professional Scrum course, check out my class schedule page for more information.