What is tugging at your team?
External dependencies cause:
- Communication overhead
- Risk of conflicting interests
- Temporal dependencies and scheduling problems
(Interruptions from auditing, or bugs found by external quality assurance, is a version of temporal dependencies.)
This consumes resources that could’ve created value.
As soon as the software organization grows enough for the developers to split into more than one team, the dependencies will change. In the worst case both teams depend on everything the old team depended on, and each other. Managing dependencies more important in bigger companies (due to math). Kent Beck has a great text on what you can do to deal with dependencies from within an existing team. The suggestions below require more influence over the organization. The goal is to create working software with as few dependencies as possible for each team, while maintaining a reasonable team size. The book Team Topologies covers much more on how to organize teams, so I include their names for different teams along my own.
Including the stakeholder in the team
This is done in DevOps. When running the code is included in the responsibilities for the team, operations is no longer a stakeholder. The same can be done with product, security and user experience. This is one of the reasons to have the customer be part of the team in XP. A cross functional team gathers all expertise in one place. The main focus is solving the business problem as well as possible. This improves all three listed problems with dependencies, since collaboration is moved to within the team.
Intent centered software teams — slicing teams along intent
Organize teams around their goal (user path or feature) instead of what technology they use. This also requires cross functional teams. It is easier for the code to adhere to the single responsibility principle when the team has only one goal. In Team Topologies the “Stream aligned team” is clearly intent centered. “Subsystem teams” and “platform teams” can also fit the description, if the other teams are seen as their customers. Solving the scheduling aspect of the dependencies relies on that the stream aligned teams can move forward independently of the subsystem and platform teams. (Platform teams are very different from a backend team, that still has to implement changes for each feature in the frontend.)
One way to see it is that the business logic is created by stream aligned teams. The technical advantage can be created as a subsystem or platform, used to improve the work of other teams as it gets available.
Service teams — from push to pull
If the overhead from having specialists in each team gets too big, you can have service teams. In Team topologies those are “Enabling teams”. This flips the direction of dependency between teams. If the legal team is there to control, it is a stakeholder for the software team. On the other hand, if the software teams take full responsibility for the legality of their code, the legal team can be there to serve them. The legal team then has the software teams as their stakeholder. It can still create delays, but the control and the responsibility is with the development team. Legal advice is pulled from the legal team instead of pushed to the development team. This can be used for other areas as well. Service teams still have to manage their time, but they should at least not have to explain why their work is needed. So the conflict in interests is solved.
Universal design — including diversity in the norm
The core in universal design is to move away from the able bodied user as a norm. People with disabilities are not a new kind of user, they are a part of the general user. We design for different screen sizes, without having stories like “as an iPad user I want to be able to buy a ticket”. The same way we can simply make accessibility a part of how we work. This is easier with a diverse team. Universal design can also be expanded to include other marginalized groups. I don’t think that “as an African American I want to be able to use face recognition” should (need to) be its own story. It is what we want to achieve that differentiates users, not the circumstances we are (currently) in.
Bonus: Cutting dependencies within a team
Read my posts on working in an ensemble! This deals with all the listed problems with dependencies, but between individuals within the team.
Offer
SAMMAN TECHNICAL TRAINING
Send your team to a course and some of them will remember part of it. Use the Samman method and they will apply what they learn from day one.
Book a meeting if you want to talk to me about agile methodology, to explore how I might help your team. I offer this for free, since I rather talk tech than do sales pitches. Let's explore if I can help you, by trying to solve your problems from the start.
Comment on the blog!
Create a comment by emailing me.
Open an email to start writing.I will then add the comment to the post.