Test Driven ?

TDD is a practice that I have found great success with. I have found that I became proficient in it, the name changed its meaning.

TL; DR

TDD like any skill requires time to learn and master. The meaning of the last ‘D’ in the abbreviation changes as does your mastery. As the practice becomes increasingly rote, TDD starts to become less about development and more about design.

Setup

It drives me crazy when I hear someone say “TDD is easy”. For me TDD was anything but easy. In fact, it is still easier for me to revert to coding without tests, even though I have been doing nearly everything test driven for the last 10 years.

It took me 2 years to get the hang of TDD, and 3 more to feel like I started to master it. During this time, I noticed a profound difference in my code. I spent less and less time trying to figure out what my design was. It emerged and coalesced on its own. … Well not exactly on its own.

Development

When I started, I would think about what I wanted the design to be, and write the test to prove out that design. This lead me down quite a few rabbit holes and wrong decisions. The good news was it allowed me to get better at refactoring.

As I started to get proficient in writing tests, my decisions became cleaner. My code never did, but my thought process cleared up. I would stop, and think about my tests. What does the next test highlight. What part of my design is not yet implemented. (And yes, I still got surprised when things turned out never needing to be implemented.) Here the tests were driving the development of my design. I was doing Test Driven Development.

Design

As I became even better at writing tests, I found that the questions I was asking were laborious and time consuming. I simplified them to 2 questions.

  1. Is this the API I want?
  2. What expectation is not met?

I found then that as I wrote the test to satisfy these 2 questions the design would emerge. Now a fundamental change had occurred. I was using the tests to drive my design.

 

Now a fundamental change had occurred. I was using the tests to drive my design. Click To Tweet

Greatness

I have been thinking about great teams and teamwork lately. Greatness is not something easily attained or held, but easily lost.

What does it take to be part of a great team? Click To Tweet

TL; DR

Greatness slips from our fingers at every moment, we must actively pursue it and not compromise for less. We must strive to ensure all voices are heard, that quality is maintained, and room to experiment is held. Anything less defeats greatness.

Acceptance

To ensure a great team, there must be an agreement of acceptance. All proposals must be met with a “yes and…” mentality. People’s views, emotions, concerns, and ideas need to be welcomed. Without this welcoming safety is destroyed.

Without that safety new ideas are killed before voiced. Trust degrades, and people fall into old habits. Greatness is lost, because innovation stagnates.

Acceptance can be achieved as long a few people are willing to champion it.

Uncomfortableness

The feeling of being uncomfortable signals the greatest chance for improvement. When the team “leans into” uncomfort and addresses the smallest things trust and acceptance grow. It is true that you need a seed of acceptance before this can happen; however, facing the feeling of being uncomfortable grows acceptance beyond its normal bounds.

Facing uncomfort, is very tenuous. Where acceptance can grow with a few champions, the ability to face things that make us uncomfortable can crumble with one criticism. This must be protected, and defended or the things that erode trust will remain hidden.

The most powerful and useful conversations happen when we solve real problems. If we cannot bring up those problems greatness dies.

Excellence

Once we have acceptance and the ability to face what makes us uncomfortable, then we need excellence. Excellence is the constant striving to do better than we are currently. This includes technical excellence, process excellence, teamwork excellence, and communication excellence; along with many other forms of excellence.

Excellence ensures quality of what we do, and constant improvement. It allows for us to make mistakes and learn. It allows us to revisit and revise old decisions. Excellence measures greatness, but by paradox excellence cannot be accomplished without the other things I mention here.

Experimentation

We don’t know how to improve, even if we do, the context will change. We cannot achieve excellence without the ability to experiment. The ability to make a judgement and be wrong.

Experimentation feels natural on the tongue, but we tend to subtly resist it. To be an experiment, four things must be true.

  1. There must be a possibility that the hypothesis is wrong.
  2. There must be a defined end for the experiment.
  3. Success and fail criteria must be known.
  4. The actions of the experiment must be defined.

In Short

Who does not want to be part of a great team? Greatness is simple to achieve but in no way easy. It requires acceptance of all ideas, the ability to face all uncomfortableness, a strive for excellence and continual improvement, and a willingness to experiment.

Greatness is simple to achieve but in no way easy. Click To Tweet

