Why and how to plan for problems

Let us start with a simple problem. Suppose you planned to wake up and gym tomorrow morning. You have been psyching yourself for this day, and now you are ready. On the planned day, you wake up bright and early only to find its raining! What do you do next?

What is the definition of a problem?

My friend Mercy recently posted a brilliant article Minding your P’s and Queues: Flow Management by Queueing Theory (https://medium.com/swlh/minding-your-ps-and-queues-flow-management-by-queueing-theory-1b45dcd27e33). 

In it, she writes this scenario:

Consider a bus with 50 university students attending a music festival arrives at the supermarket. The students all pick their items and head to the tills at 9:00 AM. Assuming the queue already had ten customers, immediately, the queue length increases by 50 arrivals to 6 times its original size. If each customer took an average of 3 minutes, the first customers to experience a doubling of this cycle time to 6 minutes will be, according to Little’s Law, those served at 9:36 AM.

Do you see a problem here?

I say there is no problem. I think nature never offers problems. So what if the customer experienced a delay of 3 minutes? Maybe they enjoy the music at the supermarket!

What we have here is a problematic situation. To get to a problem, we must employ some creativity.

For starters, a problem must have:

  • A concerned party
  • An ideal state
  • The actual state
  • A way of knowing the difference

So let’s start on why it makes sense to plan for problems.

Empower the team to recognize problems

I hope the trivialized examples above made the point. 

 Problems can not just be identified; they need to be defined!

When planning a project, it’s easy to get caught up on the positive vibe of the moment, envisioning how you and your team will be successful. 

Reality being what it is, all your grand plans will likely go awry once you hit the real world. You probably already know this, but do your colleagues know? 

For all of you to be on the same page, you must agree on what needs to happen in the real world before you call out a problem.

For example:

Problem: Experience resistance from the business

How we will know:

  • Julius from HR will remind us of his vendor
  • Initiative Z already launched will be canceled
  • We will experience an uptick in noncompliance on product Y

By running the exercise, you ensure everyone in the team has the tools necessary to point out problems.

Gain an understanding of the real scope

Let me remind the reader of one of the most famous law in software estimation:


Douglas Hofstadter

Even thou this is not truly a scientific law, as practitioners, we can attest to its integrity. I think the law gets its power from unplanned work.

Let’s get back to our gym example if you run through an exercise defining situation that your team could identify as a problem. You would have probably come up with rain as a problem; this means you would need an umbrella if your original scope were packing your gym clothes and maybe a bottle of water. Now you know you have to pass by the supermarket and buy an umbrella as well.

Solve the solvable

The truth is, you can never anticipate or even accurately define all problems. The real world has too many dimensions for that. But each issue we can expect and plan for, gives us incredible mileage.

I have talked in more detail why you don’t want unplanned work anywhere near you: (How you pay for technical debt) https://blog.chenchatech.com/2016/03/how-you-pay-for-technical-deby/.

How do you plan for problems in your organization? Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchex


Why do a manual Quality Assurance Test?

I am proud to work with some of the best minds in QA the country has to offer. In this time I have come to learn something about what it means to do excellent QA work.

You see, I used to classify the QA role as the fact-checker. Ie, the primary questioned they answered was, did the developers deliver quality code? After all, isn’t that what Quality Assurance means? It is literally in the name. In practice, if all your QA team is doing is finding bugs left behind by your developers, then someone is dropping the ball. 

Bugs in the code should be incidental, and if anything, you should expect there to be no technical bugs at all. The work of catching bugs is to be done by an automated system. If you employ a best practice such as BDD or TDD, then you foreclose the issue by design.

So how then why do QA’s test? In this entry, I will be exploring my view on this question.

To build a shared understanding.

I believe as many people as possible should have in-depth know-how of the system.

To clarify my terminology, I don’t just mean knowledge; I mean know-how. Knowledge is what you get from reading test cases; know-how is what gives you the intuitive feel the test case is incomplete.

 It is unlikely the QA was there during upstream activities such as sketching, UX or writing user journeys and even in enlightened organizations when they are, the actual app is almost always different from what you originally envisioned.

Thus you must allow your QA access to incomplete versions of the application, let them experience the frustration of the dev team as they get the MVP out. Through this process is how they will come to understand the edges of the system.

By having as deep an understanding of the system as the developer, they can then provide a useful sounding board and insightful ideas as to how the development team should continue developing the product 

To assess product value. 

A lot of opinions abide about Tech being either a cost or profit center for the organization. I think this dichotomy is too simplistic. Still, If we commission work which takes two sprints to do, the best we know beforehand is we have cost the company salaries for a team for at least a month. The only thing the business knows for sure is they have a few more lines of code in their product, whether this translates to value is a whole other story. 

Developers are by their very nature more interested in the technical aspects of their work. They will focus on technical metrics such as code coverage or cyclomatic complexity.

 While QA’s can also be technical, for the most part, they tend to focus on metrics which the business can translate to value such as time to input a record, ease of reaching various relevant action items, etc.

Combined these two strengths, what you get is a technically superior product which the customers can use.

To assess “Look and Feel.”

On one of our solution evaluation meetings, someone mentioned GSuite is built for agility while office suite is built for power. This statement doesn’t speak of objective truth but instead, refer to an essence of the offerings.

 Automated testing for such features would be almost impossible. Imagine trying to automate testing for an accent. Deciphering a Kikuyu from an American accent would be instantaneous even for a young child but would likely require state of the art AI to be automated.

 Cultural factors also come into play here. We live and breath the culture we are born into and can tell what goes against the grain without being able to explain why. A QA being human comes with the capability to pick apart nuance built-in.

To come up with and test edge cases.

In demos, developers naturally incline towards the happy case, after all, its what they put most of their focus on. As part of the culture at Twiga, we always insist you start by showing us what wouldn’t work. Ie, triggers the error message.

QA’s are usually able to see beyond the most glaring flaws. For example, what happens to an integer field if you add a space at the beginning? Or even better able to think up scenarios which make sense individually but not as a bundle, for example, Can you order sugar and have it packaged in nets?

What does the QA do in your team? Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchex





Stages of a task: Back to the basics



Somewhere in my career, I came across the realization, just because there is a right way of doing things, and I am doing it, doesn’t mean it’s the only way of doing it!

For example, I came to find if I type/write as the meeting goes on, I can prevent myself from daydreaming. I concluded those who didn’t either were not schooled in the technique or were just not interested in what was going on. Of course, I was wrong, some write notes after synthesizing only the essential points, and there are incredibly bright individuals out there who don’t need to write a single letter the whole meeting yet will remember precisely what was said.

Underlying whatever practices we chose to adopt, there are several ideas so fundamental, almost all effective methods build on top of them. Years ago I discussed what that might be for agile: https://blog.chenchatech.com/2017/10/the-dna-of-agile-practices/

In this entry, we will be looking at how to think about the various states of a task. I hope you find the ideas here as useful as I have.

The Inbox

The human brain wants everything done NOW. If you ever get a hunch, for example, you want the idea implemented immediately. Since the physical world carries a limitation on the number of things we can do, we learn to make a mental note to do it sometime later or even worse push the pesky idea out of your head. At least that’s how I did it until I came across the concept of the Inbox.

The Inbox is an infinite list of all you can do sometime in the future.

It’s everywhere, just after you have had your lunch, the empty dirty plate sitting in front of you is now part of your Inbox. The email you just received from your boss is part of your Inbox, so is the missed call.

As a newly minted leader, you will soon face an incredible inflow of new items. Creating a list with all the items to be done should help immediately calm you down as you now no longer have to think of all that you are not doing but rather have the much higher level (hopefully to match your higher salary) task of choosing the most important things to do!

Taking us to the next step.

In Progress


I am not sure if it’s Einstein who said it, but it conveys my point. You don’t have infinite capacity. This simple fact doesn’t change, no matter how big your team is.

The implication being you must select some items from your Inbox (remember this is an infinite list) and put some of it in your In Progress list.

Your In Progress ideally is bounded. For most teams, it’s per week and for software teams two weeks. Yes, this is what is called a sprint.

You must always carefully monitor your In Progress work. If you can’t do it all, then actively remove items from it back to an Inbox, Waiting or On-Hold. We will discuss the states mentioned here next.

In Waiting

I find the term independent man or woman to be an oxymoron. Nothing, indeed no human can survive outside of an accommodating synergetic environment. Are you feeling some indignation? Perhaps consider the device you are using to read this piece, think of all the people who were involved in the design, manufacture, and distribution. Even if you somehow did all these activities, you would still need to charge the dang thing and have other people organize for its connection to the internet.

As you move to higher positions within your organization, this reality will arise from the background to hit you as you realize there is almost nothing you can do without the cooperation of others. Everything you send out ends up first in their Inbox before making its way into the In Progress. So how does that task sit from your side in the meantime? In Waiting

For example, If you are busy doing your development work and come across a page which needs a designer, say the payment receipt. The new task now flows to design. To declutter your job, move it to the In Waiting list.

Sometimes, things get stuck In Waiting, not because of another party, but simply because you need to wait for an event to happen or uncertainty to resolve. For example, if you are waiting for a specific day to reach before say banking the post-dated cheque.

On Hold

If the In Waiting had a grandfather, it would be the On Hold state.

A task graduates to this state when the time horizon for this task is unknowable or so great, you do not need to worry about it, for now, there is nothing you can do about it.

For example, if you have applied for a job in a big corporation, they may take months to get back to you. There is no need to clutter your In Progress with this kind of work thou technically it is there

Will not do

As I mentioned earlier, the Inbox is a list of all you “can” do, not all that you “will” do. Not everything you set out to do turns out to be worth the time and effort.

Perhaps you had a plan to watch a movie, on the way, your friend tells you the plot. Aside from educating your friend one or two things about spoilers, you also need to update your task to now become “Will not do.”

You can also land on this state if a significant change happens in your life, which means your priorities changes, and out goes most of the tasks. For example, if your company fires you, a lot of functions suddenly change state to this one.


Finally! The most pleasant state. As work moves through your stream, it will eventually achieve a “Done” state. The task met its objectives, or at the very least, there is nothing more you can do.

The feature is now in production! Congratulations!

A note on tools

Board tools such as Trello or even your plain old wall split into “Todo, Doing, Done” are effective at managing all this.

In my opinion thou, I find some states need more attention than others. More specifically, the In Progress state. Since the tasks in this state represent commitments made either to others or yourself, you must budget for them in your calendar and wallet.

There is no point in having an In Progress task to buy a car if you don’t have the cash. Also, if you don’t have the time cut out, then tasks here will never get done.

Finally, It’s ok to have nothing literally on in Progress, sometimes we all need a break.

Did you find the piece interesting? Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchex