Category Archives: Philosophy

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.

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!

Three letters that change how you think

Solutions feel so much more comfortable then questions; don’t they? Finding a solution makes us feel good. Solutions have power and people are willing to pay real money for solutions. Questions on the other hand cause discomfort. Questions represent problems that need to be solved and cost our money a lot of times.

So it is only natural that we focus on the solution. We jump to how a problem is solved without first understanding why it needs to be solved. We risk missing critical understanding in order to feel the rush of finding the solution.

I am not using the empirical “we” here, I am very much including myself in that “we”. I like solutions also. I like it when I can tie a problem neatly up with a bow and hand the finished package over to solve all that ails someone.

The solution is emotionally powerful but often the why is so much more important. When we understand the why we can better engineer the solution. The solution we will provide will be the correct one, or at least one that better suites the need.

 

As a developer and a problem solver how is always foremost in my mind. How can I solve the problem you are having? How do I alter my code to get the desired result? How…? “How” is powerful, it speaks of solutions and gives guidance. It is also the wrong question most of the time.

I have found that the “how” of something is inconsequential most of the time. When we focus on how we optimize for the solution rather than the issues that need a solution. We start fixing before we understand what it is we are fixing. When we ask the wrong questions we get answers that do not map correctly, even when they answer the questions we are asking.

Now if we knew the correct question we could find answers that have more meaning. The problem is that the correct question is often harder to answer. When we ask why we gain understanding of the root cause. The more we know about an issue, or request the better we can address that request. Why is much more powerful because instead of answers and guidance it leads us to understanding.

How follows why, but how is often disguised. For instance, “What would you like to see on this screen instead?” is not asking “what”. It is really asking “How do you want me to solve the issue you are pointing out with this screen?” Another hidden how is: “What if I changed this?” That question is really: “Is this how I solve the problem?”

Understanding that how can be asked many ways indirectly allows us to change the conversation by refusing to be lured in. We can instead rephrase each of the above examples to why questions. “Why do you want this screen changed?” or “What is it that you are trying to solve?” (Yes this is using “What” to hide a “Why”.)

That is only half the issue. “How” is seductive. Not only do we ask “how” when instead of “why” we are often asked “how” instead of “why”. We need to listen for it, and refuse to answer it prematurely. When we are asked “how” questions we need to change the conversation to focus on why first. We need to make sure both the person asking the question, and us, understands why. Once that understanding exists then how becomes important.

So let’s lead with understanding and follow with results. That is why a three letter word can change how, I mean why you think.

I don’t know

“I don’t know” gives us a lot of power. Using these words open pathways for communication and understanding. Too often though we ignore this phrase and start by jumping to answers that feel right rather than those based on fact.

Those three little words pack a whole lot of punch. In American society saying I don’t know is often very hard to do. In fact at least one study shows that even our children have trouble saying those words. The same study suggests that our very schooling rewards us for figuring out possible answers rather than admitting we do not know.

There is often a perception that logic should be enough to eliminate the uncertainty of not knowing. We should be able to extrapolate from known data to arrive at a logical conclusion as an answer to a question. That is a great technique to gain insight and guidance. The trouble starts when we take that extrapolated point of view as fact.

Fact is something that is. A fact is solid and unchangeable. A fact is also temporal and because things change, what was true before may not be true now. That does not change the validity of the fact or make the fact mutable. Logic can lead us to facts, but does not guarantee them.

Logic is good at leading us to hypotheses. A hypothesis is an idea based on known information. It is not a fact, but may represent one. A hypothesis must be tested and observed before it can be treated as a fact, and in truth it may sometimes never become a fact. That does not make the hypothesis of any less value. The real value of a hypothesis is that it gives us something to learn from.

I bring this up because understanding these differences helps relieve a lot of problems in software development and life in general. If we know what we have is a hypothesis then we can test it for validity. We can discuss it and research it. If we cannot prove it is a fact we can at least prove that it is valid enough. Knowing its validity means we have gained insight and can make a better decision.

Recognizing that we have a hypothesis instead of a fact is an admission that we do not know. This is a very powerful situation to be in. If we do not know something we can learn it, we can change it, and we can grow it to where it needs to be. I am not saying that not knowing something allows us to change the underlying facts, but instead allows us to realize that there may be a different course than we thought when we started. The facts may be different than perceived or even that the facts we thought mattered don’t. Only by testing and researching our hypothesis can we gain this knowledge.

So do not be afraid to say “I don’t know.” Use the power of those three words to unleash potential, find new avenues, and spark creative communication. Repeat after me: “I don’t know.”