I’ve often been involved with defining processes for teams to work together. Some organisations want a standard process for all teams—that every event (or “ceremony”) is agreed, producing standard documents and other artefacts on the same cadence. Mostly this is in very large organisations, and I can’t help feeling much of the motivation is a strong need for a feeling of control.
Other organisations—particularly smaller ones—are much more relaxed about standardising processes.
But as these smaller organisations grow there are hiccups, and some standardisation seems important. How far or deep should that go?
For me, and most people I speak to, the purpose is to agree on the interfaces—the points where teams cross over. People must be able to rely on receiving things from other teams that they can rely on, but setting rules beyond that seems excessive.
For example, teams may need to provide certain agreed metrics that can be aggregated to produce a single dashboard, or provide reports that fit a standard format so they can all be viewed together, or attend at a certain regular meeting referring to common concepts and using commonly-agreed language.
And—the understanding goes—anything within the teams is entirely up to the teams themselves. Examples might be when they hold their stand-up meetings, how they write their user stories, whether and how they estimate those stories, and so on.
But there is one apparently team-specific activity that should not be a free choice: their choice of technologies.
Superficially this is nobody else’s business—particularly in a smaller company. Theoretically, if a team builds and runs their (sub)system, and it works well and interfaces reliably, then no-one else should care what’s going on under the hood.
But eventually it will matter—perhaps not today, but one day.
One major reason is that teams don’t last forever, and teams’ remits can’t be guaranteed to remain unchanged. Eventually a team will need to disband, or need to focus on a different topic, or people will just have to move, and the team’s technology will need to be embraced by others. A technology needs to be potentially owned by any other team. It is unfair on that other team to suddenly have to learn entirely new skills. The resulting slowdown and lack of expertise is also bad for the organisation.
I once worked with a small organisation where one team chose a different database to what was, until then, the norm. They thought it was their choice, and no-one else’s. The team didn’t disband while I was there, but their boundaries were more porous then they expected. Because the team was small, and because demands on them were significant, it was often important for people from other teams to help out—perhaps to help make a release, or to debug an issue. Sometimes those people from other teams needed to trace an error they were seeing back to the first team’s code. In all cases it was very frustrating for the people in those other teams. They couldn’t fix problems easily, releases were very difficult, and they resented the decision of the original team as rather selfish. The original technical decision might have been good for the team, but it was bad for the organisation.
It is important for teams to have some freedom in the way they work, but technology tends to last longer than the teams—and people—that introduce it. So there needs to be common agreement about what those technology choices should be.
niksilver.com 