Without all these things, we cannot be great. With them we will always be traveling toward greatness.

A healing work environment

A healthy work environment means a healing work environment. Click To Tweet

TL; DR

To be healthy, a work environment needs to be a place of healing, not only a place where no further harm is done. Healing is not always easy or comfortable, but always rewarding. We should build a place of healing and reap the rewards.

Healthy

What does it mean to have healthy work place?

I think we first must ask what does it mean to be healthy.

Healthy: (Merriam-Webster)

  1. Free from disease or pain
  2. Showing physical, mental, or emotional well-being
  3. Beneficial to one’s physical mental, or emotional state

Healing

Each of these definitions show a common thread. Health is a good state, or the absence of a bad state.

So, what does it mean to have a healthy work environment?

A healthy place promotes health.

On the surface, it means to have a work pace that is in a good state or very least without a bad state. This definition is simple and compact. There is a lot of meaning behind it that is easy to gloss over. I want to unpack it slightly.

To be healthy you must be free of disease or pain. If you have disease or pain you must first heal to be healthy. A healthy environment encourages your healing. That means a healthy job will encourage you to heal.

To be healthy you will show physical, mental, or emotional well-being. A healthy work place will promote those signs of health. It will be a place where a person can grow in one or more of each of these healthy states. The more growth possible the healthier a place is.

To be healthy something must be beneficial to one’s physical, mental, or emotional state. This is really what I have been driving at. Beneficial is not just doing no harm, it is allowing for improvement. It is helpful.

When we think of a “Healthy Work Place” we should think of something bigger than simply a place where no harm is done. We should strive for a place where people can heal from past hurts, and improve the quality of their life.

Uncomfortable

However, healing past injuries is not comfortable. The worse the injury the more invasive healing can feel. People can be sore, and irritable. People can have trust issues that can degrade communication. Fear can cause people to see past wrongs in healthy and helpful actions.

For a work place to be a place of healing, not only does the company need to embrace it, so do the employees that are undergoing healing. This is scary, tiring, sometimes painful, but worth it.

I have worked in these environments. Whenever I do, I learn more about myself, and my work than in any other circumstances.

Thoughts

During our working lives, we will spend 24% of those lives at work (approximately 37% of our waking lives); assuming no overtime. We should strive to make that more then something we do to survive. We should strive to build environments where others heal; where we heal if we need to.

Making a safe place to work

Thanks

This post is a special thank you to @JoshuaKerievsky. First I do not work with Joshua, or am I associated with him, however he has inspired a large amount of good things within my team.

Safety is a Skill

Bringing safty to the place I work is one of my highest priorities. Now to be fair, my place to work is the most safe place to work I can imagine. So why do I focus on bringing safety to my work?

Safety is a skill. It is why all manufacturing companies have manditory safety training. But these trainings only cover one type of safety.

Phycological Safety

Google discovered that phycological safety is the key to a well functioning team. We have seen simular successes in our team well before this article was written.

Core Rules

My team’s core rules have been in place for almost 4 years (as of September 2016). They focus on building phycological safety. They are:

  1. Treat everyone with Kindness
  2. Treat everyone with Consideration
  3. Treat everyone with Respect

The first thing to notice is the word everyone. This is not just those you work with. It is not just the people within your department, company or developer community. It says everyone, and it means everyone. It also means that everyone you work with will do the same.

The Cards

I won a raffle held by Industrial Logic, Joshua’s company. The prize came with a small number of these cards:

The back states you have the autority to stop work if any of these things are at risk:

  1. Time
  2. Information
  3. Reputation
  4. Money
  5. Health
  6. Relationships

I instantly fell in love. I gave each member of my deportement one of the cards. I made discussing the cards part of the on boarding process. At the end of which I gave the new hire the card.

On Boarding with Safety

I inform every employee that they have great authority when they come to work here. They can stop work if they feel the any action anouther is taking threatens any of those things. I then express how our practices, Test Driven Development, Contiuous Integration, Mob Programming, and others help to protect these things.

The new hire now has the authority to stop our work if anyone violates these practices and the reason isn’t to experiment on a better way; and even if that is the reason.

Then I tell them the hard part of this authority. They do not only have the authority, but the responsibility. It is part of the job requirement that they do this. Ignoring these hazards is willfully not doing your job.

