Seek Closure

Closure is surprisingly difficult to achieve. Every software project has many details that need to be implemented, tested and then rolled out. Meanwhile, market pressures are driving the product in new directions with bugs and new features.

It's not just software. When I do a home  project, I tend to procrastinate and waffle on the last 10%. Psychologically, that last 10% is often the hardest part. I have a bathroom that is still missing a piece of trim from a reno I did 3 years ago.

We also often hear about emotional closure. After breakup we need to move on with our lives. There are always loose ends and baggage to deal with. Without closure we aren't moving forward.

A new product or feature has goals which will never be 100% met. There are always loose ends. The reality is that we can't be perfectionists There will be details that can't be cleared up in a timely fashion. It takes a conscious effort to tie them off. Otherwise the project enters a form of limbo - some stuff is not quite finished but at the same time isn't important enough to get finished.

Closure requires a conscious effort, discipline and determination. It doesn't happen organically or accidentally.

Principles

We need to be able to make decisions and stick with them. It isn't easy. It takes a few basic principles, a concerted effort and a pragmatic attitude.

The first principle is to

Bundle activities into milestones and manage the milestone, not the individual issues.

Seek closure for the milestone, rather than continually trying to get a grip on a chaotic and changing set of unqualified individual issues. A concrete milestone gives you a means to focus.

The second principle is to

Once the scope is agreed, don't let anything else into the milestone.

Creep is a basic force of the universe. Individual tasks tend to grow in scope. New features will be wanted. Creep is the enemy.

The third principle is to

Focus people on the milestone. Closure of the milestone depends 100% on closure of the individual issues. Lack of focus and competing priorities are another enemy.

That trim in my bathroom would probably never be finished if my wife didn't nag me. It's basic human nature. This is where a project manager can be very useful.

As always, there are going to be exceptions but you need discipline and to be prepared to take a hard line on these three basic principles at times.

The Basic Process

The process is preciously simple.

Stage 1. Planning

• Consider your goal and determine the contents of the milestone.
• Estimate a reasonable completion date, or requirement for a market opportunity.
• Are you being greedy? Try to trim the milestone.

Stage 2: Execution

• Resolve issues in priority order. The temptation may be to knock down some of the easy issues first. Don't do that! Avoid back end loading your milestone with all of the hardest issues.
• Verify the issues as early as possible. Avoid back end loading your milestone with all of the hardest testing activities.
• Manage creep. Don't just watch it happen.

Stage 3: Closure (the Hard Part - that last 10%)

• Nag. Make sure that people are working on closure.
• Be practical. The easiest way to get closure is to avoid creep and move outstanding issues to the next milestone.

An Illustration

You are in the late stages of development for a software release but there are still some tasks to complete and a few weeks of calendar time left. It's been some time since the last software release and there's pressure from a customer. The temptation is real and you add a few more tasks. Bob isn't on the critical path and he can do the work without impacting the schedule.

During the next two weeks you find some bugs during verification that need to be fixed. Bob is sick for a few days. Some new market information suggests that one of the new features in the release might need to be changed. Now it seems that it will be at least another week.

During that week you get some closure on the original scope but Bob learns that his estimate was incorrect. In addition to the sick time he will probably need another week.

During that week there is an additional push from marketing to change feature X they were so hot about. Bob gets his feature done but no one thought about how to verify it. The verification team does some ad hoc tests but engineering management is concerned that more testing is needed. There is a meeting to discuss dropping the new feature but the feeling is that you are very close and it will make a customer happy. The verification team is asked to do some more comprehensive testing.

After the meeting sales calls down to say that a hot new prospect that is evaluating the product will make a big order if you can do one little thing. Joe is available and can do it in a couple days which won't affect the schedule. The verification team reports that they have found what may be a serious problem in one of the original, key features of the release.

...

You get the idea. Each change at this stage risks the ball game. The more time that goes on, the more opportunity and pressure to make more changes. If this becomes a pattern, people don't take schedules seriously and focus becomes increasingly difficult.

Making the Hard Part Easier

How do you do this? Here are some specific techniques that anyone can use successfully, regardless of the size of your company.

Defend. Someone will always be prepared to argue for some new feature. Creep always has proponents. There needs to be someone that is prepared to argue for the feature to not be included. An effective solution is to require at least three key people to agree to a scope change.

Prioritize. Increase the priority of closure the closer you get to milestone completion.

Be pragmatic as you approach milestone completion. If you have a difficult problem that is holding up a milestone, consider pushing it out or splitting it up and pushing out part of it.  Review all remaining tasks and their importance. Streamline and focus the review. Make P1 or P2 bugs mandatory, P3 defer-able with discussion, P4 or P5 auto defer-able.

