AUTHOR: Ryan Griggs, Scrum Master

Good developers and good farmers are the same people…

I have an appreciation for farmers, but not for their actual farming abilities. Successful farmers represent the closest example of what it means to be cross-functional. Not only do they know how to farm, but they are also engineers, accountants, scientists, meteorologists, and a host of other titles that are needed to run a farm. This is not to say that farmers are experts in all these fields, but they are functionally aware of and are able to address most tasks related to those fields while being experts in actual farming. Cross-functional knowledge enables small numbers of farmers to produce millions of tons of crops that feed nations. Effectively running a profitable farm requires a broad knowledge base and is hard work!

Software is also hard work, and the most effective development teams are just like farmers: cross-functional. Developers that resemble the idyllic T-Shaped, broad knowledge with a deep specialization, should be cultivated within their organization and teams.

I made the connection between farmers and my current experience while watching an episode of Smarter Every Day, a YouTube channel hosted by the engineer, Dustin Sandlin, who has an obsession for understanding WHY “everything” is, and HOW that “everything” is. During this particular episode, Dustin delved into what it takes to farm in modern America, but the part that stood out for me most was the grain silo. Dustin was shown the inside of a silo which was in the process of being emptied. However, the farmer did not let them venture beyond the entrance to the silo, as it turns out mountains of grain can be deadly if it decides to form an avalanche and then bury you alive. Perhaps being cross-functional makes it easier to see these dangers…

“Here lays Ryan, killed by quasi-sentient kernels”.

Silos in software development are deadly too, but rather than physically killing a team, their ability to respond to change is affected. In essence, the team has lost its agility. One of the teams I work with is currently buried alive in metaphorical corn and remarkably the team disagrees with my assertion that they are eyeballs deep in popcorn and it’s getting deeper. Evidently, the dangers of physical silos are easier to identify and understand.

“I blame silos!”

 

Silos building silos

Organizational Goals

Every organization has goals that are prioritized as projects that are funded, developed, deployed, and then potentially monetized. Projects need to compete with each other for funds before being selected for implementation and the competition gets more intense the bigger the organization is.

Large project initiatives will have some sort of support or management layer above the project teams to help prioritize delivery and avoid waste by securing strategic solutions for problems, avoiding many local tactical solutions, and keeping the development focus on the most valuable features. Different organizations have different titles for this team. I call this team the PPP team.

The PPP team is incentivized to deliver on the organizational goals however, these incentives are individualized and not rewarded to the team as a whole. Usually, this is an artifact of traditional business structures that remain after an organization has initially adopted agile. The unintended consequence of rewarding individuals over teams is that it removes the drive to collectively deliver a solution. Instead, individuals work towards securing their personal goals, and thus, they secure their associated rewards. This results in a loss of efficiency, individual goals being prioritized over the whole, potential conflict, and all of this dysfunction is then pushed down onto the development teams.

Development Team level

Each team receives their development priorities from the PPP team member under which they fall. It is then up to the teams to determine how best to implement the priorities. However, the collaboration between teams is only effective as the priorities received from the PPP members. When there is a misalignment in priorities from the PPP team, dependency management between feature teams becomes all but impossible.

Individual-level

Ideally, the development teams need to keep their output focus at the team level and not plan for individual capacity. The development team is currently maximizing individual capacity which is loosely related to a greater sprint goal. Similar to the PPP team, individuals within the development team are incentivized to complete their work, ie. focus on the “I” and not the team.

 

Symptoms follow silos

Once these silos had formed, the symptoms of dysfunction started to manifest…

Tactical solutions have become commonplace with multiple teams, building solutions for the same problem but unique to their specific products. The waste generated from tactical solutions are multifaceted, not only is a solution to a problem built multiple times but ultimately, once a strategic solution is available, those features will have to be refactored to fit with the strategic solution or left as is to be managed and supported by the development team.

Inter-team collaboration and innovation have dried up. Teams are focused on their own mandates and do not have the time or motivation to collaborate unless they can drive their goals forward.

Inter-personal relationships are under strain. As each individual is allocated work to capacity, there is little leeway to adjust for spending effort on other priorities. Individuals stop helping each other, quality drops, and the team’s capacity to innovate collapses. Without change, stress builds and is released as conflict leading to loss of trust and at its extreme – loss of individuals from the team. Each person on the team has become their own silo, completed work is thrown over the wall to the next person without thought as to how it will be received. A push culture has now developed. So pervasive is this pressure that even social interaction outside of project work has become difficult to cultivate across the floor.

 

Pesticides for Developers

As an Agile coach, concerned teammate, or organizational leader, what can you do? With an unreceptive team, you will need to make bold decisions.

In my context, my decision was to do nothing… At least not immediately and definitely not directly. When working with people unreceptive to your methods, you can do a lot of damage to trust if you try to force your way of thinking on them. Drastically changing my methods and angle of approach was required, or I would risk losing the opportunity to make real change. My new approach is to host practical workshops, subtly related to the issues the team is experiencing.

My goal through the use of practical workshops will make the silos more real for the teams, and luckily, we already know it’s easier to identify and understand the dangers of real silos.

. “I honestly hate popcorn”.