Sizing Defects

Coming from the perspective of a Tech Lead or a Product Owner, it is my opinion that time spent sizing defects is wasted time. Let me explain a little about this.

Firstly, we all (should) be living in a zero-defect world. That is, we are striving to achieve a zero-defect application. (More on Zero Defects some other time). But in the zero-defect world when we detect a defect, we need to respond quickly to resolve this issue. 

Secondly, in most cases the amount of work necessary to determine if something is trivial to fix v. very very difficult to fix is equivalent to fixing the issue itself. 

My premise is this, if you identify a defect, assume that it is size medium (or what ever your team average is) and get to work. You can pull in as many teammates as you like to dissect the issue and discuss possible resolutions after you've started the card. But starting the card is more important than understanding its size and impact on the project at the time. 

All that said, if your a Program Manager or Delivery Leader and you are concerned about a delivery deadline, you are going to want to know the size. You will want to understand how this defect impacts your delivery schedule and if you need to re-communicate the commitments the team has made. This is understandable, but you need to overcome your desire to distract the team for solving the issue. Consider that you are just adding to the duration of the fix. 

Rather, focus on getting the defect in progress as soon as possible and getting the issue resolved. If you have very small cards any defect you encounter will generally be the same size as the size in the middle. If its a little smaller or a little bigger it will average out in most cases. 

What Is a Good Tech Lead?

This post was originally created here


Tech Lead is a role frequently seen on development teams filled by a wide variety of people. Many times the Tech Lead is the most senior person of a technical nature on the team. By senior I mean the person who has the longest tenure. This is frequently a good choice, but not always the right one.

Most often, with age comes wisdom, but this isn't always the case. A long term employee of the same company with limited exposure to external environments is operating in an echo chamber. They lack a diverse experience to use as a sounding board for their ideas or the ideas of the people around them.

So to begin with I think a key characteristic of a Tech Lead is a breadth of experience. The more projects, situations, languages, products and managers a Tech Lead has had, the more likely they are to be good at what they do.

Tech Leads need to be calm and rational people. For any number of reasons projects can get crazy; people shout and threaten and cajole when things aren't going as planned. A good Tech Lead knows that nothing goes as planned and can calmly address issues knowing that most problems are solvable as long as you don't lose your head.

Tech Leads make lots of choices throughout the course of a project. Some have little or no consequences, some have major repercussions. A good Tech Lead knows the difference between these kinds of choices and therefore how much effort to invest in making them. In all cases, a Tech Lead should make those choices with confidence. Where they cannot make those choices confidently a good Tech Lead is open to suggestion and experimentation. In any case the Tech Lead understands the risks and costs associated with making a choice and can weigh the decision appropriately.

Tech Leads need to remain focused. It is important to have good technical depth and breadth, but it is also important to understand when you are out of your depth and have the humility to ask others for help. A Tech Lead should always be willing to delegate to others in order to remain focused on the primary goal of the project: delivering value to the business.

In order to remain focused it is important for a Tech Lead to be passionate. Not just about the objective of a project, but about the technology itself. A Tech Lead should strive for technical excellence in the solution. It isn't just about doing the Right Thing(tm) but also about doing it well.

In order to make this work a Tech Lead needs to have the right disposition. A Tech Lead needs to be simultaneously likable and aloof. Take a hard line on issues that are critical to success while remaining pliable on everything else. Logical and rational without becoming cold and unapproachable. A good Tech Lead should push a team to exceed its own expectations in the quality of their work without breaking their spirit at the same time.

A good Tech Lead should be the team's staunchest defender and biggest cheerleader; A mentor, guide, and leader who approaches every situation with calm rationality and a minimum of ego.

Team Work and Defects

For the purposes of this post I'm using Defect in its broadest sense. 

The Product Owner, Tech Lead, and Developers should be consciously working together to reach a goal. Identifying something as a defect should not be pejorative.  It should be a means of improving process and ensuring cost effective delivery of features. It is not personal. It is a way to see that there is a flaw in the system that needs to be investigated. 

From the vantage point of the Product Owner, identifying a defect is important to ensure both system correctness and to manage cost. If a development team cannot consistently deliver on the specified requirements, or if that consistency is derived of trial and error approaches, a product or feature may become impracticable for the needs of the business. A product owner should ask, did I specify this completely? What additional verifications could I have specified to have avoided this. 

From a Tech Lead's perspective a defect signals a flaw in workmanship. They should ask, did we ask the right questions when preparing to do the work? Did we make the correct verifications after the work was complete? Are we missing a test? What kind of automation and tools could we bring to bear to prevent this type of issue from occurring again?

Developers should be asking themselves, how did I not understand the requirements? Should I adjust my testing strategy to keep the acceptance criteria in front of me? What questions did I fail to ask? What processes and procedures did I fail to observe? What processes could I suggest to the team for preventing this kind of issue?

All of these questions should be asked openly and feely. A team operates as a unit, not a collection of independent contributors. For each perceived defect we should have an open and frank discussion about the nature of issue and attempt to identify the source using techniques like 5-Whys or Eight Disciplines

Finally, remember that none of this is personal. We get emotionally attached to our work as a consequence of caring deeply. This often leads to accusatory and defensive behaviors when discussing defects. Our natural inclination to avoid conflict isn't much help either. Try a different tack when approaching defects.

First, when declaring something to be a defect, propose the issue rather than declaring it. There may be a vantage point from which it does not appear to be a defect. Additionally you may be making a declaration without all of the information. 

When discussing the whys of a defect, avoid becoming defensive. Try to state the facts of the situation as plainly as possible without adding emotionality to them. Be as objective as possible. 

Finally, get comfortable with saying 'I don't know'. We cannot know everything despite our best efforts. So if someone makes an assertion in either direction, ensure that you've considered your response. The real response to any assertion can always be 'I don't know'. Be honest with your self and your team and avoid speculation and hyperbole when discussing the 'why it happened' portion of a defect. Keep it simple. 

Objective of this blog

Greetings. I'm starting a new blog. My goal is to keep my posts as concise as possible while still delivering payment to the reader. Help me find my balance by pointing out how I'm doing on this objective.

Thank you,

.rich