One of the best moments of my career was when I told this to our interns. They could not believe any company would give them such resposibility and power.

Part of our culture

A number of us have attached the card to our badges, as a reminder of how important this really is. We retrospect often and try to do things that promote this safety. I think we are better then any company I have ever heard of it this regard. However, I do not believe we are perfect or finnished. The company recognizes that this safety has obviously contributed to our success and we are dedicated to finding better ways to achieve it or grow it.

The problem with the #NoEstimates Debate

The problem with the #NoEstimates debate is that both sides are not arguing the same thing and therefore the debate focuses on invalid points. The #NoEstimates hash tag has almost nothing to do with estimates, despite the focus the debates have. What is really being discussed is fundamental ways of doing business.  The pro #NoEstimates group is talking about a fundamental shift in how business is being done. We are talking about regulating and controlling price of software in a very different way.

Without changing, in entirety, the way in which business is done then a lot of the concerns the anti-#NoEstimates group bring up are valid. However, we are talking about a fundamentally different way of doing business.

The basic tenant of #NoEstimates is to change the way that decisions are made. We start with the assumption that the market is moving faster than we can. If this is true, then anything that delays getting a product to market has a huge cost associated with it. This cost is measured in employee hours, loss of customer faith, and competition gaining market shares before us.

The second tenant is that we are going to make mistakes. We are human, and therefore it is impossible to be correct all the time. If we are going to make mistakes, then let’s minimize those mistakes. We want to release small pieces of functionality often so that we can get feedback quickly. We can use this feedback to find mistakes before they are big and costly.

The third tenant is that the market will move with the introduction of product. Once the customer gets any functionality that is useful to them, that functionality will change what they want from future functionality. We have to be able to sense and move with that change.

This brings us full circle. The market is going to change faster than we can.

#NoEstimates is a way of doing business that attempts to accept these three tenants, while ethically helping companies navigate the new landscape of business. We do this by making business decisions in real-time and trying experiments in the marketplace to determine real value. We make decisions based on evidence instead of estimates.

A Better Interview

As interviewing is the first impression a company has of a candidate and the first impression a candidate has of the company, it is important to get right. My goal with this article is to start an open discussion about interviewing and how we can improve it. As a community we need feedback, debate and understanding to create something better. The place I work currently has the best interview process I have ever seen in my 17 plus years in this field. By examining what they do and why, the discussion can open with a solid foundation. We can build upon this to achieve something greater.

Where do we Start

The Hunter Software Development Group is built off of three core rules, and those rules permeate everything we do, including the interview process:

  1. Show everyone kindness.
  2. Show everyone consideration.
  3. Show everyone respect.

These are our foundations upon which we build everything. We believe every facet of an interview process should be executed with these in mind.

Our Objectives

When you consider kindness, consideration and respect as the foundation for an interview, your goals change shape. Yes, you need to know if the candidate is right for the job, but how you determine that changes subtly as your focus changes.

There are three conditions for an interview being considered successful:

  1. The candidate leaves feeling fairly assessed.
  2. We know if the candidate will be a good fit for the team and company.
  3. The candidate knows if the team and company is a good fit for them.

Achieving those Objectives

Each objective is achieved through very intentional means. We examine our process after every interview. We look for any place where the process can be polished, or someone can be better trained. We focus on each objective to better our process and make the interview successful for both the candidate and the company.

The candidate leaves feeling fairly assessed.

It is difficult to judge the capabilities of an individual within a small time frame. It is harder to do that in a way that feels fair and just. We try our best to accomplish this goal by tackling the idea from a number of sides. In order to talk about how a candidate is assessed, it is important to know what they are assessed for.

The traits that we are trying to assess are:

  1. How much emotional intelligence has the candidate acquired so far?
  2. What unique technical background and skills does the candidate bring?
  3. What part of programming does the candidate shine in?
  4. How much does the candidate know about Extreme Programming?

The first thing that happens is the candidate is given an explanation of the interview process. They are told what will happen, what they are evaluated on and why. It is important to eliminate surprise wherever possible. We believe this level of transparency is essential to the accomplishing our three goals.

