All software projects are challenging, although not all at the same level. Even the easiest projects are tough and demand attention in order to make good decisions and adjust the course.

There are plenty of ways of doing so, like sprint retrospectives, where the good and the bad things are exposed and discussed. But, another very good way, which is not seen very often, is project retrospectives.

Project retrospectives allow a more deep analysis of the current scenario. Not a code analysis by itself, but how stakeholders handle changes, how the team sees the future, what were the challenges the team overcame, where the team failed and all those questions that apply for sprint retrospectives, but applied for the whole project, since it started until the day of this retrospective.

As stated before, you can list good and bad things, like any other retrospective, and discuss about how to act against those bad things. But what I came to tell here is about a technique that is not very common: questioning the good things.

Where wild things are

The human mind is complex and so is the knowledge acquisition which is not always organized or systematically explainable. Somethings you just know and you can’t explain why. This happens because most of it is empirical knowledge (or empirical evidence), i.e., knowledge that you obtain by observation or by experience.

I remember a toy I had, a train that would run a few meters if you pressed the button. The problem was that everybody, at first, thought it was broken, but I knew how to correctly press the button in order to make it work. When other toys of mine stopped working, I always tried pressing in different ways, including the way that my train responded to, because I had an empirical knowledge that it could work, because it worked before.

If you apply this logic to software development, you can see a lot of practices, like code reviews, plannings, retrospectives, which now are documented but previously were just known. People are always improving books and creating new techniques based on what already exists by observing and adjusting. This is how things take shape.

But, there’s a problem when empirical knowledge is used: you don’t know if your context applies in this case and you have no clues if it will work or not. It’s like taking a guess. In order to avoid that problem, you need a formalization of this very same knowledge.

By formalizing empirical knowledge, I mean to understand what happened. Instead of just pressing buttons of the train all the time, formalization would require some electrical investigation and checking why it works when pressed in a specific way. The same thing could be done in the software development life-cycle, in order to keep improving ourselves.

How to formalize

Well, back to the good points listed in a project retrospective! I’ve been in a very few amount of sprint retrospectives where the good stuff was analyzed and the way it was analyzed made no difference for me. I just couldn’t see the value of getting a plan to keep that job. It was good, it obviously should be continued.

But there is a technique called five whys intended to “discover underlying conditions that contribute to an issue”¹, which can help you dig into facts and scenarios where a better analysis can be done.

But only “whys” won’t drive you to the right path. You will need more interrogative words like what, when and who. You need to understand the facts that lead to a good thing and then get the theory around the issue.

Let me share this example that happened to me and how far it went. In a project retrospective once, we had a good post-it with the text “UX”, the questions began:

In order to keep this example short, I’ll stop here and state our final lesson. Instead of just stating “UX are good for the project” we’ve figured out that “UX is good for the project if the UX experts are close to and aware of the business. UX work must be done at the very beginning and discussed with the whole team to check technical availability and better scheduling.”

Hope you’ve enjoyed the tips. If you do something similar, please let us know in the comments below, and start sharing knowledge =).