Flashover

Cone of Uncertainty is used to describe how the uncertainty of our estimates decrease as our project evolves. At the beginning of any project, our understanding of possible edge cases, third party APIs, and other issues is limited. However, as we start the actual work, we begin to learn more and more about the problem space and the details of our system under development.

Barry Boehm's Software Engineering Economics is a heavily cited resource when it comes to the topic of Cone of Uncertainty. Boehm's version of the initial estimation range is 0.25 to 4 which means that your project can cost 4 times as less or 4 times as more than you expected.

If your company builds WordPress sites for clients, I'm willing to assume that this range is much smaller as you operate with the same tools and in the same problem space from project to project. You are able to collect historical data from your past actuals and apply that data to new estimates. On the other hand, if you are solving novel and complex problems, your initial range can be uncomfortably high.

What will happen the next time you give your client or manager a range instead of a number for a work estimate? Probably they won't be satisfied. It's likely that your answer will be followed by a question of "Can't you just give me a number?" We dislike ranges because a) we hate risk and we want others to absorb it and b) ranges don't fit nicely to our quarterly plans and budget proposals. However, the world cares very little about our dislike of risk. Uncertainty isn't reduced by ignoring its existence.

Here are three ways you can respond to people who need a number instead of a range:

1. Agree on a fixed budget with a flexible project scope and code quality. This means that if you find out during the project that your estimate was too optimistic, you cut down some of the features or start making compromises with code quality. However, your client or manager needs to know what flexible scope and quality mean in practice. Make sure they understand what they are signing up for.
2. Do discovery work. Cone of Uncertainty gets narrower as we learn more about the project. Build a Walking Skeleton or hack together a prototype using the required third party APIs.
3. Push back. Find a place and a time to discuss about the actual success rates of software projects and risk profiles. Just because our visceral reaction to estimate ranges tends to be a negative one, it doesn't mean that we are not willing to sit down and reevaluate our stance.

My final point is somewhat related to pushing back against the need to get single number cost estimates. Most of the time we should use our time and effort to get better at estimating the benefits of our project, how fast people will start using our system, and whether the project will ever be finished. Sometimes it's enough that we know something can be done under an X amount of money. This is related to the concept of information value and you can read more about it in Paradox of the IT Cost-Benefit Analysis and Reduce Expected Opportunity Loss with Build, Measure, and Learn. If you want to learn more about cost estimations, I suggest you check out the post You Keep Being over Budget Without Data.

Last week I read The Phoenix Project. It's entertaining and it offers a way for IT departments to make their work matter inside organizations that lack IT expertise. WIP is one of the things that the book got me thinking about.

Work in progress (WIP) is the work that has been started but not finished. There is WIP in manufacturing and there is WIP in software development. WIP is an unavoidable step in all production operations. But while WIP is inescapable, it's harmful in excess; when WIP goes up, due date performance goes down.

In manufacturing the more WIP you have in the production area, the more cluttered your work stations are. When there is a pile of unfinished work waiting for the operators to continue where they left off, those operators end up spending more time thinking what to do next instead of moving from one task to another. WIP makes the manufacturing work slower and more unorganized in big and small ways.

Manufacturing and software development have their differences but it's not difficult to see the waste WIP generates in our software projects: Each pending change to our codebase makes introducing new code changes harder. When developers have multiple tasks in progress, they have to do more context-switching. Some WIP requires us to keep the rest of our team up-to-date with the current task status.

Teams can try to control their WIP by limiting the number of tasks developers can work on at any given time. These are called WIP limits and while they might seem counterintuitive, they work when managing production performance.

However, setting WIP limits for small teams building custom software sounds troubling to me. Instead of defaulting to more management, we should first try to coach small teams to take more ownership of their ways of working. Taking more responsibility over different parts of the system and having the ability to change direction fast are the key strengths of small teams. We want our small teams to realize this opportunity instead of doing all the management and thinking on their behalf.

Here are three reasons your small team might be facing out-of-control WIP. For each of these issues there exists an alternative to WIP limits.

1. You don't control how tasks move from backlog to WIP

The pressure to deliver features might be so intense that your colleagues constantly push you to start yet another task before finishing the last one. You are allowing too much work to enter your WIP lane.