Once the interview has been explained, there are a number of programming problems that the candidate is asked to work through. Each problem is straightforward with no obscure programming knowledge required. There are no riddles or surprises. Each exercise allows candidates to demonstrate a host of different skills as they work toward different solutions.

As they work through the problems, they have the opportunity to be given help and advice by three to four programmers that have been designated as their team. The team will not give solutions, instead they will help with programming language knowledge and design advice. The team will also rotate into the interview, giving the candidate a chance to navigate, teach, and guide various people with different skill sets.

There is a proctor, a person who takes lead on the interview. The proctor works as a guide for the candidate, helping keep them on target, and moving smoothly through each problem. It is the proctor’s responsibility to ensure the candidate understands what is happening throughout the interview.

Lastly, the candidate is not expected to solve the problems. In most cases it is not possible to finish in the allotted time. The purpose of the exercises is not the solution, but the path taken. We are not focused on what the candidate does not know, but rather the unique experiences and strengths the candidate brings forward.

We know if the candidate will be a good fit for the team.

There is a lot to consider and understand when talking about team fit. The Hunter Software Development Group works very differently than any place I have ever worked. We use a practice called “Mob Programming” to do all of our daily tasks. This means that all production code is written in a highly collaborative environment.

The factors that are key for our work environment are:

  1. Can the candidate communicate collaboratively?
  2. How does the candidate research new information?
  3. Do they demonstrate kindness, consideration, and respect?

Being part of a collaborative team is essential for anyone working in a Mob Programming format. Candidates will be asked explain how to solve problems and sometimes navigate a member of their team through the process of solving a problem. This means that one of their team sits at the keyboard and the candidate is asked to tell the teammate what to do. The disconnect from the keyboard forces some form of communication between the team and the candidate. Each of the team members is at a different skill level for different sets of skills. Inevitably, the candidates will either guide someone that is currently more skilled than they are or a teammate who is less skilled than they are. The way the candidate handles these two situations provides invaluable insight into that person’s communication style. It is important that the candidate shows kindness, consideration and respect during the whole process.

The processes of our everyday work environment puts highly collaborative teams into situations where they are acquiring new knowledge, usually as a result of having no foundational knowledge. The problems that the candidates are presented with are straightforward as for as core knowledge but ask questions that the candidate may not be familiar with. We look forward to web searches, text messages and anything else the candidate can use.

The candidate knows if the team/company is a good fit for them.

Letting someone know who you are is complicated process that can easily take the entire time of the interview. So how do you let someone know who you are within a couple of hours and still accomplish the other goals of the interview? This is one of the hardest questions we try to answer during our interview. We start by holding the interview in our open work environment. The candidate can just look around and see how other teams are working. They can hear the discussions, and see the excitement. A few feet away a team is working to solve problems and tackling goals.

Our interview process is part of our work. It is collaborative and social, designed to mimic the best parts of our work while still being an interview. Teammates take turns typing, helping, and guiding during the process, all of this helps give a feeling of what to expect.

If the candidate seems to be a good fit skill-wise, we then continue to a Lean Coffee session that lasts 45 minutes to an hour. This changes how the Q&A process for interviews goes as it starts by putting all questions and topics up front for all to see. Even if all topics are not discussed, the candidate and the team can see what was on each other’s mind.

A Lean Coffee format gives the candidate the chance in participating in the selection of questions and topics. Each person participating in the interview has three dots to vote on topics. These topics are then organized by number of votes. The topics with the most interest are then discussed first.

This gives the candidate a lot of agency in guiding the discussion. Their voice gets heard and they get a chance to have their questions addressed. It also allows them to focus on topics from the interviewer that they feel will make them sound better.

Each topic is given a five-minute window to be discussed. When the time is over, everyone votes on continuing or moving on. If even one person wishes to continue then the topic is continued, but only for two minutes. Then the voting cycle continues until everyone is done with the topic.

Each topic discussed is a topic not a question. Everyone is encouraged to reflect on the topic and address what it means for them. For instance, if the topic given by one of the interviewers is, “Describe a moment when you felt you really shined,” all members of the interview are encouraged to answer, not just the candidate.

This also means that topics brought up by the candidate will not only be addressed by the interviewers, but also by the candidate.

These discussions are the best way that we have found to truthfully let the candidate know who we are, what we do and why we do it.

In Summary

