Tag Archives: Understanding

#NoEstimates Story Sizing

A way to determine if a story is small enough without estimating it.

TL; DR

“No Estimates” is a modern movement in software development that focuses on eliminating wasteful estimates. However how do you know if a story is small enough to be accomplished without estimating its size? There are a series of rules that when followed guarantees a bite size bit of work.

There are a series of rules that when followed guarantees a bite size bit of work. #NoEstimates Click To Tweet

Setup

“No Estimates” is built on continuous delivery of valuable product. That means that the business must be able to measure the output of a development team in near real time. If releases are regularly weeks or months away, then you leave the business with few tools to measure with. Faster the delivery the better they can measure. Stories need to be small enough to complete daily.

How do guarantee that the average story is small enough to be completed in a day without estimating?

The Rules

There are three rules that can be followed to ensure that a story is as small as possible. In all three rules, the word team means much more than the development team. It means the whole project team including the developers, the product owners, testers, management, executive management and anyone else who has a stakes in the product being delivered.

  1. Does everyone on the team have the same understanding of what the story delivers, and what need it addresses?
  2. Does everyone on the team have the same understanding of when the story is completed?
  3. Is the story free of any known preconditions?
Three simple rules for sizing stories in #NoEstimates Click To Tweet

Understanding

Gaining understanding about a story that crosses skill and role boundaries is difficult. To better communicate intention, we must be communicating simpler ideas. The first two rules do a lot to limit the size and scope of a story.

The first two rules also ensure that the right thing is done. A shared understanding means a shared vision and shared responsibility. If we understand what is to be done, and when it is done then we do not mistakenly build the wrong thing.

Preconditions

Once everyone understands what is to be done, and when it can be considered complete then we have a certain level of understanding about the story. If at that time anyone can think of a precondition that must be done before the story is complete, then the story is too big to be worked on. Maybe it is time to work on the precondition, or something else entirely.

The operative word in the last rule is “known”. We could spend an infinite amount of time looking for and understanding preconditions. It also goes without saying that we may find new preconditions as we start working. The important thing is that no preconditions are discovered in the process of gaining group understanding.

During the doing of the work, if we do discover a precondition we then need to decide if we continue or abandon the current story? Most often we can continue, especially if the precondition that was discovered meets the 3 rules, which means we must communicate our progress effectively.

Summary

In short, by following the three rules we can ensure work is taken in bite size chunks, even without estimating.

Employee Feedback without Unicorns

I am talking at #Agile2017 about giving meaningful, helpful, and humane, employee feedback. The secret is that the employee needs to be central.

TL; DR

The only person qualified to give advice to an employee regarding their career is the employee. That means we need to empower the people who work for- and with- us to analyze their career. If we can empower people to better their lives they will do more and do it better.

The only person qualified to give advice to an employee regarding their career is the employee. Click To Tweet

Questing

What if employees looked forward to receiving feedback? What if they found feedback valuable and able to improve their lives? What would that look like? How would we provide that environment? Our department asked these questions and the whole department swarmed to tackle the problem. The solution we came up with worked well in our context, and I also believe the lessons learned while figuring the answer out are valuable to others.

Personal

The first lesson we learned was that if we want to give meaningful feedback to individuals was that it had to be individual. That means we must do things to consider, protect, and appreciate, the single person who is receiving the feedback.

Our solution, currently, is to do a personal retrospective for the person. This retrospective is private, personal, confidential and facilitated by a peer who the person trusts.

Trust

It is important that the retrospective is personal and private. Without this security, there is no safety. Without safety, truth is limited, constrained and lost. The goal is to allow the employee to have real insight into how they can improve their career path, their entire career path, not limited to that within the company.

Facilitation

It is also important that this retrospective is facilitated. Facilitation gives the opportunity for the employee to explain their thoughts to another. The process of explaining leads to insight.

The facilitator is to listen, and ask questions only to gain understanding. They are not to judge or comment. They are not to burden the person whose retro it is with their own opinions. We decided to provide facilitation training for everyone who is interested in being a facilitator.

The facilitator is invited by the employee who is undergoing the retrospective. Invitation is important, as it signifies trust. It is just as important the invited facilitator be allowed to refuse without explanation. Not everyone is comfortable with facilitation.

The last thing to note about facilitation is that the facilitator will make mistakes. After all, these are not professional facilitators. Mistakes are okay. Even if they disregard all their training, just by being there for the retrospective, they will make the retrospective more successful.

Output

The content of the retrospective is private and personal. The things talked about during this meeting need to be protected, unless there is a legal obligation. If not, we again lose trust.

The product derived from this retrospective is a set of possible goals. One or two of these goals will be decided upon and acted on. They will be shared with the director who will help to achieve the goals. He uses this information to understand the ebbs and flows throughout the department.

When a goal is not achieved, the director needs to know if the department hindered its progress, and if so, how. If a goal is completed the director wants to know how the employee felt about the goal, if there is more that can be done to improve upon the accomplishment, or if knowledge can be shared.

Rewards

These goals, the retro, and information gained through this process, except where there is legal obligation, is disconnected from compensation. This frees us from the burden of creating an accidental game where the outcomes can become harmful.

The only reward is the ability to take an analytical look at your career and take steps to move it into a direction you want.

Plug

Please come to my talk, where I will talk in depth on this. I hope to see you there.

I will be watching Facilitation Without Unicorns at #Agile2017 Click To Tweet

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.”