Be disciplined. If someone checks in a change that wasn't in scope, back it out, especially near milestone completion. It doesn't matter if it is a nice to have. Put it in the next milestone. Create a culture where people know better.

Branch ad hoc requirements. If you have a customer that needs something fast, do it on a branch for that customer only and merge it in the next milestone.

Be mature. If you find a new bug, resist the temptation to fix it right away. If it is a legacy issue don't even entertain a scope change - if customers already have a release that contains it and they haven't noticed yet then there's a good chance they won't notice this time either.

Use a tool to associate tasks with milestones. Use the 'fix version' or 'milestone' field. The unresolved tasks are the remaining development scope. Close issues after they are verified. The resolved tasks are the remaining verification scope. Status is readily available in real time - just query the open issues in the milestone.

Use a triage process. Only a triage team/individual should be able to assign an issue to a milestone. Make your triage team your first line of defense against creep - by default new bugs should not be triaged into the current release

There are always exceptions to the rule. You want to make creep decisions difficult enough that they are taken seriously. The proof is in the pudding - follow these principles and closure will become a regular event. It is a healthy, liberating pattern.

The Search For Low Hanging Fruit Can Be a Trap

Development companies love low hanging fruit but the expression has lost some of it's meaning in recent years through over use and, I propose, because the very pursuit of it devalues it.

It refers to fruit that you can easily harvest, that you can reach without tools and ladders - it's low effort so potentially high value for effort.

Low hanging fruit can exist in many places in tech companies: cost reductions in hardware purchasing and design, easy bug fixes in critical areas, simple process improvements that save people time. It is worth looking for these high value for effort items.

But, the thing is that once you've picked them, they are gone. There isn't a limitless supply of low hanging fruit.

It takes a specific focus to identify low hanging fruit and then it takes specific actions to address those issues. It takes time and focus and often involves creating some new practices having new meetings, possibly hiring or reassigning resources - infrastructure.

That can be where the subtle trap is set. Once people become good at it and certain infrastructure is in place it can develop a certain amount of inertia. Also, if it is successful, management can become very attached to the easy gains and want more.

Therein is the conundrum. It's very success is the seed of it's downfall. The next round of gains isn't quite as easy and the payoff isn't quite as large but the organization has developed some skill and the activity may still bear some fruit (not quite so low hanging, pun intended).

But each round is more difficult with less gain. Organizations need to recognize when the effort is no longer returning high value.

Some activities can be rolled into ongoing activities. Every new hardware design may have the potential for cost reduction once it passes proof of concept and prototype phases. Bug triage can give a priority boost to easy bugs.

The approach to low hanging fruit tends to be very short term, quick fixes which can have consequences. Quick fixes may not fully or properly solve a problem. Each round of low hanging fruit harvest deals with more difficult problems and the quick fixes consequently bear more risk.

Don't forget that some problems deserve in depth solutions. Don't empower the focus on low hanging fruit to create new problems that outweigh their gains.

Most small companies that have to rush to market with a product create a significant amount of low hanging fruit in the process but a compelling argument for a focused harvest of low hanging fruit may only occur once in a company's lifetime.

It can be very worthwhile activity. Just remember that you can only pick each juiciest, easiest to reach piece of low hanging fruit once. Don't get caught up forever looking for easy gains.

Does Your Company Have ADHD?

It can be very important for a business to be reactive to changes in requirements, business opportunities, maintenance situations, etc. The ability to react is an aspect of a healthy, dynamic, adaptive company.

A startup may have one angel customer that is sufficiently lucrative to only require reacting to their needs. This is a fantastic situation. You don't have to guess what this customer wants. Reacting is easy. You don't have to have vision or make touch choices.

However, it can be habit forming. The flip side of the coin is the ability to stay focused. When you have more customers, when you are trying to anticipate markets, when you have to start prioritizing because of resource limitations it is essential to be able to stay focused.

Being reactive and being focused are competing forces.

When it is necessary to stay focused and people are having difficulty staying focused an organization can exhibit a collective personality and that personality can have disorders just like a person can. An organization that is having a hard time focusing looks a lot like a person with ADHD. And it can be as big a problem for the organization as it can be for an individual.

When the company needs to be reactive it's not a disorder. It's entirely appropriate. However, when focus is what is needed it can be a real problem. This post deals with the scenario when a company needs to focus.

There are several tell-tales that your company may be suffering from ADHD. Does an e-mail from a customer send people off immediately investigating some new opportunity or problem? Does a new bug send people off immediately seeking a solution? Do meetings get off topic. If they go off topic do they come back on topic? Do you have recurring discussions on specific topics? Are people working on what you think they are? Do you spend a lot of you meeting time talking about things that you don't end up doing?