The Hunter Software Development Group has a very different approach to interviewing born out of a different perspective. We start with a foundation of kindness, consideration and respect and build from there.

We work to fairly assess the candidate based off of four types of skills. Emotional intelligence, unique experiences, what makes the candidate shine and what they know about Extreme Programming.

These methods have been very successful for us when hiring. We retrospect and adapt after every interview, so we are always improving. However, I would like to be part of a larger conversation. By discussing this with other professionals the community as a whole can gain insight from each other’s experiences that might not be seen any other way. Maybe the whole of the industry can improve and find yet to be discovered better ways. Mob Programming has led to better code quality. If we all huddle up and analyze how we interview who knows what will happen?

Intentionally Exceptional

“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.” – Steve Jobs

Every process, person, or thing that is exceptional became that way through lots of hard work and intention. When we talk about best practices, and management processes we as an industry seem to leave that part out. It is easy to talk about what “magic” successes have been had, but hard to describe the sometimes grueling process and reasoning that made the magic happen. I believe this is related to Survivorship bias which is a cognitive bias where we tend to focus on successes rather than failures.

Understanding that as we share our successes, it is important to also share the decisions and hard work that went into the creation of those successes, is the first step. By sharing information about the work that the success was built upon lets others examine its context, and gives hopes to those currently struggling.

That does not communicate the power of intention behind the success.

Why I believe in #NoEstimates

Before I start, as I will be talking about different work experiences, I need to state all my opinions are my own. They do not represent the opinions of my current or past employers.

That being said now let me begin.

What:

When I was first introduced to the concept of #NoEstimates I was a mid-level developer and thought that it was a wacky idea that could never work. Later, still a mid-level developer, I decided that working with estimates was stupid. Then I grew up and learned that the world was not black and white. I listened to what @WoodyZuill had to say and tried to understand the meaning.

Experimentation:

My first experiences with trying #NoEstimates had nothing to do with Woody. I worked in a small company that hired me to take over a legacy VB.Net v1 project which had failed so badly they fired the whole team. They had no source control despite having 13 versions of the application deployed, and only one copy of official source code that didn’t match any of the deployed versions. I hired a new team, we focused on bug fixes that were discreet, understandable and easily repeatable.

We gave no promises and made #NoEstimates. We focused on discovering value, by giving users fixes to things that were easily understandable. Within 3 months not only did we have source control, but we managed to reduce the number of variant applications and we were deploying every week. We had moved beyond bug fixes.

We were so successful, that the company sold in under 2 years. The CEO was able to retire, based on the value we delivered. We did this entirely without estimates.

Tutelage:

Later, I got to experience #NoEstimates in a completely different way. The team I was part of worked on custom line of business applications. We often produced software for different departments within the company. Here we focused on changing discussions that were given to us. We always asked: what is one thing that if we gave it to you now would make your life better? Then we tried to understand that enough to figure out something that is discrete, understandable and has a clear definition.

Once we did that, we would work to deliver it. Once it was delivered, we would follow up with the users to see that it met their need. If it didn’t we changed it. When the need was met correctly, we were told what the next need was.

That is how we worked. The company never had worry about interrupting us, because our deliverables ended up taking less than a couple of days on average. This was not a precondition, or intentional. It happened because of how we isolated something to work on. Occasionally it would take significantly longer. That was ok also because it meant that there were more unknowns in that piece.

 

So What:

#NoEstimates as I have witnessed it accomplishes two things. The first is it moves authority to make business decisions to the current point in time. By delaying the act of what has priority, to the last responsible minute the business is better able to cope with business as it is.

The second benefit is that it places business decisions in the hands of those who have the knowledge to make the decision. I always say that programmers are business people who have not been correctly trained in business. I say that because every line of code is a decision about how the company does business. By focusing on discrete deliverable chunks and using those chunks to measure value/need, a lot more of the decision of what goes into the application goes to those who are responsible for the business.

 

Now What:

#NoEstimates is the beginning, not the answer. There is a lot more exploration that can happen out there. Let’s focus on improving how we do business, and share our successes and failures. Eventually we will always find better.

Toxicity is Abuse

Why I am writing this

