Assumptions are not facts

I was recently in the non enviable position of recommending changing direction of a large set of projects after 6-8 months of planning

For clarity's sake: By large I mean 7 to 8 figures multi-year program . By changing direction I mean Changing one of the core technologies and Reorganizing the order in which we were building the system; bringing some deliverables a year ahead of the original schedule.

The original plan and technology recommendation were made before I joined the team, by people who I respect a lot. So, why the change?

I must clarify that I normally start with the assumption that people before me had good reasons to make the decisions they made. But following what you will read later in this post, I decided to ask "why?". I needed to understand those decisions to be able to represent them to senior management.

What I eventually realized was that the original plan and technology were based on a set of assumptions that hadn't been validated for 6 to 8 months, meanwhile the understanding of the system had increased and there had been some important changes to the organization.

The team was under pressure and hadn't stopped to validate the assumptions. What's more, many people in the team didn't even understand why the current direction.

At that point I recommended to STOP and verify assumptions. We brought the team together and brainstormed assumptions, identified conflicting assumptions and, most importantly, discarded the incorrect ones. With a new set of assumptions, we verified the original decisions and agreed that we would benefit from changing direction.

Assumptions are not facts
A very common problem with assumptions is that, after a while, they are taken as facts.

The most effective way to eliminate this problem is to avoid assumptions altogether and make our decisions purely based on facts. As the old saying says: If you assume you'll end up making an ASS of U and ME.

This is of course, easier said than done. Frequently we need to make decisions even when we don't have all the facts.

Here is what has worked for me:

• Identify assumptions
  This is probably the hardest part as not all the assumptions are relevant and most of us do not even realize when we are making assumptions. A good way to collect assumptions is to start from the decisions. Ask "Why?" if there is no concrete evidence for the answer, then it is an assumption. Another way is to ask "under which circumstance would you change the decision?". Usually the answer highlights the assumption.
• Document
  Write down and share what the assumption is, but most importantly, the consequence or impact of that assumption. This is, if the assumption changed how would the decision change.
  
• Verify
  Set the time to prove or disprove an assumption. If you can, then there is one less assumption to worry about.
• Challenge
  By challenging your own and other people's assumptions you avoid inertia.
• Review
  It is a good practice to review assumptions at predefined stages in the development cycle. Even more important is to review them when you identify change.
• Act
  If an assumption changes or is disproved, bring it up for discussion, review the decisions made based on that assumption and if necessary, recommend changing direction.

Doing the 180
It is not easy to do an about-face after having given all your arguments for the current decisions. However, having clearly stated assumptions can reduce the pain, and certainly show people that you are a professional that is not afraid to change directions if conditions change.

I'm back blogging. This time more agile

I'm back blogging. After a few months hiatus, I've decided to start posting again. First I thought it was that going on vacations had changed my rhythm, then I thought it was all the workload of an important project, or maybe the summer.

Finally I realized what it was. I chocked trying to do too much at once.

My original plan for this blog was to write my thoughts as they came. Short posts that wouldn't bore people. Over time I would add additional related thoughts. Eventually, those thoughts would be associated by the labels.

In methodology terms: I was planning to write things "agile". Write as much as I had in my mind.

Then I came to the topic of Troubleshooting. I had a simple thing to say but as I wrote, I thought I could add more and more, then I realized I had to add structure, and reword things and... and... I got stuck. Instead of publishing what I had, and later improve it, I went for a big bang approach.

If that sounds familiar it may be because that's how many software projects get cancelled. They start with a simple, great idea but instead of implementing it and making it evolve, we try to improve the idea and add things to make it perfect on the first pass. As the idea gets reviewed by other people, new features are added to the list. We start thinking bigger, and bigger needs better architecture. As it gets better we need more input; after 6 months or a year of reviews and talks and meetings, still, nothing to show for it.

Most likely, releasing early could have shown if the idea was good or not. And the features that were really missing would have been added over time. 6 months or a year later, after learning from our mistakes, we would have a system that we could improve, refactor, even rearchitect, but we would be doing it with real usage data, not pipe dreams in meeting rooms.

So, that's it, I have decided to start posting again. Sometimes the ideas will be raw, most likely I will get some wrong, but as I get feedback and receive comments and discuss with other people, I may come back and review them, or even write new posts with a clearer idea.

May this post be the first where I spill my raw thoughts.