People at all levels can be easily distracted. I've seen executives leave a meeting where important priorities were being set leave the meeting and go directly to an engineer and ask him to do something explicitly contrary to the priorities that were just agreed to. This kind of ADHD behavior is communicable. The higher up it manifests, the more communicable it will be.

When focus is required it is very important for management to set an example. It can be very hard for entrepreneurs to focus. The same damn the torpedoes drive that allowed them to step boldly into the unknown and found a company often leads to a reactive business approach. If the message is mixed it will likely be very difficult to keep people focused. People will learn that recognition comes from being involved in whatever new thing is happening and not from sticking to a plan.

It is important to think about new things as they come in the door. The need to focus doesn't permit a company to stick it's head in the sand. Companies still need to be reactive. The key is to compartmentalize the assessment (triage) of new information and the assignment/resourcing (action) of it.

The same distinction can be applied to a new project that may involve an entire department of the company and to the smallest maintenance issue in the field that might only take 5 minutes to fix.

The issue is being in control of when and how to react.

The assessment of a new project will involve substantial effort and will normally be formalized - a business case, a profit margin analysis, etc. The assessment of a new bug might only take 5 minutes. They are both important. You will have many bugs and even small ones can be distracting if you don't stay on top of them.

You want to make it clear that you are triaging everything that comes in the door and who is responsible for it. When it is clear other people equally clearly aren't expected to or desired to be involved.

Some triaged issues will be actioned. You want actioning a task to be equally clear and visible so that it is clear what is expected and who is expected to do it.

Triage and actioning can be brief and simple but it is essential that you do both. Together they concisely and unambiguously specify what is expected (and not expected) from people.

Staying focused requires good record keeping. Issues, features, opportunities, etc. will recur. If you don't keep track of the triage decisions you will end up having a lot of Deja Vu. It's a good idea to keep track of the reasons for and against an issue and any additional information like work breakdowns, estimates so that if the issue comes up again you can quickly review what you decided last time and why. If there is no new information then you don't need to do anything more than just review the decision. Just ask if there is new information and if the answer is no, you don't need to engage. If there is new information then record the new information and retriage the issue. You don't have to discuss it on the spot. Don't let people hijack your focus with wishful thinking, whining, etc.

For bugs I highly recommend a bug tracking system. There are many good open source options. You don't need to spend a lot of money. For features you can also use a bug tracking system. A bug tracking system inherently supports triage and assignment and they make it easy to record the reasons and any extra information about the decision. No one works on a bug/feature until it is triaged and assigned to them.

For strategic and tactical business opportunities most small companies can record an overview in a spreadsheet and backing information on a file server. Set up an incoming opportunity folder on the server, keep the overview spreadsheet in the main folder and create a subfolder for each opportunity. Create a project folder and only create a subfolder for a new project when an opportunity is assessed and there is a management signoff to spin up the project. During triage there may be specific actions to do high level R&D estimation, cost of goods estimation, market assessment, etc.

Many good ideas come up in meetings but they can be distracting. You want to spend your meeting time talking about what you ARE working on or are already COMMITTED to working on. If you find that you are spending a lot of time on tangents, consider setting up a brainstorming session on a regular interval (biweekly or monthly) so that you can ask people to use that venue to bring up new ideas that would otherwise distract your operational project meetings.

Focus is so often the key to successfully capturing market opportunities. There are lots of real challenges. Don't let ADHD create more challenges for you. Be a company that can focus. Advocate clear and concise triage and assignment and practice what you preach.

No Whining!

Whining is a symptom and, like a disease, it can infect others and spread. Anyone who is whining is wasting valuable energy and adversely affecting people around them. It can become quite destructive.

All companies have limitations. Decisions have to be made about what problems to tackle. Small companies often have tight limitations. Being good at one thing often depends on not diluting the focus on that thing. That means NOT doing some things, maybe even many things.

It is common for people to grieve that their thing is not be on the agenda. Getting people through the five stages of grief quickly (Denial, Anger, Bargaining, Depression, Acceptance) can be a real challenge. You want to get to acceptance as efficiently as possible.

Whining is a symptom of the first four stages. Its tone can change: during the Anger stage it is bitter whining, during the Depression stage it is sad whining. Constructive people that are moving forward don't whine. That's what you want. People that tend to whine may need to be trained.

How do you train people? It's easy. Don't tolerate whining. At all. Zero. Encourage people to present ideas and to lobby for them but they must accept a decision. It's Ok to reopen an issue after a suitable time period but until then their job is to accept it.

It is important to listen to your people and to allow some discussion after you have made a decision. However, don't weaken your message. Even if you are reconsidering it is better not to weaken your position by implying that you'll "think about it" in case you decide to stay the course.

It is better to acknowledge what you hear and respond by asserting the decision: the points were considered, the points are not compelling. At some point, ongoing discussion and questioning becomes whining. Usually it is when there is no new information. It is fair at this point to ask if there is anything new. If not, entertaining further questioning is enabling whining. At this point you need to stop engaging on the issue.