This weekend I got into a lot of discussions about the responsibilities of a programmer.  I heard multiple times that a programmer cannot be held responsible if they are working in an environment that is toxic and forces bad behavior. While I do not advocate that someone threaten their ability to feed, clothe, or house themselves (or family) because of some theoretical responsibility, it is imperative to get out of a toxic environment.

This weekend I was in a conversation about a consultant that was described as abusive by the other employees and someone said: “They only fear for their jobs because they are too stupid to do the job right.” In other words, they deserved to be abused.

In another conversation, I mentioned that a programmer has a responsibility to do what is right. I was told that this was a pipe dream because of the toxicity of work environments. To me this translates as, “Offices can treat you any way they want because you are worthless.”

The funny thing is I have heard these statements before.

My mom married an advertising executive when I was 8. It turns out that he was a drug user who slowly revealed his nasty temper. I was often backhanded hard enough to knock me from my feet, and I got to watch as the same thing happened to my mom.

I heard the whispers of neighbors and even friends.

They sounded a lot like how I now hear people talk about toxic work environments. The words are slightly different but the meanings are the same. The fault lies on the victims. If they are being abused, then they deserve it.

It takes more courage, stamina and risk to stand up to an abusive person or organization than most people know. That chapter, in the end, was a small chapter of my life. My mom left that man one night and never looked back.

When we speak down on those being abused or make excuses for the abuse we make it even harder to do what is right. I implore you to stop this destructive behavior. Instead of making excuses for toxic companies, let’s do something about them.

Your responsibility

Every software developer has some professional responsibilities, even when we are unable to perform them. These responsibilities include:

  • We have a responsibility to produce bug free code.
  • We have a responsibility to produce code that is inexpensive to maintain.
  • We have a responsibility to produce value that is greater than our cost.
  • We have a responsibility to help those starting in the profession to be better at what they do.
  • We have a responsibility to share what we learn to progress the industry.
  • We have a responsibility to understand our customer’s, company’s or client’s business well enough to make informed business decisions about the software we write.
  • We have a responsibility to say ‘No’ to our employers if we are asked to do something that endangers time, profit, relations, information, reputation or money of an individual, company, community or ourselves.
  • We have a responsibility to provide value well above our cost.
  • [UPDATED] We have the responsibility to support those in a toxic work environment find a better one.

Doing that will cost me my job!

If you are in an abusive relationship with your employer, one or more of those responsibilities become impossible to execute without being fired. That is a tough and scary place to be. I am not saying for you to risk your job, and risk being homeless.

What I am saying is that you do have a responsibility to leave. Don’t quit your job without a new one. Look for help within the community.

Then share what you learn. Help the community understand what you did to find a good place to work. This will give hope to those who are in similar situations.

We need to use economic power to stop abuse.

These abuses are not illegal. They are immoral, but that does not give us any legal ground to prevent them.

Companies need to make at least 3x their operating costs to be successful. That means that a company sees at least 3x profit from your pay. YOU ARE WORTH A LOT MORE THAN YOU ARE BEING PAID! We have value. In today’s economy custom software makes and breaks a company.

If a toxic company could not keep their employees or better yet not be able to hire then they will not be able to compete against non-toxic companies. The problem now is that programmers stay in toxic situations. This allows toxic companies to compete.

Let’s stop this. Leave those companies. Leave them as soon as you realize they are toxic. Abandon them, and move to companies that are doing it correctly.

[UPDATED]

Moreover, remember it is not the fault of those being abused that they are abused. It is the fault of the abusers. Show compassion to those in need. Help them move to somewhere that will appreciate them. Help people recognize abusive bosses, coworkers and companies before they are in the position to be abused. Recognize that even with warning circumstances might necessitate they go anyway. Be prepared to help them.

Transformational Communication

Intro:

I recently came across a framework for discussing and categorizing the types of messages we see. I present it here to help analyze the way that the community talks about Agile. The hope is that through analysis we can improve the way we deliver our message.

I will give you the framework for analyzing our delivery that I learned. I will explain what it means when a message is hard to understand, or compromised. The hope is by seeing similarities in what we are putting out into the world the community can better self-adjust.

When I say community I include myself. I have been and am guilty of violating the rules set forth by this framework. I am no better than anyone else. In writing this blog, I have had to swallow a large pill and make the decision to change.

Framework:

