Agile: Walls Dysfunction & People

A comment made at the recent GRTesters meetup meeting left me with a hard choice. I could jump on that and lead us further down a rabbit hole we were already in, and well off the topic of the evening, or I could make a note to myself and revisit my thoughts later.

This is "later."

We were discussing team dynamics in a macro sense - how teams function, the interactions between team members, how they interacted with other teams and the like. Specifically, we were looking, briefly, at the difference in relationship between software testing specialists who were embedded with development & delivery teams and who were in external teams.

The apparently "classic" case of "OK, our code is done, now we give it to the test team."

The problem is, by pulling testing specialists farther away from collaboration with the people specializing in creating and writing the production facing code, the testing specialists become "others" - not part of the actual development team.

The idea of pulling people into a team and having them work together is great. If you allow for teams to build trust and get to work together.

So there we were, talking about teams and silos and how divisions between teams can lead to huge dysfunction for the organization. Then one person said, "I've seen these kinds of problems everywhere. But if you really want to see huge problems with silos and Us vs Them, look at how most companies do 'Agile.' Teams don't cooperate with each other. Teams don't help each other. Teams barely talk to each other."

Most of us stopped and blinked. I had some thoughts on that, particularly as he had just described what I had seen at many organizations.

To Begin

First, some considerations on Scrum and Agile.

While there are certainly proponents of both who will be happy to tell you that delivery will be faster and quality will be better, I am not certain these are universal guarantees. I know this flies in the face of the statements and pitches made by sales people of "Agile" and Scrum and various certification programs.

What I tell people, much to the chagrin of certain "leaders" is that Scrum will almost certainly identify problem areas very quickly.

You will get very fast "returns." These returns may not be what you expected.

For example, if you have an organization with many development teams. Randomly relabeling them as "Scrum Teams" is rather counter to the point of Scrum, and certainly counter tothe Agile Manifesto itself.

Then, targeting a poorly functioning team as the Proof of Concept group, as many organizations do I have seen, might not give the shining results hoped for.

A team that is troubled in delivery, with low quality product, might not be the ideal group to "demonstrate" the benefits of "Agile." Likely it will be a trainwreck. This trainwreck, as happened with early steam trains, can put people in other teams and other parts of the organization completely off the "new" concept.

The problems are not in Agile or Scrum - or any other method or framework associated with Agile. The problems exist in themselves. Using a team with problems as the prototype simply highlights the problems the team already has.

 Did "Agile" Cause This?

No. Not at all.

The "transition" to Agile - any type, form or flavor - simply exposed this issue. The problems existed. People working with the team, oftentimes people ON the team, are fully aware of the problems.

The team lead or manager might be aware. They may be working to make it better. They might be trying to address the problem.However, if the issue is chronic and sustained, there is a strong likelihood they will not improve things.

Why?

The largest single problem in any organization is not the technology. It is not the tech stack. It is not the language used for development or testing. It is not the development models and methodologies in use.

The largest single problem, is People.

Gerry Weinberg wrote (and said) "No matter how it looks at first, it's always a people problem." (Find that in Secrets of Consulting, 1985.)

What does that have to do with this situation? Loads.

The team lead or manager might BE the problem. OR, there might be a person (or two) who are engaging in damaging, if not destructive, behavior.

The Problem?

There are loads of other possibilities. The issue might not be with people on the team. If people on other teams have "issues" with people on the troubles team, a wee bit of animosity can go a long way. This can point to broader issues within the organization.

My favorite issue, still a "people problem" is Byzantine processes and methodologies around software. Everything from multiple levels of approvals before software can be moved from one environment to another to mandated control measures to "protect" the production environment.

The less clear the process to be followed, the greater the odds of dysfunction. 

These exist whether the organization is "Agile" or not. A mandated decision to "do Agile" might just make these problems more obvious - the light can be shown on them and make them clear.

The Response?

This varies. Often times we see this as a "Fragile" implementation. People (that word again) focus on the forms, ceremonies and rituals around Agile and not on the purpose.

Many, many organizations ignore the Principles behind the Agile Manifesto and focus only on these rituals. The problems are not addressed. The challenges remain.

Except, now they get blamed on "Agile."