Eliminating dependencies in Scrum

Guest contribution by | 01.11.2021

How dependencies can be effectively eliminated through socio-technical learning.

Organisations need to act quickly and get ongoing feedback from customers to drive sustainable innovation through continuous discovery and delivery of value. But there is a problem: dependencies.

Dependencies are knowledge gaps

Michael James writes that dependencies in knowledge work – as in software development – are caused by knowledge gaps and not by laws of physics.1

He is right about that. The fact that we have to put on our socks before we can put on our shoes does not apply to knowledge work. When writing a book, we can start with the second chapter if we know the content of the first. Knowledge creation is limited solely by the ability to discover and create knowledge, not by physical dependencies.

If there is ambiguity about certain requirements and the Product Owner is not available, if guidance from a database administrator is needed to make a schema change, if development can only begin after the development environment has been deployed, if work can only continue after a change to an API has been completed by another team, if a Product Backlog entry cannot be completed because it has to wait for approval of the change by the change review board, then these are not physical dependencies for teams, but dependencies which are solely due to a lack of knowledge.

What causes knowledge gaps? Are they inherently there, or do they only emerge over time in an organisation? Who is responsible for their creation?

Managing dependencies does not resolve them

Progress in software development can only be made tangible through the delivery of software. If teams do not regularly provide users with new versions of their product, the basis for feedback from users is missing. Without feedback, the progress of development is not visible to the organisation. Managers counter this loss of control by dividing and conquering:

  • If the requirements are unclear, a requirement engineer is assigned to document the customer’s requirement in advance before they can be handed over to the teams.
  • If more problems occur during testing, a test manager is hired to coordinate testing activities across teams.
  • If quality issues arise, a separate quality control department is created to validate the teams’ work and release it if it conforms to the requirements.

When teams are deprived of the opportunity to do their work independently, they have to hand over work to others. And this makes them dependent on them. By creating new functions, units, teams and coordination roles, managers encourage specialisation and division in the organisation. More division leads to more dependencies.

If, on the other hand, we understand dependencies as knowledge gaps, we see that management cannot bring about improvement. Knowledge cannot be shared, pushed around and ordered. It can only be discovered and created where it is missing.

How can organisations discover knowledge gaps?

Uncovering knowledge gaps with Refinement

Scrum teams use refinement for this purpose. This helps them to continuously uncover knowledge gaps by regularly discussing the upcoming work. If several Scrum teams are working together on a product, cross-team refinement has proven to be a good way to continuously identify knowledge gaps across team boundaries.

After identifying the dependencies, we can’t find an execution order that takes all dependencies into account?

Program Dependency Board - Quelle: Solutioneers

In the cross-team refinement, cross-team dependencies are visualised.2

In trying to anticipate dependency in detail in advance in order to plan the work of the teams around it, organisations are embarking on a dangerous path. Nick Tune describes the end of this path as a waterfall. Deep anticipation is at the heart of scaled agile frameworks like SAFe. The waterfall is the extreme end of this deep anticipation.3

Deep anticipation is a tap, and the further 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 takes place – organisations deprive themselves of the competitive advantage of responding quickly to change.

So how can the knowledge gaps be closed?

In the short term, identified knowledge gaps can be addressed by

  • team members working together across teams,
  • reallocating work to other teams,
  • rearranging the product backlog, or
  • individual teams are only responsible for certain features.

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 robs the organisation of the opportunistic value discovery that is at the core of agility.
Therefore, the organisation must sustainably close knowledge gaps without restricting the Product Owner’s scope of action. Which paths lead to this goal?

Socio-technical learning is the sustainable elimination of knowledge gaps

Only learning eliminates knowledge gaps. Learning in an organisational context is a socio-technical activity. We cannot think about collaboration between people and teams or development practices in isolation. It is symbiotic. Instead, we should focus on creating adaptive organisations by constantly removing the technological and organisational barriers between teams so that they can effectively deal with cross-team interdependencies, rather than allowing them to lead to further division in the organisation.

How can socio-technical learning be implemented? I observe the following practices gaining popularity among organisations of all sizes:

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 organisation is called inner sourcing and is thus an approach based on open collaboration and self-organising work. It helps organisation 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, so they are aware of any changes. After updates, each developer has the opportunity to look through the others’ changes and see what they are working on. Branching, on the other hand, delays integration and thus the central exchange of knowledge and should therefore be avoided.

Component Communities of Practice. If Team A and Team B are working on the same code component at the same time, they need to know about each other so they can ask questions and review each other’s code changes. Component communities of practice help facilitate this communication, through mailing lists, chats, occasional meetings or other channels. These communities are organised by component mentors, who are members of teams and take on the additional responsibility of mentoring other teams. In doing so, 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 dissemination of knowledge within the organisation.

Organisation-wide Pair Programming. There are many forms of pair programming that 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. Instead of only collaborating on acute problems, pair programming has become the current state of development in many organisations, even across team boundaries. There, developers enter them in a company-wide calendar to find partners for their Pair Programming sessions. This promotes continuous knowledge building and exchange between developers throughout the organisation.

Team Rotation. Team rotation involves a regular rotation of one member from Team A to Team B and one member from Team B to Team A. Regular rotation provides greater awareness of the big picture and improves the skills of the individual and therefore the team as a whole. In my experience, at least one person from each team should rotate to another team every two to three months. This is also in line with the case studies presented by Heidi Helfand in Dynamic Reteaming.4 If a cross-team dependency occurs, both the knowledge of the other teams’ systems and the strengthened personal relationship help to reduce possible knowledge gaps and friction points in the cooperation at an early stage.

Organisation-wide learning eliminates dependencies

Does your team suffer from dependencies and the resulting delays? Is the Product Owner no longer able to order the Product Backlog according to the highest added value?

Then the counter-intuitive insight from this article should be that more management does not eliminate dependencies, but potentiates them!

The best way to create even more dependencies is to further fragment the organisation through dependency management. Therefore, it is better to create an environment for socio-technical learning. In essence, a learning organisation means that each individual is constantly learning and passing on their knowledge to others. Thus, the way to eliminate dependencies in the long run is to focus on organisation-wide learning.

 

Notes:

Simon Flossmann offers insights into his work as a steward for Scaled Professional Scrum Training, as well as occasionally writing about scaled Scrum and agile product development. If you are interested, you can subscribe to his German newsletter here.

[1] Michael James: The Seattle Scrum Company
[2] Solutioneers: 17 Kanban Dependency Management Hacks To Improve Flow Efficiency, Program Dependency Board
[3] Nick Tune: Strategy, Architecture, Continuous Delivery, and DDD
[4] Heide Helfand: Dynamic Reteaming

Simon Flossmann has published another post in the t2informatik Blog:

t2informatik Blog: From feature roadmap to outcome roadmap

From feature roadmap to outcome roadmap

Simon Flossmann

Simon Flossmann

Simon Flossmann is an experienced Scrum practitioner and has worked from start-ups to large corporations in a variety of industries. As a Professional Scrum Trainer at Scrum.org, he helps Scrum Masters, Product Owners and Agile Leaders implement Scrum to work more effectively.

Because of his deep knowledge and experience working with multiple Scrum teams, Simon Flossmann is one of the two stewards of the Scaled Professional Scrum training, helping to evolve the course and maintain the integrity of Ken Schwaber’s vision on Scrum.