Trust Is A Must

December 23, 2016

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.

trust-is-a-must-iiOne 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.

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.

If you set deadlines for other people, you better have very good and thought through reasons for doing so. You will not get many chances to blow this until it starts to backfire and you get caught in a vicious circle where you’ll have to set your deadlines farther and farther into the future and they’ll get less and less respect.

If you hand me a task with a deadline I will assume that this is important to you and prioritize the task. But if you don’t start using the result of my work until a week after the deadline, then we have a problem. I can see three reasons for this happening and none of them makes me any happier.

1. You didn’t trust me to get the work done on time and you built in some slack. Well, from now on I don’t trust you to trust me so I will be using this slack whether it’s there or not.

2. You just put an arbitrary deadline on the task in order to get it off your desk. This would mean that you value your own time much higher than mine. I’m sorry but I’ll have to disagree with you on this one, I find my own time quite valuable and I won’t be spending it on your arbitrary deadlines in the future.

3. Your priorities changed since you gave me the task and you didn’t tell me about it. Well, if you hand me low prioritized tasks I’m sure not going to give your items high priority in the future. As with #2 this is a problem of you not valuing my time.

You see how this behaviour drives me to not meet your deadlines in the future and how my behaviour will drive you to set even higher priority and more arbitrary deadlines far off into the future on even the most mundane tasks in order to get my attention. So don’t be afraid to hand me work with deadlines as long as I see you working on my output the minute after I’ve handed it to you. If you intend to shove my output at the bottom of your own TODO-pile, then you SHOULD be afraid. Be VERY afraid, because the Reinforcing Loop is out to bite you in the stern.

Intentional communication

April 19, 2010

Lately I’ve seen several discussions about the senders responsibility to transmit information correctly. The responsibilities range from a correct choice of words to being explicit and not assuming that the implicit will be seen or heard. What you say and how you say it are definitely corner stones of succesful communication. However, I would also argue that the receiver of the information has the same obligations; to raise the abstraction level when interpreting the information in order to put everything into context and also to not try to read additional information where there is none.

Transferring of information needs to be built on a contract between sender and receiver, a contract stating that both parties will try to make the transfer as correct as possible. If we don’t have the intention of understanding each other correctly, there will always be misunderstandings. I’ve seen countless discussions where the parties refuse to look at the subject from the other side and thus intentionally misread what is being said or written. If the conversation lacks intention of understanding, there is no use in proceeding since there will always be ways to misunderstand by straw man arguments, cherry picking etc.

A good intention is not enough to guarantee a correct transfer though. We must always reflect on the information being sent and its intended purpose. Are we transferring some undisputable facts? Asking a simple question? Arguing a case? Covering our own backs? Do we want someone else to actually receive the information or do we just want them to know that we have sent it? If there’s no ambiguity in the purpose, then there will be less reason to extrapolate the information outside what has actually been sent.

So if both the sender and the receiver have the intention of making the transfer successful and we have an explicit intention with our communication, then we actually might get the result that we intended.

… Unless you’re broadcasting or otherwise pushing unsolicited information (like I’m doing with this blog), in those cases the responsibility lies entirely on the sender. So feel free to misinterpret my posts.

But in order to improve OUR communication, I hereby set up an open contract where I promise to do my best to learn from any comments posted here. I will try to see things from your perspective and if anything feels funky, I will ask for clarification or give you the benefit of the rule of six.

%d bloggers like this: