Let's build things right (this time) mindset- Does it help at all

Overview

A common belief in (tech) teams working on wicked problems is that they start the project with some wrong choices or missing information. Whilst this is very common in complext problems, teams always tend to ‘blame’ the first steps of the project as opposed to searching for adaptation.When teams stick on this mindset, they tend to repeat the same mistakes over and over again and when they retrospect the see only the mistakes or wrong choices made in the beggining and overlook the importance to learn and adapt. This article, presents this mindset as a historical recurrence trap and suggests some methods that will (hopefully) help teams spot and escape from it.

introduction

Mark Twain once said, “History never repeats itself, but it does often rhyme”. In school we were taught that people should learn from history, meaning that humans need to learn from past mistakes. However, people really struggle to follow this rule of thumb- and there is a reason for that. Indeed, apart from politics and sociology, people face the same challenge in everyday lives meaning, family, work and personal relationships. In this short article, I will focus on the “Historic recurrence” effect in technological teams.

Problem description

A new project is about to commence and depending of the selected way-of-work the team is somehow structured. While discussing the what, the how and the when, one of the most used phrases noticed amongst peers is, namely, the “let’s build it right this time” or “let’s organize it better”, “let’s sell it better”, “let’s design it better“, following the “Let’s it better” structure. Ideally, it should stop there, the statement should be followed by the “do it right” solution and the project should run within budget, time and scope leaving the end user/customer satisfied. However, it seems that this phrase is quite vague depicting lack of structure, processes, or even experience. Let’s dig a little bit into this phrase.

Analysis

This statement should not be underestimated. It is a strong indicator that some team members were not satisfied by the way they worked in the past or the result of their work. What is difficult to understand is that this can vary across team members according to their objectives. For example, business people try to optimize the outcome within the given budget. Project managers try to control the budget, scope and time while development teams try to generate as much value as possible for the customer with the minimal possible technical debt. These teams need to find a balance and it is not guaranteed at all that all of them will be satisfied at the same time. For business people, this statement could refer to their disappointment regarding budget and revenue. Project managers could use it to highlight to the team the importance of providing more “accurate” estimations. Finally the development teams could refer to the technical debt as well as prolonged latencies in getting feedback from the customers. However, teams should comprehend that they are trying to jointly optimize different objectives. This is very common in Machine learning tasks formulated as multi-task and/or multi-objective problems or constraint optimization problems, where an objective is optimized subject to several predefined criteria. As Machine Learning teaches us, we are always responsible for what we choose to optimize against as well as how we evaluate out results and the tradeoffs within. For example, you might have the right objective but the training data might not be representative of the problem or we might be interested in reducing False Positives in favor of increasing the False Negative Rate.

What you can do?

Here are some suggestions to help your team be better prepared and well-structured next time:

• Unlearn

Within complex projects/products it very common that more is unknown than known. Agile methodologies cope with complexity by iteratively working on solving the problem by taking one small step at a time and checking both the output and when to go next (review) as well as the way teams, that adopt them, work (retrospective). In this manner, it often takes a team to unlearn in order to drop the tools used to work until now and build new strategies.

• Avoid the mount stupid

The well known Dunning-Kruger effect tells us that oftenly people tend to overestimate their abilities leading to poor decisions and those decisions are later transformed into project failures, technical debt and/or customer dissatisfaction.

• Engage people with range

Todays wicked problems require generalists. While specialists in a team can do the job optimally, generalists can also help to do the right job.

• Hear all the voices: Imposter syndrome

After working for many years, you realize that things you do actually work and that your ideas are usually applicable. Lot’s of people however, believe that this is due to luck and they keep believing that they do not hold any expertise amongst their peers. In a similar manner, some juniors might have a good idea or a proposal on how to implement an idea, but they may hold back thinking that they have to wait until they “grow up”. This is known as the imposter syndrome, so a team needs to learn to also take onto account people that are not always heard in a discussion.

• Define goals and objectives.

This can include the vision and key deliverables but it can go beyond that. A goal-condition formulation can be used in deliverables where the acceptance criteria should be clearly defined. Therefore, acceptance criteria describe the sweet spot between the business, the project and the development teams facilitating early estimations and fruitful discussions.

• Define and revisit priorities

As Heraclitus said “The only constant is change”, and during a project lifecycle, priorities are no exception. Clearly communicating the effects of these changes alongside with the strategy will help the teams to align to a common goal.

• Decide what to measure

A team has the ability to measure anything is considered valuable to them, not only in the current project but also in future ones. For example a development team can measure the technical debt, the project management can measure the planned value.

• Ask team members to propose new methods

Typically, this should take place in retrospectives. For scrum teams this can happen even in a weekly basis and it can be embedded in the Definition of Done.

• Processes

If there is a flaw in a process make an attempt to fix it. Keep notes each time an issue raises during the project’s lifecycle and try to find a way to fix it within processes. The most important issues with the highest frequency of appearance can be prioritized.

• Select a framework that will guide you

Project Management techniques will help your team to navigate through the various tasks they need to implement while keeping their effectiveness. Those techniques will also help in coordinating, recording and evaluating project activities minimizing that way the chance of a derailed roadmap.

Epilogue

As history teaches us, even with past experiences and large amounts of data, it is not always easy to make wise decisions. Whilst most of the times relying on data and being flexible to adjust as you learn more will help you and your team to succeed, the complexity and the uncertainty can still affect your decisions and therefore your results. In case something like happen, you should try to learn as much as possible from this new experience and generate as much data as possible for the next time you will face a similar challenge. This will ultimately change the “let’s build things right this time” to “are we going to achieve the required goal with the current choices we make? ”

Hope this helps!