Trust Is A Must

We all know that Agile is as buzzword-ridden as anything else that helps people generate an income. There are a lot of gems among the buzzwords associated with agile ways of working though but a lot of the time we tend to take them at face value and not look at where and how they fit in. I’ve been looking at some agile practices and tried to reason around the relationships between them and one of the things I realized was how essential Trust is in order for most of the other practices to work. You can fake a lot of things but if Trust is not truly there so many of the other things we try to do will not only fail, they might also make things worse.

One practice that has always been at the essence of agile is Transparency; we want everyone involved to have current and correct information. Adding a window to a solid brick wall won’t offer any Transparency though. We can’t buy Transparency in the form of a whiteboard. Worst case scenario, the whiteboard only serves as giving credibility to lies, useless data and wishful thinking. Transparency needs to be combined with, among other things, Trust and Autonomy to provide value. The “Transparency” offered when Trust is lacking will never be true Transparency. It will be a display of what the team believes that people around them want to see. It will be fidgeted numbers such as story point inflation, velocity boosting with “almost-done” stories and smokescreens hiding work performed under the radar. In short, any “Transparency” offered when we don’t have Trust or we suspect that we’re not Trusted will be a pile of lies.

So if we add Trust, will that transform Transparency to a valuable practice? I’d say no. Not unless we also add Autonomy to the equation. A team that is not Autonomous will always have dependencies to people and teams outside the own team in order to deliver any business value. When all a team can deliver are small parts without intrinsic value, the data that come out is mostly worthless. No true progress can be shown, only task completion. In any cases but the truly basic ones, task completion won’t give us much information regarding how close we are to realizing any true value. The complexity of what we do will hide a plethora of new challenges behind every completed task. Challenges that only surface towards what we thought would be the end, when we put everything together. In a similar way if we have an Autonomous team that lack Trust and/or Transparency, they are potentially a true danger to the organization. If they act without Trust, it will be a high stakes lottery ticket where there might be a brilliant idea in the jackpot but more likely the team will be a liability that acts without any information sharing with the rest of the company. Adding Trust could be a way to better the odds of something good coming out but without Transparency it will not be aligned with the rest of the company and its strategies.

Before adopting the next good practice, see where it fits in your context. Look for the untold prerequisites for the practice and consider if you fulfill them. Do you have the necessary mutual trust in your organization? And remember that trust ISN’T earned; it has to be offered in advance because people WILL act according to the expectations that are offered to them.

Caught in the metaphorical trap

Did you see what I just did there, in the header? I created a metaphor. Do you envision me as caught in a bear trap right now? Probably not if you’re an adult capable of abstract thinking. In fact, if anyone interprets my header to imply anything else then a possibly improductive side of metaphors, then my metaphor itself was improductive.

 “Life is like a box of chocolates” according to Tom Hank’s character Forrest Gump (from the movie with the same name). However, I’d like to disagree with Forrest on this one; life is not at all like a box of chocolates … except maybe from one certain aspect – “You never now what you’re gonna get”. Oh, he said that too did he? Well, that would make the first statement somewhat useful but please don’t ever use it standalone if your life is not sweet, brown, sticky and delivered in a cardboard box.

Metaphors can sometimes be useful when you’re trying to explain a complex concept or when you want to be poetical about something. Comparing fractals to coastlines is a useful metaphor. Judith Moffetts translation of Karlfeldts poem “Winter Organ” contains several beautiful metaphors, e.g. when describing icicles:
“… On frosty evenings a silver arcade,
A glittering row of pipes, is made …”

Metaphors can also be bad and even harmful when applied in the wrong context or when people try to interpret them too literally. Godwin’s Law predicts with scary precision how metaphors and analogies can, and will be used in the wrong place. Most arguments in forum threads show no similarities whatsoever with Hitler and Nazis but yet we get to see the comparison again and again.

In the world of software development, we’ve been living with the house building metaphor for as long as I can remember and probably long before that. This is an example of a metaphor taken way too far. There might (in some cases) be certain aspects of software creation that resembles certain aspects of building a house, but when people try to fit other aspects of either side of the metaphor into the interpretation we end up with a horrible combination of code, hammers, foundation, architecture, languages, mortar and design. This is not a useful metaphor at all anymore. I’ve seen better and worse attempts at trying to get this to work but the heritage has rendered the metaphor completely useless and I hope that I never have to hear anyone use it again. I do think that we should continue to look at the world around us to find new patterns and similarities in order to learn from other fields but I don’t think that I want to hear another “creating software is like …” because most likely it isn’t.

Just one more for the road; creating software IS like a box of chocolates, you never know what you’re gonna get. At least not if you’re doing it right and have a willingness to learn along the way.