If something has a high priority, it moves further up in the backlog. It doesn't enter the production area because we don't want to introduce more clutter and context-switching to our workspace. If you want more finished work, you make the flow of work faster. More WIP means slower flow. Which of your extra tasks are so critical that they allow the overall development speed of your team to drop?

2. Bottlenecks prevent you from finishing

Are these bottlenecks temporary or do they seem to persist even when you move to different features? Dealing with persisting bottlenecks are likely to yield more benefits to your team compared to any refactoring or test coverage efforts (unless the bottleneck is related to poor code quality). Theory of constraints teaches us that improvements made at the bottleneck make the system faster. Improvements made anywhere else are illusionary because a chain is no stronger than its weakest link.

3. You try to maximise activity instead of output

We often give false value to busyness. Many work cultures reward people who look busy running around from meeting to meeting with a phone in their hand. It's the best way to make yourself look important, right?

Because we think busyness is important, sometimes when we face an obstacle with our task at hand, we freak out and start working on another task in order to avoid the risk of inactivity. This is not a good habit. Effectiveness is ultimately about output – not activity. We should all try to get better at finishing instead of getting better at starting.

A minimum viable product (MVP) is a product that's good enough to be released for the early adopters. When you're building an MVP, you prioritize time to market and market feedback over impressive feature sets and availability. The goal is to learn early and fast and avoid building the wrong things.

Especially first time entrepreneurs and software builders struggle to identify what's good enough for their initial product release. Instead of learning through trial-and-error and fast feedback cycles, the feature set keeps growing and the release date is pushed further and further into the future.

We have a tendency to focus more on the number of features than the overall simplicity and usability of our product. Our projects also experience scope creep as new requirements are discovered throughout the development process. It takes effort to say no to non-critical features when we are building our very first MVP.

Because of this, a successful MVP project is a result of successful scope management. It's a result of defining who are the early target users and what is the minimum set of features that can create value for them. At the same time, it's a result of excluding platforms and user groups. It's a result of making difficult compromises between scalability and time to market.

Reducing the number of stakeholders inside your software project can reduce the influx of new requirements. User story mapping can help you define the minimum set of features inside your team and protect on-going development from scope creep. Using third party software and services as a temporary solution for some of the requirements can reduce the amount of custom code you need to write.

Less is faster.

It's better to start this post with a disclaimer: I'm a software consultant, not a marketer. I've never been in charge of a marketing budget. During my university studies, I did one course in marketing and I barely got a C in it. When it comes to marketing, I'm still very much a novice – a curious novice, but a novice nonetheless.

Because of this, my views on content marketing might be naive and overly optimistic. Maybe professional work as a marketer would make me fall into cynicism and start treating content marketing as another predatory marketing mechanism. Maybe I'm just a sweet summer child unaware of the hardships of winter.

But here's the thing: I think content marketing is pretty awesome and it's a shame that more companies aren't creating valuable content for their audiences.

What's so great about content marketing? It generates trust, authority, and attention. It puts your focus on the long-term. It creates a system where the more you share your knowledge and effort, the more you get back from the community.

I think it's difficult to find a company that wouldn't agree on the benefits of content marketing. It's also probably not an easy task to find a business with marketing personnel that don't have a content calendar in use. People not only understand the opportunity of content marketing but also include content marketing in their marketing strategy.

And yet we often end up with neglected company blogs and content that doesn't seem to move anyone.

What makes a business struggle with content marketing? Here are three problems that you might be dealing with:

1. You focus on ROI

Digital platforms enable much more accurate data collecting methods compared to offline channels. Companies can tell if you bought something from them or scheduled a meeting with them after you clicked a paid ad on Google. This is still not possible with things like TV or magazine ads.

Because we can measure, we measure and we calculate ROIs for digital marketing the way we would never try to calculate ROIs for offline marketing. This means that content marketing can get easily pitted against online ads that are much more optimized towards short-term goals. Meanwhile, offline marketing still doesn't have to justify its spending because you can't measure it.

It takes time for content marketing to start producing results for your company. If you want your blog to help your SEO and be a valuable asset for your brand today, you should have started blogging in a consistent way a year ago. Because of this, you should be careful when setting short-term goals for content marketing. Otherwise you won't give your content marketing the runaway it needs to grow.

If after producing content for a year, you allow yourself to look at the metrics and see results that are extremely disappointing, should you establish content marketing as a channel that just doesn't work for your company?