If you respond politely, firmly and consistently you will find that people take less and less time to get through the process. If not, consider a penalty for whining to emphasize your position - a fine.

Sounds easy? Well, there's always a catch. In today's politically correct world, anything that is phased politically correctly is hard to say no to. Don't be tricked by niceties.

Popular culture understands how boring, annoying and counterproductive whining is. For example, google "no whining" and click on the images tab.

Everyone knows it. Don't create an environment that encourages it. 

Should Is A Four Letter Word? Or Should Be.

It's easy for people outside of a thing to criticize it. It's so easy that people often aren't even aware of doing it.

One form of criticism is indirect, the statement of how a thing aught to be. How it should be.

It is considered politically correct for the most part so it is insidious even in many environments that outwardly foster a positive work culture.

In a technical environment, especially in small companies with limited resources, many expediences need to be taken. The current state of the union is the result of conscious decisions in the past - the best decisions that could be made at the time.

It should be just the way it is. Think about it.

It isn't appropriate to look at the current state of things and say that it should be different.

It's perfectly fine to say that we want it to be different. It's even fine to say that we should make improvements. Both of those statements are forward looking.

The problem is the fine line between a proactive stance on the future and a complaint about work done in the past. Assuming everyone is operating in good faith, the problem is that the context is ambiguous. That some usage is critical taints other usage.

It's safest just avoid using it.

There's an idea that relates should to another similar sounding four letter word. It is a pertinent comparison and thinking of it that way helps to avoid its use.

Don't should on people's work.

Quality Is Bottom Up, Not A Spice You Can Add

All firmware/software product engineering companies struggle with quality.

All companies. 

Quality costs money and takes time. When time to market is important, it is often more important than quality. Successful innovators must be able to go boldly into the market and make tough decisions to go fast and worry about quality, if necessary, later.

Lack of quality also costs money. Some customers will turn away from a purchase or return a purchase if quality is perceived poorly for the price. If a product is under warranty, returns can be very expensive, especially if it is a software/firmware problem that must be addressed.

Startups can be fast to market by being very time focused and accepting quality risk. A successful start up is often forced to mature quickly. Once it has products in the market place, quality problems can threaten their market position and strangle a small engineering department with maintenance.

How does a small company make the transition from time to market to quality over a product's lifetime?

Most don't.

Some keep blasting aggressively forward, damning the torpedoes, risking losing their customer base and being overwhelmed by maintenance. Some look to the industry for best practices, hire consultants, create processes that address symptoms but not the root cause, etc., at the risk of being overwhelmed by constraints and losing their innovative edge.

Where is the middle ground? How does a small company mitigate quality risk while avoiding being handcuffed by introspection, finger pointing and red tape.

The answer is shockingly simple. Quality has to be built in. It's not a feature that can be added in. It's not a spice. There is no magic quality dust that you can sprinkle on your product. Improving quality takes calendar time which in turn takes patience. Management often cannot get its head around this fact. They want a quick fix - "We need better quality now!".

The best advice I can give a growing small company is to be very wary of anyone that promises a silver bullet. There aren't any. Don't trust anyone that tries to sell you anything that sounds either fast or easy.

Quality is everywhere. In a software product, it is quite literally everywhere. Every line, function, library contributes to quality. When there is a quality problem, the root cause is also everywhere, every line, function and library. It is inside out, bottom up. 

The only way to raise quality is to patiently raise the quality of the entire code base. Priority can be focused in areas that are either more essential or problematic but the solution requires a patient, disciplined approach.

The process is also shockingly simple. Testing. While software development best practices can help mitigate quality risks for new or updated software, ultimately, it comes down to testing. All kinds of testing. Unit tests, functional tests, stress tests. Testing.

Small company management hates to hear about testing. "That would take a lot of time and effort. We need something now". Exactly! Denial is very costly. The longer a company hedges on testing the longer it will waste time and money and continue to risk credibility in the market.

Rather than believe that it is a bottom up maturation of the entire product code base and invest in a rational bootstrapping of testing infrastructure, companies often waste precious time with internal reviews, finger pointing and whining about their plight. Then they may hire consultants, install tools and processes, make changes in mid management and waste further time.

Denial is also why there is so much snake oil in the market. Consultants make a lot of money on denial. Tool vendors also share in the bounty. But, there's no money to be made in the hard truth that quality is a long term bottom up journey.

Companies that make a successful transition are the ones that get over the whining quickly and accept what has to be done. Only then can they look objectively at their product and start to prioritize a test driven quality agenda.

The problem is that the damn the torpedoes Type A personalities that were essential to the company's early success can have a very difficult time embracing an agenda requiring patience and ongoing investment.