Let’s assume that the goal is to deliver a message to an audience. If I examine how understandable our message is on one axis. Then we examine how intact the message is on the second axis.

On our grid interact-ness is Y and understandability is X

On our grid interact-ness is Y and understandability is X

 

So if that message, is Agile then I can diagnose why I am being ineffective in communicating what I want. If either the understandability of what I am saying or content of what I am saying is low, I fail. I need to be able to communicate with the highest approachability if I am to succeed.

That is fine and easy to say, but what do I do if either or both, understandability or intact-ness is low? First you have to be able to recognize when either or both are low. I will give examples and some explanation. I will also give some reasons why something is low, with the hope of guiding you out of that position.

 

Noise

When both understandability and content are low, what you have is noise.

In the lower left quadrant, noise is unable to reach any one.

Noise is unable to reach any one

 

Noise comes in all forms. With noise we build a wall hiding the fact that there is no real content. Noise can be either ranting with no context to how and why something failed, or it can be cheerleading. Both of these turn people away from the message because it is unapproachable. If someone has concerns or excitement regarding the message you have left them with nowhere to go. All they have is how the delivery left them feeling and a bit of anxiety about its meaning.

I have been guilty of this. I have both complained that too many people call themselves Agile, without clarification as to why they are not Agile. I have also cheered the success I have had with agile techniques without giving context or information about why I had success.

The less concrete what you say is the more likely it is to be noise.

Non-contextual

When the content is intact but people are unable to understand and digest it or act on it, it is non-contextual.

 

In the upper right quadrant, non-contextual exists where people want the information but are unable to reach it.

Non-Contextual exists where people want the information but are unable to reach it.

Here you preserve the message by framing it into a single context. There is only one way the message can exist is within your context. If you ever find yourself talking in absolutes you are being non-contextual. This does not mean that you compromise what you are saying only you need to frame it in representation of the audience’s context.

Accommodating

In the lower right quadrant accommodating allows everyone to hear what ever message they want to hear.

Accommodating allows everyone to hear what ever message they want to hear.

When the understandability, and ability to act, are high but without the meaning or original message that is accommodating.

Accommodating starts with a message, but allows it to be adaptable to whatever interpretation the audience may have. Each person interacting with the message changes it to fit their needs. Nothing actually changes except the meaning of the message.

Here you lose your intent. Context is mistaken for reality and presumed to be the truth rather than a commonality upon which to build communications. I have been guilty of saying that everything is a suggestion without giving context to how you evaluate what is needed.

Transformational

So far I have only talked about the negative. There is one part of the graph that actually signifies success. If I can communicate such that I deliver the most of the content I was intending while making it understandable then the message is transformational.

In the upper right quadrant transformational reaches everyone and preserves the message.

Transformational reaches everyone and preserves the message

In order for a message to be transformational, it has to be able to reach its audience and be complete. That means describing it, and explaining it with the context not only considered but understood. You can only deliver a message to someone you understand. Once you understand your audience you can help them to understand you.

Summary

We can take the way we deliver a message, Agile in this case, and analyze it to understand if it can be effective. We can also examine messages we hear and put out into the world to see how effective they are.

We examine the message by how much content there is, and how understandable it is. We can classify our communication. Noise is neither understandable nor does it actually inform. Non-contextual messages keep the context but reduce understandability by ignoring context. Accommodating messages are very clear but lose content by allowing others to change the meaning.

 

Only when we keep the message intact, and clearly deliver it from an understanding position do we become transformational.

We desire to be in the upper right quadrant.

We desire to be in the upper right quadrant.

Now what

When we talk about Agile, we are talking about transformation. We are trying to bring an industry build on the mistreatment of people and failing processes to a point of success for all. We are trying to build human systems to automate the world, drive business, and generate money.

We cannot do this if the industry does not understand us. It becomes harder if bad experiences make it so they don’t want to understand us. We need to change the way we approach this, we need to be more efficient in what we say and how we say it.

So now what? Now we retrospect and learn. We categorize our successes and failures into these four groups and attempt to capitalize the good.

Before we speak, judge, or advise; take a moment and reflect. Move those conversations to the first quadrant. Focus on the individuals’ beliefs and knowledge. Try to capture their context and drive the lessons through them. Let’s transform the world!