Maybe. But before you make up your mind, consider the following:

2. You have a quality/quantity problem

Here is the second problem in a nutshell: your content is not that great.

In order to discuss how to avoid this problem, we have to first define what does quality content look like.

Content marketing is about brand and authority, but also about improving your SEO and lead generation. However, I'm willing to argue that these are different goals. Or that they at least require different measurements for quality.

If your main goal is to improve your SEO, good content is something that people are already googling for and content that people want to link back to. There is also a technical dimension in SEO-friendly content: you have to make sure things like metadata and sitemaps are managed properly.

If your main goal is to build up authority, you care much more about who is consuming your content and what are their impressions. Is your content interesting or does it make people yawn? Is your content brave and meaningful or is it safe and conventional?

Even though you can tell the difference between a low-value and a high-value content piece, this doesn't mean that you are now able to generate high-value content. You still need quantity.

Quantity leads to quality, or in other words "practice makes perfect." Keep pushing out content consistently and frequently, and the content creators inside your company start to become better content creators. What's the number one advice on becoming a better writer? Write more. Why wouldn't this same advice apply to content creation?

3. You don't have content creators

Of course you can't keep pushing out content if you don't have the required resources. Companies don't struggle with content marketing because they don't have enough ideas. Your company is full of people with stories, ideas, and knowledge that are waiting to be shared with the world. What your company doesn't have is people who are excited about content creation.

Why aren't people excited about the idea of content creation? Unfortunately school has taught some of us to avoid writing and other creative endeavours. We can still associate writing to the feeling we had when it was a Sunday night, we were supposed to write an essay about a topic we had no interest in, we had a word count that we had to hit, there was barely a full paragraph written down on our paper, and the thing was due next morning. You can never underline enough the opportunities, the learning, and the fun you can have producing content. If you make content creation sound like homework, people will treat it like homework.

But more importantly, content creation is time away from something else. That something else might be things like project work, billable work, or personal development time. Why should your coworker write a blog post instead of making progress with their project? Where does content creation rank in terms of the priorities of your organization?

Who sets the example of content creation inside your company? Is it you or are you trying to find someone else to do the work for you?

Content marketing is not the only way you can build up authority and presence. Maybe content marketing is simply not for your company. And if it's not, let it go. Free up your resources. Discover the marketing channel that works better.

Sometimes it's difficult to explain software to "non-software" people. Luckily there are metaphors. We can compare software development to things like construction, gardening, or writing to help others understand what we do.

Metaphors can also help your own learning. The way I learned the difference between a class and a class instance was imagining classes as architectural drawings and class instances as different houses built following those drawings.

However, metaphors have their limits. And when stretched to their limits, metaphors start to break down. You can also hinder your own thinking if you rely too much on metaphors.

Let's talk about analogies and analogical arguments and reasoning. Analogies are comparisons between different entities. A metaphor is one way to communicate an analogy.

When you make an argument from analogy, you start with perceived similarities and then continue to infer further similarities that have not yet been observed. Here is the more general form of analogical argumentation:

1. S is similar to T in a, b, and c.
2. S is perceived to have feature z.
3. Therefore, T also has the feature z.

We use analogies constantly as the basis of our reasoning. There's nothing wrong with it (you can find examples of analogical arguments used successfully in science here https://plato.stanford.edu/entries/reasoning-analogy/).

The problem is that sometimes we might end up with arguments that aren't actually valid if we base our reasoning solely on analogies. Here is an example of that: Writing software can be like construction. Should we therefore avoid writing code during winter months?

We can easily spot the problem with the previous example (software isn't built on top of actual ground and therefore we don't need to care if the ground is frozen or not). But could the following argument slip past you in a meeting when you haven't had your first cup of coffee: "Imagine starting to build your house without blueprints! We can't start this project until we have a detailed plan for our software architecture."

How about the effect metaphors and analogies can have on your own thinking and reasoning? Instead of figuring out what is actually true, analogical reasoning can be the easy way out when you're faced with a difficult question. Pattern matching comes naturally to us. But this doesn't mean that we shouldn't make the extra effort to every now and then start our reasoning from fundamental truths or first principles.

For a second, stop imagining how software development is like building a house. Instead, look at the people in your project and study what they do. Observe how the code actually evolves inside a codebase. Focus on reality and allow it to teach you.