I noticed that everyday I learned something new was a good day for me. Any day I felt I got better at something had a special meaning to me: learning how to play a new song, learning a new chess opening, experimenting with photography, etc. At that point I felt like learning and sharing what I learned with others was something meaningful, and maybe the meaning of my life.

Do you know who agrees with me? Neil deGrasse Tyson a random 6 years old kid. 10 years ago the kid asked Neil about the meaning of life, and if this kid followed the advice he received I bet he’s very smart 16 years old today.

To learn or not to learn, that is the question

Do you know who else likes to learn? The Machine.

Machine Learning is not really a new concept. I remember studying it in college and even taking a course by Andrew Ng around 2013 when I was trying to come up with a way to introduce a classification algorithm in a product my company was creating.

But we never had enough stolen data or computational availability to make something like the LLM’s we have nowadays, so the models we created back then were domain-specific and could never do what the LLM’s do today. We learned a lot while exploring the concepts, and even though the results weren’t astonishing it made us geeks quite happy.

What bothers me with the current scenario is that learning is losing meaning for some people because they see no point in spending their time learning a craft just to be outperformed by an LLM in a couple of seconds.

For example: I like to draw all images I use in this blog. It takes time, yes. But as I learned from my shrink after about 5 years of therapy: You don’t need to be productive at every moment, Mario!

Why would you write code if the LLM can write it 1000x faster?

Well… Why would a 79 years old Drauzio Varela run a marathon? He took almost 5 hours to cover that distance! Had he taken an Uber he would achieve the destination in 30 minutes! He was able to do that because he trained hard since he was 50, and during that journey his muscles, his heart and his brain learned how to endure such a strenuous effort.

My point is: There’s value in the journey, and learning is always a journey.

Creating vs Reacting

During the Regional Scrum Gathering South Africa, Chris Garvey made a fun wordplay with the words CREATING and REACTING, and it really fit the theme of this post. He used the same letters to create two different words, and these words represent two very different ways we can work with LLMs. After all, how much can you learn when you’re just reacting to the tsunami of content generated by LLM’s nowadays? Can you use LLM’s to actually develop a craft and learn as you move forward?

Basically, I see two different approaches when working with an LLM:

1- Can you write a text for me? Fast. Potentially no learning involved.

2- Hey, I wrote that. Can you give me some feedback? Slow. Potentially some learning involved.

I use the second. I write my posts, and that gives me an incredible leverage while using an LLM to provide feedback about what I wrote. For one: If the LLM provides a feedback that doesn’t make sense, I ignore it. Or question it.

Besides that, I have a Claude project with all my blog posts and a values.txt file where I state my personal mission (the same content you can read on my About Page). Whenever I write a new post, I ask it to:

• Hold myself accountable to my values
• Find meaningful connections between the current post and previous posts I wrote
• Find typos and help me to improve my english vocabulary
• Check people I mentioned and suggest diverse people so I can burst my bubble and do my part in making the IT world more heterogenous.

I can’t tell you how much I learned by doing that. I found many people outside the AI echo-chamber that is LinkedIn, and I got a book recommendation that changed the way I feel and relate to LLM’s in general: “The Empire of AI” by Karen Hao. It hits hard, and even though I knew some of the problematics behind the whole AI ecosystem the book shed light to other impacts I was previously oblivious to. In its later chapters it also showed how LLM’s and SLM’s can be created and used in a more conscious way and produce real benefits to the humanity as a whole.

Not because the final posts are better written (I can’t even say if they are), but because the journey of writing started making me learn more. And the same idea can be applied to programming, or drawing or whatever you find pleasure in doing, as long as you keep creating instead of just reacting to what the LLM created for you.

I still think that learning gives meaning to my life, and I try to do that as much as I can. It’s harder now, with all the AI noise around us, and still… not only it’s still possible to learn, but we can consciously choose to do so when we inevitably interact with the LLM’s in our daily lives. Creating is still a choice we can make, and learning is the outcome we might get out of it.

Most people (myself included) are learning how to deal with AI in productive ways. But notice that this is a lesson that comes with a dependency: take the LLM away, and you don’t have a valuable skill. And guess what? LLMs aren’t free. You can use them to learn how to work without them, to burst your bubble.

That’s what I’m trying to do: exploration. Learning for the sake of learning. I’m trying to create more, and react less.

But then came enshittification.

Metrics, always metrics

Substack is a platform where some authors release their content for free, while others charge for more premium pieces. So, what becomes relevant for writers?

• Number of views
• Number of mentions
• Number of subscribers
• Number of paid subscribers

And that’s all fine, perfectly normal. There’s a lot of good content there worth paying for, and many people competent enough to make a living from this model.

The problem isn’t all the authors, but what the platform does to try to make these metrics attractive enough to keep authors there and attract new writers. Over time, Substack added:

• A Twitter-like feature
• Popups constantly asking readers to subscribe to the newsletter
• A default option to subscribe to ALL substacks that an author recommends when subscribing to their newsletter

Reading a post on Substack became an exercise in patience, and I started feeling bad about making people who dedicate some of their time to read what I write go through that. So my desire to write there kept diminishing.

Where I drew the line

As if all that wasn’t enough, the metrics made completely despicable newsletters become interesting for the business because they generate revenue for the company.

And that includes Nazi newsletters.

That’s when leaving Substack stopped being an option and became a necessity for me.

Where did I go and where can you go?

If sending newsletters is super important to you, Ghost is the best option. It’s open-source, easy to set up, and quite lightweight. Many people have been making this transition, and in terms of features, it’s the closest to Substack.

If you just want to write and images aren’t very important to you, you can use WriteFreely. Since it was made in Go, it’s quite lightweight (in my server test, it consumed only about 50MB of RAM!). The writing experience is pleasant and to the point. Interestingly, WriteFreely was developed as an alternative to Medium because its founder got tired of Medium’s enshittification.

If you want something free, with a high level of customization and full ownership of your content, the best thing to do is use a static site generator like Jekyll, Hugo, or Astro. This blog was made with Jekyll, which is built in Ruby and has been around longer, and I ended up going that route because I had already acquired a theme that fit what I had imagined for my site. Hugo is a more modern option, and probably the best choice here, especially if you plan to write in more than one language.

Another advantage of static site generators is that you can host them for free on GitHub Pages, for example. You don’t even need to pay for a server.

If you want something to read, I strongly suggest using an RSS Reader, which is nothing more than an app where you add the blogs you like to read and it notifies you about new posts without cluttering your email inbox. RSS is also a more conscious form of reading: you need to choose what you want to read and follow, and no algorithm tries to push anything else on you.

Currently, the software/services I use are:

• Scaleway, to host my site.
• Typora, to write posts.
• Plausible, self-hosted. To collect metrics while respecting your privacy (no Google Analytics here).
• Procreate, to create the images I use on the blog
• Vivaldi, a browser that also has an RSS reader

But… what about the newsletter?

Well, for now, it doesn’t exist, but I might create one in the future. I sincerely thank everyone who subscribed to the newsletter on Substack, and I hope you’ll continue following what I write here.

I didn’t want to write anything superficial about it, so I tried to read it carefully, with low expectations, and made some notes along the way.

It isn’t flawless…

Scrum is a framework and therefore is incomplete by nature. It gives us the task to complete it with practices, techniques and tools, and that’s the best part of the Scrum Framework in my opinion.

When I first heard about the expansion pack, I feared it would fill in the gaps and make the entire thing more prescriptive, and I think most people shared the same feeling. The authors managed to avoid that problem quite well, however, there were other problems I found.

It isn’t an expansion pack

Instead of just adding new information, the authors also changed some original concepts (ex: reverting to the use of the word roles instead of accountabilities).

It also says that the Product Backlog Refinement might be an event, which I really don’t appreciate since in my experience this kind of language fosters a mechanical behavior.

It’s not a single document. As the authors state at the very beginning:

“This document is a collection of independent works. Each section retains its original license or copyright status, as indicated.”

So the reading is a road full of bumps, and sometimes repetitive.

Other than that, I’d say it’s pretty much harmless.

It actually might help those struggling with Scrum

I’ve been teaching software development and Scrum since 2013, and I dare to say that a good deal of the questions people ask me during training sessions can be answered by the expansion pack.

And most of the time the SGEP managed to do that by expanding on the WHY of things, with a huge focus on empiricism.

More words make it easier to understand

Let me give you one concrete example: the Sprint Review. The original Scrum Guide is somewhat cryptic when it says:

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations

Scrum Guide, 2020

It also says that The Product Backlog may also be adjusted to meet new opportunities.

In my classes I often take some time to discuss that: we need to determine future adaptations, which means changing the Product Backlog somehow. Therefore, a Sprint Review that doesn’t change the Product Backlog is something that should cause some reflection. Also, if the Sprint Review is a mandatory event, it means that the Scrum Team is not passively open to change the Product Backlog: they are actively searching for these changes.

The SGEP uses more words to describe that:

“The Product Backlog (the what)IS adapted” - Not “may also be adjusted”, but a strong “IS”.

This is the kind of difference that matters to me. Reinforcing that Scrum is about learning through experimentation so we can use fresh information to develop stuff.

Focus on Empiricism

The main problem most people have with Scrum, sometimes even without noticing it, is that they use the framework believing it will increase development speed. That often puts Product Owner and Developers in confrontation instead of collaboration. This problem is so common that the last Scrum Guide update change the term “Development Team” to “Developers”, and the explanation on why they did that was:

The goal was to eliminate the concept of a separate team within a team that has led to “proxy” or “us and them” behavior between the PO and Dev Team.

There is now just one Scrum Team focused on the same objective, with three different sets of accountabilities: PO, SM, and Developers.

- Scrum Guide 2020 Revisions

Don’t get me wrong: I do like this change. But for beginners or even people who have been using the Scrum Framework in a dysfunctional way for a long time that’s not going to solve any problems. I mean, neither does the SGEP, but at least I think it did a better job at trying to achieve that.

For example, the SGEP:

• Clearly states that being a feature-factory or a discovery factory is not desirable

• Establishes that the Product Owner needs to effectively communicate outcomes

• The Product becomes an artifact with outcome based metrics

The SGEP also creates the Definition of Outcome Done, and I have mixed feelings about that. On one hand it adds yet another piece to the puzzle and makes the Scrum framework more prescriptive, but in the other hand it might be specially important for those beginning or struggling with Scrum.

Talking about that, the SGEP also provides some valuable insights for those starting or struggling with their job as Scrum Masters.

Provides better directions to Scrum Masters

The original Scrum Guide describes the Scrum Master in half a page. And if you have a good deal of experience with the framework that’s more than enough.

The SGEP however gets more into the specifics, but without limiting too much of your work. It states for example, that the Sprint Backlog should have enough work to get started, e.g., start with one or two Product Backlog Items toward the Sprint Goal. And you can read this sentence as: “there’s no Definition of Ready”.

Another example is the Product Backlog: while the original guide states that the Scrum Master must find techniques for effective Product Goal definition and Product Backlog management, the SGEP adds some valuable information on top of that, such as: A smaller Product Backlog often provides more Transparency or even the suggestion of using an Outcome Criteria for Product Backlog Items.

Then again, I know these are old news for some. Yet it makes obvious some of the things people often struggle to learn.

So, is it valuable?

It can be. But not for everyone. But reading it is a good exercise anyway, so go for it. The focus on empiricism is what made me like it, and it’s an expansion pack, which means… it’s optional anyways. You can also pick some of the ideas and apply them if you don’t want to add it all.

So, if you’re doing well with Scrum, you don’t need it. After all, you’re probably already doing most of the stuff described there.

If you feel the Scrum Guide is cryptic and leaves you with a feeling that it should elaborate a bit more on some aspects because you’re stuck, then the Scrum Guide Expansion Pack might be a good thing for you.

Now, let’s go back to our pitfalls and also talk about a “war” that’s being going on for the past 40 years: the Editor war. It might sound like a silly war, or a simple matter of preferences, but trust me: it’s not just geek tribalism, it’s about fundamentally different philosophies of human-computer interaction.

I’m a NeoVim user. That means I’m one of those geeks that rather type code in the terminal istead of using something more modern like VSCode. While using NeoVim I never use my mouse or touchpad: I just type stuff and use a bunch of key combinations to navigate through the code. But I’m not alone! The first Vi editor was created in 1976 and since then its popularity has only grown between the geekiest of the software developers.

Why? Well, let’s explain that while talking about one of the pitfalls I mentioned in Munich:

Pitfall 4: The Coding Tunnel Vision

Vi and its siblings (Vim, Neovim) became popular because they allowed developers to navigate the code faster. Instead of moving your hand to your mouse, scrolling down, selecting a part of the code you want to change and then typing the change, these editors proposed a different idea: they would have modes. While on INSERT mode, everything you type on your keyboard would appear on the screen, just like it happens on any other editor. But in NORMAL mode, each key on your keyboard can be used to navigate the code.

For example: if you press 3wce you would instantly change the content of the third word in that line. (Something like: Go to the 3 rd W ord C hange until its E nd).

It basically creates a dialect so you can tell your editor where you want to go and what you want to do with your code without having to do it using mouse, menus, etc. And accelerating how we navigate the code is important because software developers spend more time navigating and understanding the code than writing it.

A chart representing the results of a research on how developers spend their time

So, why are we focusing on using LLM’s to generate code when we can also use it to help us understand the code? I mean, they are great coders, I’m not denying that. But in my experience they can provide much more value explaining the code instead of just creating it.

Here’s a practical example on how I did that: I’m currently writing a software to improve the practical activities I run in my classes. And at some point I decided to ask Claude to explain my own architecture to me. Because Claude excels in text output I thought it would be nice to use a tool like Mermaid, a tool that transforms text inputs into neat diagrams. I asked Claude to explain the structure using MarkDown and Mermaid, and I pasted the result on a text editor compatible with both technologies called Typora. Here’s the result:

That’s a great piece of documentation that can be used to explain both the developers on my team and even the LLM itself how the architecture works! Specially because the diagram can be read by the LLM as a simple text input, minimizing the amount of tokens consumed in each interaction.

Thing is, no matter if you wrote the code manually or if an LLM wrote the entire thing for you, you’ll still be responsible to the consequences. Therefore, understanding what’s going on is fundamentally important.

Remember: if something works and you don’t know how, when it stops working you won’t know why.

Pitfall 5: The Bulk Bias

Some people are still complaining about the quality of the code generated by LLM’s and I strongly disagree with this take. In my experience, the code generated is actually pretty good.

What bothers me is the code quantity.

Specially because I don’t believe in “vibe coding” (that is: trusting the generated code and not even taking a look at it). I need to review the code and make sure it’s doing what it’s supposed to do because… I’m a responsible adult? So, when the LLM changes 8 files and adds 200 lines of code for each prompt I make, my job becomes extremely painful and well, unfun. I tried multiple approaches and different prompts to reduce this problem but I’m yet to find a solution.

To be fair Claude 4.0 presented a great improvement when it comes to this particular pitfall, and I think we’ll get a definitive solution to this one in the near future. But it’s not quite there yet.

One prompt, MANY changes

What I feel is that instead of helping us to walk faster LLM’s are helping us to take bigger steps. Both approaches can help us to cover a longer distance in the same amount of time, but the later also comes with a high cost when you’re walking on the wrong direction. The business model also contributes to it: when I use Cursor for example, I have limited tokens/interactions, which incentivizes me to take the most out of each prompt.

Conclusion

Writing about working with LLMs is a strange thing. I wholeheartedly mean everything I wrote in this post today. But things are changing fast, and this post might age like milk or wine depending on the upcoming developments. If you value learning more about this topic, I strongly suggest you to do two things: use it to create something instead of just reading about it on LinkedIn (even better: get away from LinkedIN altogether), and try to read different takes about the subject. Karen Hao’s book “The Empire of AI” might be a good start.

The funny thing in this conference is that I went to two subsequent talks that directly connected to what I presented: Nigel Baker and Paul Goddard talked about Pair Programming (and I’m still disappointed they didn’t mention Penn & Teller in their pairing examples) and the final keynote by Henrik Kniberg that talked about agentic AI in software and agile software development. So, I’ll also connect insights from their presentations to enrich our conversation. To do that, I’ll change the order in which I initially presented the pitfalls.

Pitfall 1 - Written Fixation

My first complaint about how most people have been using AI was about how we keep writing and using text as the only way to talk to our LLM’s. Kniberg used two different forms of communication during his presentation: voice and a napkin drawing. And that’s precisely what I was talking about: language has limitations, and these are old news. Nietzsche notoriously said that Every word is a prejudice and William James challenged our ability to comprehend the meaning behind the words with his squirrel going around the tree anecdote.

If you want to try how it could work, you can integrate Aider with ChatGpt to use your voice to program (and maybe that could be my next post as well). But if you don’t want to go that far, draw , take screenshots to use as examples, basically: experiment.

A diagram showing how the modules of my application should interact with each other

Now, the diagram immediately takes us to the next pitfall…

Pitfall 2 - Atrophy to Learn

If an AI can code, why would I learn to code? , well… that’s an interesting question. In my talk I mentioned that the code generated by the current LLM’s (like Sonnet 3.7) are actually pretty good, and often times better than what a human would write. And the LLM’s are improving faster than we are right now, so…

So we still need to learn. Look at the diagram in the previous section: it talks about software structure and how to organize the code. If you don’t know how to code, you can’t come with diagrams like these and your options will be limited. These limitations can lead you to dead ends and problems you’re unable to solve, and if your AI colleague is also unable to solve it then…

The dark side of the vibe

Like Nigel Baker and Paul Goddard said in their talk: pairing is a great way to learn. You will probably learn that different people use LLM’s in different ways, and you’ll have to figure out when to use each approach. For example: nowadays you can literally program an agent that would check everything your significant other posted on the internet and automatically buy them gifts at special dates. And they will probably be good gifts!

But is it a good idea? Well, I don’t think so. Simon Wardley proposes an interesting question to solve this dilemma, and by all means, if you haven’t watched his talk yet please do :

How much do you value a human involved in that decision?

And sometimes, when developing software, it matters. But then again: your decision making capabilities will be limited by your knowledge. So, keep learning (and try to pair with someone else so you can learn more and faster).

Pitfall 3 - The Monolithic Approach

I made a joke during my presentation and said that Vibe Coding should be renamed to Conversational Reactive Assisted Programming, or C.R.A.P.. Everybody laughed, and moments later we were all watching Henrik Kniberg doing an impressive demonstration using Cursor.

So, I think I’ll have to explain myself. :)

The term Vibe Coding was coined by Andrej Karpathy, and he said that the technique is “not too bad for throwaway weekend projects”. A key part of the definition of vibe coding is that the user accepts code without full understanding, and the AI researcher Simon Willison even said that “If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding in my book—that’s using an LLM as a typing assistant.”.

So, by that definition of Vibe Coding, I stand by my joke. At least for now. The concept of not caring about the code generated by an LLM can be a good idea, but only if we know when to use it , and for now it shouldn’t be a 100% of the time unless you’re building a prototype.

The thing is, if you don’t know how to code, Vibe Coding will be your only option when using an LLM to develop software. And isn’t really coding , because it’s non-deterministic: the same prompt might generate different results. I prefer the term Simon Wardley uses: Vibe Wrangling.

A slide from my talk: If you have more technical knowledge, you’ll have more options

Maybe in the future having Vibe Coding as your only option won’t be a problem, but we are not quite there yet. It might happen next year, in 2035, or it might never happen. But no matter the answer, learning to code is still relevant because it will expand your options. And that’s my main (and maybe single) critique about Kniberg’s great keynote session: I don’t think that Vibe Coding is an evolution of copying and pasting code generated by an LLM, for example. I see all these approaches being used in different contexts, and the decision will always come down to a slightly modified version of the question proposed by Simon Wardley:

How conscious do I need to be about the way this is going to be implemented?

For me the answer is still “quite often”. LLM’s are biased, non-deterministic and they replicate all the problems that were present in their training data. They will make mistakes, and some of these mistakes might harm people, specially in groups that are under-represented in the data used to train the models (you can and should check Dr. Timnit Gebru’s work). When we accept AI-generated code without full understanding, we’re inheriting not just the solution but also the conceptual prejudices embedded within it.

So, answering that question is something we’ll start to do more and more. And going back to Nigel Baker and Paul Goddard’s session: you don’t have to answer that question alone.

I’m constantly teaching and coaching people on how to develop better products, be it in CSM/CSD classes, as a consultant or as a mentor. I do have my share of stories to share during these events, but you know… while these stories are new and exciting for the students, I can’t say the same after repeating them a dozen times.

And besides… I need an excuse to touch code. :)

The Product

As a trainer, I try to create simulations so my students can learn by their own experience most of the time. That’s why in 2019 I created the card game Scrumchkin, for example. But since the pandemic, most of my training sessions have been online, which makes it really hard to replicate the same dynamic environment I had with the actual Scrumchkin cards in an in-person training.

So, I decided that my product would try to solve that problem:

The students should be able to learn complex subjects through dynamic experience and simulations.

It was a good fit after all: I have periodic classes where I can take the product to a field test and collect feedback and I have access to a community of trainers that could be interested in trying the product and providing a different kind of feedback.

As everything I needed was an excuse to start writing code, I was happy with that.

Decision: Pick an UI component library from the beginning and stick to it. You can change the whole thing later, if necessary.

Tooling decisions

I decided to avoid using a database at first, until I figure out what kind of data I want to store and how I want them stored.

Elixir (my go-to language) has something that does the job quite well: GenServers. I can use them to temporarily store data without having to resource to a database. The information will be there until one of three things happen:

• I restart the server

• An error occurs and the GenServer gets restarted

• I terminate the GenServer

This approach allowed me to move faster and forget about migrations, for example.

But, but… Mario! Isn’t it risky?

Risk depends on context. My training sessions are short, and in the worst case scenario I would lose about 15 minutes of time and the students would have to restart an exercise if a GenServer fails during the training.

So, it’s a risk I’m consciously willing to take.

Talking about failures…

I can’t say I’m doing pure TDD, but I’m writing a lot of tests. Specially because I’m using Claude to generate some chunks of code for me (I’ll write later on which chunks of code Claude is writing for me).

It’s really hard to use TDD with an LLM. These models generate huge chunks of code at once. Meanwhile, TDD is all about that incremental rhythm: one test, make it pass, and then tackle the next one. What I’m doing is writing tests for my GenServers, asking Claude to come up with extra tests I might have forgotten and then asking Claude to implement the functions that would make the tests pass.

I learned that tests are now way more important than they were before AI. When a LLM makes dozens of changes in your code, it’s impossible for you to guarantee that your code still does what it’s supposed to do. And I had Claude breaking my tests more times than I could count, specially when it tried to modify a lot of files at a time.

Decision: Using AI as copilot increases the need for automated tests. And the AI can help you writing your tests as well.

Design decisions

I acquired tailwindui a long time ago and I enjoy using its building blocks to create my applications. I can use it to make my product look nice without spending much time over-refining my design.

Of course, being a non-designer I also struggle with the overall layout. Even though I have beautiful blocks to work with I’m still pretty capable of messing the whole thing up when putting them together. So, sometimes I use Lovable to understand better ways to visualize how the components could go together.

Decision: Try to postpone having a database. Think about different ways to do that so you can learn more about your data before committing to a model structure.

Authentication mechanism

When I’m in a training session, I don’t want to have my students creating accounts and remembering passwords for an experience that will last for 2 or 3 days. I also don’t want to spend time fiddling with an authentication mechanism.

Now, I know some of you are thinking: “ Hey Mario, it’s 2025! You can set up an authentication mechanism in a couple of minutes ”. Maybe yes, maybe not. But I’m positive that having a full authentication mechanism would instantly add at least a bit of complexity to everything else I want to develop.

So my mechanism works this way:

You tell me your name, I save it to your session and you’re good to go. Unless you’re the trainer, of course. Then all you have to do is enter your name as SUPER_SECRET_PASSWORD and you’ll have access to advanced features.

Is it safe? No.

Is it good enough to use in a class with 20 people? Definitely yes.

Decision: Authentication comes in the last responsible moment. Think about it, work around it and maybe you’ll end up creating something innovative.

Deploy

I recently read the amazing book Simplicity by Dave Thomas, and there’s a lot of good ideas there. One I’m particularly fond of is: automate your deployment from day zero , so you can deploy often.

I did that using github workflows and my dedibox in Scaleway. Now I deploy by doing just a single:

git push origin deploy

And of course, the deploy occurs only if all my tests passes. Pretty basic stuff, I know. But doing that from day one allows me to deploy often and gather feedback quickly.

Decision: Create a hello world, deploy it and automate the entire deployment process before doing anything else.

Final Thoughts

A good pet project is a pet project you can quickly deploy and have other people to use it. In my case, as a trainer, the idea of creating a platform to simulate real life stuff during training sessions seems like a perfect fit.

Will I revisit some of these decisions? OF COURSE! That’s the entire idea behind each one of these decisions. One day I’ll have a proper authentication mechanism and a database, but when that day comes I’ll have a reason to implement these things.

As Jaqen from Game of Thrones would say:

What do we say to our need to implement authentication in our products? Not today.

Turns out language is probably one of the most mind-blowing topics I came across since I started studying philosophy, and it’s a one-way wormhole: once you start thinking about the meaning of words and symbols you can never go back. So much that when I stumbled upon Kent Beck’s last post (link below) I started to automatically reflect upon the word demo.

Software Design: Tidy First - The Threat of Incremental Delivery

So, let’s try to delve into the meaning of two words we often use in software development: demo and review. Stick with me, I promise I’ll keep my feet on the ground.

What is a “demo”? Answer 1:

As someone who likes videogames, I remember playing a lot of demos when I was younger. The demos were basically a version of the game that had limited features, such as a single level, and there were magazines that would come with a CD-ROM containing dozens of demos so you could have a little taste of a game before committing your money and buying the full version of it. The demos still exist and are out there, they just don’t come in CD-ROMs anymore.

A demo works as a “teaser” to convince people to buy the product

So, a demo was a demonstration of something that was already done. Its purpose was to allow people to test something before answering a simple question: is it worth my money? On the developers side, they were trying to demonstrate that the answer should be a sound “YES!”.

And that’s why I don’t like using the word demo in scenarios where the customer is already committed to the product development. They already invested their money there, so… what’s the point of offering them a demonstration?

What else is a “demo”? Answer 2:

The word demo could have a different meaning. Specially in low-trust environments, where the customer needs some proof of progress. Some way to validate that what is being produced by the team is 100% coherent with the initial specification.

Here customer, if you click here a popup window opens and an error message is shown, Q.E.D.

Q.E.D - quod erat demonstrandum, meaning “that which was to be demonstrated”.

This time we are using a demonstration to prove something. To show the customer that we’ve been working since our last meeting and that the progress we made matches the initial expectations.

This meaning fits some software development teams better, but still has a problem: a demonstration is not about gathering feedback.

What about a “review”?

Re-view. To view again. Does it work?

“Let’s look at the software we’re producing one more time and check if we’re heading to the correct destination.”

That sounds good. But I also think about when my bike undergoes its safety review:

“We have a predefined checklist, and we’ll go over every item to make sure everything isaccording to the standards.”

Nope. Doesn’t work.

I still don’t love this word, but it’s way better than demo. At least it has a chance of actually stating what we’re trying to do.

What other words could we use?

There’s no perfect word to use. But take the Scrum framework for example: the name Sprint Retrospective makes perfect sense to me. The name Sprint Review doesn’t. Are we reviewing the Sprint? What kind of review are we doing? The good one or the bad one?

This conversation takes me back to when I was planning my wedding and we had to try all the fancy snacks, sweets and the cake. We would try them, and provide feedback. The buffet would be adapted according to our feedback. That experience is much more inline with what software development teams are actually trying (or should be) to do in a Sprint Review.

So, if I were to rename the Sprint Review I would call something on the lines of Increment Try-Out or Product Try-Out.

It focuses on what we produced rather than on the Sprint. And a try-out is about empiricism, it makes the need of the customer active participation more explicit.

Is it perfect? Well… no. But:

Every word is a prejudice

- Nietzsche

Ps: If you like this subject you’ll probably like to spend half an hour listening to this episode of Philosophize This! - Episode 178: Susan Sontag on Metaphors. :)

First things first: no, I’m not under the influence of any mind-altering substances. I recently started studying philosophy and developed a taste for it. While studying, my mind kept connecting philosophical concepts and questions with techniques and behaviors we’re accustomed to seeing in the software development world. I quickly made a list of potential posts I’d like to write, so this definitely won’t be my last post about philosophy and software development.

In other words… this trippy post won’t be the last one on this subject. :)

Descartes was about 50% agile

Descartes would definitely write great unit tests and experiment some suffering with them

Descartes was a rationalist, meaning he believed that the best way to find truth was through thought. This might make us think of him as a traditional project manager, sitting at his desk thinking through every detail of the plan we must follow to develop our product.

But thinking of him that way wouldn’t be fair, because in his Cartesian method we can find ideas very similar to what we practice in agile software development:

• Breaking big problems into smaller problems

• Ordering problems and solving the simplest ones first

You can almost imagine him writing unit tests and breaking down Product Backlog items, right? But there’s a problem: Descartes believed we could reach ideas that were “clear, objective, and immutable”, and that we could use them like LEGO blocks to build bigger ideas.

It’s as if he supported writing unit tests initially to provide clarity and objectivity, but failed to see value in keeping these tests in the repository after the functions were implemented because that idea had already been validated and consolidated.

In other words: Descartes sought an immutable truth, but the process to reach these truths was iterative and incremental.

But if Descartes was partially right about method, where did he go wrong? This is where David Hume comes in with a revolutionary idea: what if experience is more important than pure reasoning?

Hume would have been an excellent Scrum Master

Hume would push the team to experiment more, and allow them to learn from their failures

David Hume had the advantage of being born about 120 years after Descartes and thus having more material to study and explore. He argued that real knowledge can only be obtained through experience, and that merely sitting and reflecting or studying wouldn’t generate any new facts, only mere speculation.

But even being a devoted fan of experiments, he knew how to recognize their limitations:

Though experience be our only guide in reasoning concerning matters of fact, it must be acknowledged that this guide is not altogether infallible but in some cases may lead us into errors

- David Hume

Through this thinking, he raised some problems (and reflected on others that had been previously raised by other philosophers) that are easily recognizable in the software development world:

1. The problem of induction: Past experience doesn’t guarantee the repetition of future results. Also known as: if it works on my machine, it works on the server.

2. The problem of causality: Just because event A occurred followed by event B doesn’t mean one caused the other. Also known as: to replicate the bug the customer found, just follow these steps.

3. The fallibility of experiment: An experiment can always fail or lead us to wrong conclusions. Also known as: if we cover 100% of the code with tests, we’ll never have bugs again.

As The X-Files would say: The truth is out there!

This maxim should govern Scrum teams worldwide, since the framework has Empiricism as part of its foundation. If David Hume were a Scrum Master and saw teams doing Sprint Reviews with PowerPoint presentations or Dailies that are basically Status Reports, he definitely wouldn’t sit idly by.

If Hume were a Scrum Master today, he would probably:

• Insist on demonstrations of working software

• Prioritize real metrics over theoretical estimates

• Question any “absolute truth” about processes

Cool… but can we conclude anything useful from all this?

Well, first of all, I’m not a philosophy expert and took the utmost care not to commit any crimes when mentioning these philosophers and their thoughts. I’m comfortable with my understanding of the subject, and I believe this type of deeper understanding about the why of things always leads us to question mechanical behaviors and be more conscious about what we practice daily.

I think writing helps me better absorb the topics I study, and even if nobody reads it, it ends up having value for me.

For example, we can conclude that context matters. Descartes would probably write unit tests to validate the logic of building our product, while Hume would think about acceptance tests to evaluate customer behavior when using the product. Both approaches have value that can be greater or lesser according to the context in which they are applied.

If Descartes and Hume decided to do pair programming today, they would probably create DevOps.

Descartes would contribute with:

• Infrastructure as code (after all, it needs to be clear and objective)

• CI/CD Pipeline (order and method in action)

• Automated tests (validating fundamental truths)

While Hume would insist on:

• Constant monitoring (because experience matters and failures happen)

• Feature flags (to validate hypotheses in production)

• Culture of blameless postmortem (learning from errors and treating them as a natural part of the process)

If we understand each daily practice as an experiment that can fail, we can start to see if we achieve satisfactory results in each of these experiments:

• Why do we have daily meetings?

• Why do we do Sprint Reviews?

• How can I measure the value that a certain practice brings to my team?

And this way we start to do our work with more consciousness, always taking into account the intention of each step.

Interested? Well, here are my recommendations:

I started learning more philosophy through Stoicism, and Ryan Holiday’s The Daily Stoic is a book I’m reading for the third time and therefore never tire of recommending. If stoicism appeals to you, all of Seneca’s work might be interesting, and I recommend starting with “On the Tranquility of the Mind”.

Oh! If you’re not much of a book person, check out the Philosophy Tube channel on YouTube. Her video on empiricism might be a good start!

How can I start applying Test-Driven Development?” This question echoes through my training sessions like a recursive function call. While my default response has always been “Start with fixing bugs,” I’ve discovered an even more engaging approach: Advent of Code.

My default approach: fixing an existing bug

Let’s examine a simple example. Imagine you have a calculator function:

When someone tries to divide by zero, our application crashes unceremoniously. This presents a perfect opportunity for TDD – we can write a test expressing our desired behavior:

My test will of course fail, because my code fails. I can now fix my code and make my test pass.

The Gamified Approach: Advent of Code

As a self-proclaimed geek with an affinity for puzzles, I’ve found Advent of Code to be the perfect TDD training ground. Each puzzle provides:

• An input sample

• An expected output

This structure naturally guides you into the TDD mindset – you write your test based on the example before implementing your solution. It’s like having a built-in specification!

I mean, not only it’s a good way to learn TDD but it’s also fun. You’re honing your development skills, solving a puzzle and practicing a very valuable technique.

As you advance through the challenges, you might start to experiment more with TDD and maybe reduce the granularity of some of your tests. For example, you might need to parse a complex text input into a Map in order to solve the problem, and then that could be a test on its own.

Tools That Enhance the Experience

In Elixir (my language of choice), the pipe operator (|>) is particularly powerful for TDD:

That small triangle basically says: take the output of the above function and pass it on to the following function. This elegant syntax allows you to sketch out your solution’s high-level flow before diving into implementation details.

Combine this with tools like mix test.watch, which automatically runs tests when files change, and you’ve got a rapid feedback loop that makes TDD feel natural and intuitive.

Ready to Begin?

Pick your preferred programming language and dive in! You can explore my Advent of Code 2024 repository for inspiration:

https://github.com/mariomelo/advent_of_code24

Remember: The goal isn’t perfection but practice. Each puzzle is an opportunity to strengthen your TDD muscles while having fun!

For deeper insights into TDD, check out ’s excellent article on Software Design: Tidy First?

Software Design: Tidy First? - Canon TDD

Happy coding!

So far we talked about Stratification and Chronology, and we moved from the “Mario Bros approach” where we’ll always develop level 1-1 before level 1-2 to the “Megaman approach”, where we have more flexibility and can develop our modules in any order.

Did you notice I just used the word “modules”? That’s the problem we are about to tackle in this post: if we consider that a given part of our software is done, that means that part isn’t flexible anymore. If Stratification is about layers and Chronology about sequence, Modularity is about the boxes we put our code in - and sometimes, those boxes become prisons.

Understanding the Modularity Bias

When you beat a boss in Megaman, you gain access to a new weapon. A complete and functional weapon, but also a weapon that will never change. In software development however, if we try to finish a part of our software and state that we will never be touching that area of the code again… Well, let’s say it just doesn’t work like that. Sorry, Megaman.

So, which game could we use as an analogy on how to improve the MegaMan approach? Planescape: Torment! (Or any other Classic RPG for that matter).

In Planescape, every time you accumulate enough experience you can upgrade your character by adding points to his Strength, Wisdom, Intelligence, Dexterity, Charisma and Constitution. You gradually improve these stats, but you never complete any of them: you can always add more points to a given stat during your next “level-up cycle”.

Think about Megaman: when you start to play it, you can chose one of 8 stages to play. But every time you beat a stage you have less options on what to play next, up to a point where you’ll have no choice because you’ve beaten 7 stages and there’s just one remaining. You start flexible, but you lose that flexibility along the way.

In Planescape we don’t acquire new “modules” to our character. We improve their characteristics according to our needs, and our needs change as we advance through the game.

Enough about games. Let’s talk about software!

Well, technically these games are also software, but I get the point. :)

Let’s go back to the example we had in our last article: a Hangman game. While breaking the Chronology bias we decided to postpone the development of a “Dictionary Module” by just implementing a function that always return the same word: ELEPHANT.

By doing that we were able to focus on more interesting things such as the game mechanism without spending much time with the dictionary. If we think about our next step, one could say that we could implement the actual dictionary next and give our Megaman a new weapon. But by doing so we would hinder our ability do adapt to customer feedback as we reduce the amount of possibilities we could develop in the future.

unless we’re willing to discard some of our work and redo it according to the feedback we receive, of course. It’s actually not a crime to do that, but this kind of waste can be drastically minimized if we instead of implementing the Dictionary we ask ourselves the following question:

How could we upgrade our Dictionary by a single point, like in that game Planescape?

Maybe we could create a list of words and pick a random word each time the function get_word is called. This is simple, could be done in a couple minutes and would greatly improve the game.

Notice that we didn’t implement the API integration initially shown on our last post, but we can do that in the future if we think it’s a good idea. Or not.

Benefits of breaking the Modularity Bias

Let’s say you’re developing that Hangman game using the MegaMan approach and you’re part of a Scrum Team. During the Sprint Review you show your customer what you build and you ask for feedback:

So customer, we finished the Interface and the Dictionary. What do you think we should do next?

Well, what’s the point of asking feedback here? If the customer asks us to change something related to the Dictionary or the Interface, we’ll waste a lot of the work we’ve done, and if they limit their feedback to the remaining areas of the software we aren’t benefiting from the whole Scrum thing.

Now, imagine you with the Planescape approach. You improved our Dictionary and our Interface, but instead of finishing them we used the remaining time to come up with a simple Scoring System:

In this scenario, you would be able to ask your customer a different question during the Sprint Review, such as:

So customer, we based in what you saw, where should we allocate our next 3 upgrade points? And what are we trying to achieve by doing that?

Notice the difference? The customer has keeps their options and even if they ask us to improve something we already worked upon, we don’t throw work away. At least not that much.

Also, maybe we won’t have to implement that API integration right now as the customer decides to enhance the Scoring System and implement Hint Mechanism. Meanwhile we won’t have to worry about how many API calls we’re making during the development process, create mocks and stubs to test our game or create a configuration option to make our game deployable to both staging and production server.

The waste we minimize isn’t just related to customer feedback, but to the entire development process.

Maybe we’ll never use that API. In fact, while developing this Hangman Game for a Certified Scrum Developer course I was teaching, my wife played the game and came up with an interesting idea: since the course was about Scrum, we should use words from the Scrum Guide, and by doing that we ended up with a static dictionary that had 802 different words. All related to the same subject: Scrum.

How can we avoid that Modularity Bias?

I’ll be direct with this one: Use the Hamburger Method. I know I could ellaborate more, but in my experience there’s no better way to tackle that bias as team than using that method. You can read more about that method here:

https://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/.

It’s also a great way to deal with dependencies, which often pushes us towards the Modularity Bias.

There’s still one more thing we need to address here: The Planescape: Torment approach isn’t even our final destination. That’s because in that great game we’ll always have the same 6 stats to upgrade throughout the entire game. And if you truly break this Modularity Bias, you’ll be able to discover new areas to explore as you move forward.

This post is too long, could you summarize please?

Yep! Before declaring any part of your software ‘complete’, remember: even the most powerful RPG character can still level up.

This time, we’ll talk about how an imaginary user flow can lead us to blindly follow a predefined development flow.

Understanding the Chronology Bias

I remember the first time I played a Mario Bros game in the NES console my father gave me when I was 4. The absurdly unergonomic rectangular controller, the joy of playing a game with a character with which I shared my name… It was a blast, and it was very linear: 8 worlds with 4 stages each. You start on Stage 1-1 and finish the game after beating stage 8-4. There were warps you could take to advance forward, but you could never go back.

Developing software under a Chronology Bias is like playing that Mario Bros game, except it isn’t that much fun. You start developing world 1-1 because that’s what the user will play first. Then you develop world 1-2, and so on. If we follow that path, we are clearly not falling into the Stratification Bias, because we are creating every layer for each stage (we are not finishing the design of all levels before implementing the game mechanism, for example), and we would be able to gather feedback from the customer after developing each stage and use that to create better stages further on. But still… we are missing some good opportunities.

You know what’s funny? This Mario-style linear progression shows up everywhere in software development. Take the login screen, for example - it’s pretty much become our “Stage 1-1”. It’s almost like there’s an unwritten rule that says “Thou shalt implement authentication first” just because it’s the first thing users see. And more than often, this is the first thing a software development team will work on. Have you ever done that? I did it, countless times.

But what’s the problem with this approach?

Problems, I would say. Plural.

The most obvious one is that we are not entirely benefiting from an agile approach if we are following a predefined path. After reviewing Stage 1-1, we’ll have some flexibility on how we develop stage 1-2 but not on what we should develop in our next iteration. Besides, all of our conversations about the product will leave that sour taste of wasted time because the path is already defined. This feeling is quite common among developers in Scrum Teams during the Sprint Planning and Sprint Review when they’re falling into this bias.

What if stage 6-2 is the most valuable one to my user? They’ll have to wait 26 iterations to finally be able to play it.

Another problem will be risk mitigation. If I’m building a Mario game maybe I’ll have some bold ideas I want to validate first, such as a water world, a puzzle castle or a very challenging boss. Even the final boss!

So the solution seems straightforward: just develop features in any order that provides the most value, right? We could build stage 4-3 before stage 1-2, following user priorities rather than sequential order.

Well… turns out we often hit a familiar obstacle: dependencies. But here’s where another gaming classic offers us an illuminating alternative…

Breaking the Chronology Bias (and the dependencies)

Going back to my childhood and my NES console, there was a game I loved even more than Mario Bros: MegaMan. In every MegaMan game you could select which stage you wanted to play, and once you had beat the stage boss you would gain access to their weapon and could use it for the rest of the game.

If you never played Megaman, stop reading and go play NOW

So, you could choose to fight Fireman first and use its fire weapon against Iceman, or the other way around. It’s up to you. There was absolutely no predefined sequence. But… what happens if we try to use the same approach on software development? Well, sometimes we’ll hear and say things like:

We can’t develop a report without creating a CRUD to insert the data first, after all there’s no report without data!

Ok, let’s challenge that: How could we develop a report without having an interface for data insertion? Well, mocking the data. Imagine we are going to build a Hangman game. One could say that the very first thing we need to do is create a dictionary of words we can use during the game, because having a word to play is a pre-requisite!

So, if we fall into that trap, we’ll probably spend some time developing something like:

It doesn’t seem like much, but it required some time to research a way to generate a random word, read the API documentation, create an account, get an API key, write the code, test it and refactor it a bit. But the game mechanism is way more important, and if we could save some time here we could use that time to develop it further. And one way to do it is by establishing a simple interface.

When I call the function get_word I get a word, and I don’t really care about where it came from. If we do that, we could create our Dictionary like this:

Yes, the word will always be ELEPHANT. But I’m not saying we should release the game like that! All I’m saying is that now instead of showing the user a screen that generates a bunch of random words, we’ll show a fully functional Hangman game that always use the word ELEPHANT. And by doing that, our product review will become more interesting because now we have a very powerful question to ask:

What should we do next?

We could decide to implement the Dictionary, or the customer could ask for something else, like a scoring system for the game or a hint mechanism. We’ll have options. We are not playing Mario Bros, we are playing MegaMan.

And how do I start to do it?

First of all, take notes of all your dependencies assumptions and start to question them. I like to use the How could we / without construction to do that:

• How could we authenticate the userwithout a login screen?

• How could we generate a reportwithout having a way to populate the database?

• How could we show this informationwithout using charts?

Second and most important: make sure your team knows how to work with interfaces. This is paramount to avoid rework and breaking stuff.

Remember: in order to adapt to changes successfully, we must learn how to do that without increasing the development costs. Just like in MegaMan, the best path isn’t always the most obvious one - sometimes you need to fight Fireman before Iceman, and sometimes you need to build that scoring system before implementing the perfect word selection algorithm.

The Chronology Bias, much like its cousin the Stratification Bias, tricks us into following a predetermined path when we should be asking ourselves that simple yet powerful question: “What should we do next? “. After all, software development isn’t about completing levels in order - it’s about creating value in the most effective way possible.

Stay tuned for the final post in this series, where we’ll explore our last bias: Modularity.

Oh! And if you came this far, thanks for reading!

Reflection Moment: Take a minute to think about a current project. What tasks are you doing in sequence simply because “that’s how it’s always been done”? How might you reorder them for better value delivery?

The event was awesome, as the organizers (Evelyn, Giuseppe, Khurram, and Thomas) and the volunteers did an amazing job putting it together. I left the event truly happy and with a lot of food for thought. That was my motivation to transform my presentation into three posts: one for each bias I described there.

So, what are these biases?

A bias can be defined as “A preference or an inclination, especially one that inhibits impartial judgment”. In software development, that could be translated as modeling a software project using concepts that are hardwired in our brain, thus avoiding an alternative approach that could help us create something more flexible.

We do things this way because we’ve always done them this way. And that’s an infinite loop.

To break these biases, we must first understand them, so let’s start with the first one: Stratification.

Stratification?

Yep, I came up with these three names, and I’m not really satisfied with them. But, as Phil Karlton said: “There are only two hard things in Computer Science: cache invalidation and naming things”.

The stratification bias happens when, after splitting software into layers (let’s say: database, backend, and frontend), we immediately start to develop the basemost layer, which is often the database model. Picture this: you start with the database layer, meticulously crafting each table and relationship. Only when that’s “done” do you move on to the backend, and heaven forbid anyone mentions the frontend until the API is complete!

This is probably the most famous of the biases, as it’s long been coined as BDUF (Big Design Upfront) and was one of the first barriers we had to overcome to develop more flexible software. Sad thing is, it still happens. A lot.

There are two main problems with this approach. Number one: side-effects. A change in a single point of the uppermost layer could generate multiple changes in the lower layers.

Second problem: side-effects of side-effects, or bugs. Now, because you had to change the database, some part of the backend that is barely related to the initial change might be affected and also affect some frontend part that is completely unrelated to the initial change.

If you’ve been paying attention, you noticed that by fixing a bug you could trigger the exact same process again, which takes us to an infinite loop of despair, frustration and customer-angriness.

Am I a victim of this bias? How do I escape it?

There are symptoms. Your customer won’t be able to provide valuable feedback because they won’t see anything usable, the amount of rework needed whenever you have to change something will be unbearable, and you might feel the urge to discard some nice ideas because of their development costs. Most importantly: your developers will be bored to death.

And just because this was the status quo not long ago, the bored developers back then decided to create something to help them out of this situation. Something that would allow the database to safely evolve over time without generating a lot of technical debt. They called it “Database Migrations”.

It’s beautiful, isn’t it? A technical solution created to solve a technical problem that was hindering the team’s capability to adapt to change. I’ll come back to this later after the technical example, so if you’re already familiar with the concept or if you’re not familiar with code, just skip the next section.

Getting our hands dirty (with code)!

Let’s take a look at a Database Migration using Elixir and Ecto. Imagine that you are creating a table to store the users of your system. You (and your customer) might have a lot of neat ideas of all the data you can store there: name, email, a short bio, an avatar, their birthday, and the list goes on and on.

If we understand that the database can evolve, we can start with something simpler. Just the username and the email, for example.

defmodule MyApp.Repo.Migrations.CreateUsers do
  use Ecto.Migration

  def change do
    create table(:users) do
      add :username, :string
      add :email, :string
      
      timestamps()
    end
  end
end

Doing this first part will provide us with options for the next iteration. We can actually ask ourselves what is the most important thing to develop: the avatar? the short bio? something entirely different in another part of the system?

Later, if we decide to implement the user avatar and the short bio, we could just create another migration like this one:

defmodule MyApp.Repo.Migrations.AddProfileToUsers do
  use Ecto.Migration

  def change do
    alter table(:users) do
      add :bio, :text
      add :avatar_url, :string
    end
  end
end

This way we can ensure that the customer’s database will always be up to date and that nobody will run the same database script twice and break the whole thing.

There are technical benefits, but non-technical as well

Besides the obvious benefit of creating something more flexible, there are some very interesting non-technical benefits as well. For example: because you built a lighter database, whatever the team needs to develop next will take less time just because there will be fewer fields and tables to deal with. This will also reflect on the amount of side-effects (aka bugs) your development process might generate, because the complexity of your software won’t grow exponentially like it did before. We could summarize that as: breaking the stratification bias equals saving time.

That time you saved could generate a butterfly effect. The team can now think about what to do with that time. Maybe learn how to write some unit tests, or take some time to experiment with a new technology. Because the answer to this question isn’t obvious, they’ll have to collaborate to find the best option. Note that everyone will have to collaborate: developers, designers, testers, business people.

This whole database migration concept was created because someone challenged the idea that “We cannot change the database as we please”. A technical person, with a technical solution. Because sometimes when a developer faces a challenge like this one and has the proper time and resources to deal with it, an innovation is born.

That’s also the case when we break the Chronology and the Modularity biases, but we’ll talk about them later. :)

Ps: If you want to read further about this subject, you can check Martin Fowler’s amazingly detailed blog post, here: <https://martinfowler.com/articles/evodb.html

If it’s true now, would it be true tomorrow? Probably. Chances are she’ll spend a couple months until she finishes the album, and the sentence will still be true during that period. However, if you receive a more specific information the scenario might change:

• Lady Gaga is working on the first song of her new album

For how long will this sentence be true? Maybe a couple of days or weeks.

• Lady Gaga is writing the lyrics for the first song of her new album

For how long will this sentence be true? Maybe a couple of days or hours.

• Lady Gaga is writing the chorus of her new album’s first song

For how long will this sentence be true? Maybe a couple of hours or even minutes.

When it comes to software, we could say the same. And Kent Beck recently reposted a nice article about that subject called “Software is Bananas” (link below).

Software Design: Tidy First? - Software Is Bananas

Thing is, different information in different contexts will have different “expiration dates”. Let’s say you have a problem, and you want to create a software product to solve that problem, so you formulate a hypothesis:

If this idea I have works, problem X will go away.

If you don’t implement your idea in, let’s say, 6 months, it might not make sense anymore even if the original problem still exists. It’s only natural: the problem is less volatile than the solution, because the later depends on the former.

But let’s say you decide to move forward and implement your idea. You then start to make notes on how to do it :

To implement this idea, I will do step X, step Y and step Z.

Same rule applies here. If you don’t follow the steps you established right away, you might decide to implement the very same idea in another way. The steps are more specific and therefore more volatile.

In summary, it’s ok to have a list of problems to solve as long as you don’t spend too much time thinking on how to solve many of them at a time. And it’s ok to discuss the implementation details of a handful of ideas, as long as you are really certain you’re going to implement them in the next few days.

During these years I’ve been a developer, a business owner, a consultant, a trainer, and learned (mainly by making mistakes) many things about both the technical and the social side of software development.

What I wrote down here is based on what I lived in this market, which means: it’s based on many years of experience, but it’s also biased by these same experiences. But as I’ve seen things changing and some things not changing, I’d like to try to elaborate my reasoning on what are the causes and consequences of these outcomes.

So, let’s start!

What changed in 20 years?

Well… Obviously, technology changed. And with that, everything changed.

When I started programming we didn’t have iPhones or Android phones, and curiously enough I was working with mobile computing. Pocket PC 2002 was the operational system and I was writing C++ code that needed to be highly optimized because of all the memory restrictions we had back then.

Mobile in 2000’s: These devices could make the Nokia 3310 seem fragile

But most importantly: the organizations changed. And most of the changes I saw were caused by technology innovations.

Complicated, then simpler, then complex

If you ever wrote a web application using J2EE and Enterprise Beans you can remember how bureaucratic it was. The deployment wasn’t straightforward, we needed to write a lot of code to do the simplest thing and changes of a database schema were a nightmare. The thing was we were mostly creating private web applications because the web wasn’t what it is today (not even Orkut had been created back then).

At first, these pain points incentivized organizations to push for bigger teams, a specialized database management department and also an operations department.

On the other hand, developers started to create tools to solve these pain points: ORM frameworks such as Hibernate started to become popular, then frameworks such as Rails started to introduce easier ways to create evolutionary databases and also a more direct approach to create a web application.

These changes empowered the developers and allowed small teams to be even more productive than big corporate teams were. With that we saw a shift in the market: everybody wanted smaller teams with the so called Full-stack Developers. Cloud computing was available for everyone for less than US$5/month with Heroku, DigitalOcean and AWS, and a lot of startups started to pop up everywhere.

But then… everything changed.

The web evolved and what was a simple REQUEST/RESPONSE with HTML and CSS became a complex puzzle using Ajax, jQuery, and then Angular, Ember, React, Vue, Svelte. The companies started to require frontend developers.

On the backend, things got even more complex. The giants in the industry were facing the challenges caused by their own success: how to handle such a massive amount of simultaneous users? How to store efficiently store this massive amount of data?

Then again, the developers came to the rescue and created solutions such as Docker, Kubernetes, Grafana. The giants shared their success stories and the medium-sized companies decided to add all this complexity to their products in order to achieve the same results. In part, this movement was also caused by the developers: we wanted to work with the cutting-edge technology used by the giants of the market, even if it was clearly not necessary for our servers that were handling way less users than Google or Facebook.

Developing a simple software felt… unnecessarily complex. Most companies I worked with back then weren’t creating products for the masses, but niche products with little to no necessity of such complexity. And that’s actually when I started to work more with consultancy and training again. I was constantly advocating for simpler models whenever they were good enough.

I still am.

What didn’t change in 20 years?

Many things:

• We still need software developers

• People are still trying to figure out how to measure productivity in the software development field

• Estimates are still a problem for most people

• People are still arguing over which is the best text editor/IDE/framework/language

• And well… software development still brings me joy :)

I don’t feel I said everything I wanted to say. I still need to reflect more on how I changed during these 20 years.

Maybe I’ll write more about that in the future.

About a year ago I created a card game to teach Scrum: Scrumchkin. The game made the learning process more fun and was adopted by Scrum Trainers from several countries, until the pandemic made any in-person class unfeasible.

And that’s where my personal project came from: creating an online version of Scrumchkin. Which would be a great opportunity to play and learn more about Phoenix Liveview.

Initially, I thought of the following structure for the project:

This way, it would be possible to create games in separate processes and have a registry with unique identifiers for each game so that each match could be accessed through a different URL.

Example:

• The user accesses the URL http://scrumchkin.com/game/abc123

• The web application asks the Game Registry where game abc123 is

• The Game Registry finds the PID of the match and returns it to the web application

The Game Registry as a library

Keeping in mind the single responsibility principle, the design above makes evident the existence of 3 different projects: The Game Registry, the Game Server and the Web Interface.

The next paragraphs will talk about some technical aspects of Elixir as a curiosity. If you just want to understand the difference between a library and an OTP application feel free to skip this part :)

Technically the Game Registry is extremely simple: it links a unique ID to a match. It’s basically a dictionary that has a UUID as key and a PID of a GenServer as value for a match.

Initially, I created the Game Registry as a library capable of performing CRUD operations on an ets table:

defmodule GameRegister do
  def init() do
    :ets.new(:scrumchkin, [:set, :public, :named_table])
  end

  def save(value) do
    key = UUID.uuid1()
    :ets.insert_new(:scrumchkin, {key, value})
    key
  end

  def delete(key) do
    :ets.delete(:scrumchkin, key)
  end

  def get(key) do
    :scrumchkin
    |> :ets.lookup(key)
    |> format_result
  end

  def list_all do
    :ets.tab2list(:scrumchkin)
  end

  defp format_result([]), do: {:error, "Game not found"}

  defp format_result(item_list) do
    item_list
    |> hd
  end
end

TL;DR - The library stores the current state of matches and links them to an identifier code. It is capable of listing, getting, saving and deleting matches from the registry.

A small problem

For me to use the ets table, it needed to exist. This means that at some point the init function from the code above would need to be called by my web application.

  def init() do
    :ets.new(:scrumchkin, [:set, :public, :named_table])
  end

But this goes against the single responsibility principle I used to divide this project into smaller parts, right?

The Registry as an application

But what is a dependency as a library? It’s a gear that’s part of a whole; something very similar to a Lego piece. We know where the pins and holes are and we use it to build something bigger.

The dependency on an OTP application is a bit different.

Think of a car. Usually, cars have an engine cooling mechanism that starts when you turn the key and start the car. The car depends on this mechanism to work, but it’s somewhat independent: many times it’s activated when we turn off the car (that fan noise that comes from under the hood, especially on hot days).

This cooling mechanism has interfaces with the car’s engine, but controls its own state. There’s a clear relationship of dependency, but not of control. The engine depends on the cooling system not to overheat, but doesn’t control it.

And the same needed to happen with my Game Registry, which ended up like this:

defmodule GameRegister do
  use GenServer

  def start_link(state) do
    GenServer.start_link(__MODULE__, state, name: __MODULE__)
  end

  def init(stack) do
    :ets.new(:scrumchkin, [:set, :public, :named_table])
    IO.puts("Scrumchkin table created")
    {:ok, stack}
  end

  def handle_call({:save, game}, _from, state) do
    key = UUID.uuid1()
    :ets.insert_new(:scrumchkin, {key, game})
    {:reply, key, state}
  end

  def handle_call({:delete, game_id}, _from, state) do
    :ets.delete(:scrumchkin, game_id)
    {:reply, :ok, state}
  end

  def handle_call({:get, game_id}, _from, state) do
    result =
      :scrumchkin
      |> :ets.lookup(game_id)
      |> format_result

    {:reply, result, state}
  end

  def handle_call(:list_all, _from, state) do
    {:reply, :ets.tab2list(:scrumchkin), state}
  end

  def save(game) do
    GenServer.call(__MODULE__, {:save, game})
  end

  def delete(game_id) do
    GenServer.call(__MODULE__, {:delete, game_id})
  end

  def get(game_id) do
    GenServer.call(__MODULE__, {:get, game_id})
  end

  def list_all do
    GenServer.call(__MODULE__, :list_all)
  end

  defp format_result([]), do: {:error, "Game not found"}

  defp format_result(item_list) do
    item_list
    |> hd
  end
end

But… what changes?

My web application is not responsible for creating the ets table. It just says it depends on the Game Registry and that it’s now an extra application.

The change in the mix.exs file is simple:

  def application do
    [
      mod: {Scrumchkin.Application, []},
      extra_applications: [:logger, :runtime_tools, :game_register, :game_engine]
    ]
  end
  defp deps do
    [
      {:game_engine, path: "../game_engine"},
      {:game_register, path: "../game_register"}
    ]
  end

Now, every time I start my application with mix phx.server, my game registry is automatically started and takes on the responsibility of creating the ets table where it will store the PIDs of Scrumchkin matches.

My web application depends on the Game Registry, but trusts that it can solve its problems on its own.

Disclaimer : this post was first written in March 24th, 2014 and published on Medium. I think it’s still pretty relevant (maybe with some old song references here and there), so I brought it here as well.

To err or not to err

As humans, we’re all error prone. But some refuse to accept that.

You give your best at something just to find out it didn’t go as well as you planned. Is there some kind of punishment on the way?

Failure-shaming environments

Whatever your answer might be, it was at least in part created by the environments you lived so far. Were you free to fail when you were young? Do you work on a company where people get punished when they make mistakes? Are you confortable facing people you’ve let down?

A failure-shaming environment is a place where no one is allowed to fail, because if they do, they’ll suffer some kind of harsh penalty. Like being fired by your boss, hit by your parents or even left by your significant other. Pick your flavor.

You’re wrong. Shame on you.

- Ourselves

If you’ve ever experienced this kind of environment (and chances are that you did), you know how hard you must think before taking a single step forward. Or backward. You need to think and rethink each move because if you fail there’s somtehing bad awaiting for you.

Failure-shaming consequences

Well, if you look in the face of evil evil’s gonna look right back at you, and by not being allowed to fail you might start to hate when people fail you.

That happened to me, and as I started to reverse this process I became able to perceive some consequences of this kind of culture.

Stagnation

We often evolve by trial and error. We accept concepts learnt by practice quicker than by theory.

Why do we fall sir? So that we can learn to pick ourselves up.

— Alfred Pennyworth

Where I work, we’re constantly trying new things and brainstorming. No matter what comes to mind, everybody feels free to speak up anything to anyone. Failures are tolerable as long as we learn something from them, and that makes us evolve much quicker than one would expect.

If nobody had this freedom to fail, my coworkers would lose the autonomy and self-confidence to try their own ideas and we’d be stuck in 2011.

Procrastination

I can’t fail so I need to work on that until it’s perfect, no matter how much time it takes.

I wanna a new mistake, losing is more than hesitate.

— Queens of the Stone Age

I once worked on a project that aimed to improve a certain company’s indicator to something above 90%. After 5 months, the project could improve this indicator from 10% to something above 65% if it were deployed. The responsibles didn’t want to deploy it as it was and kept looking for ways to improve that 65% to the desired 90% for 2 freaking years.

For 2 years the company had 10% on something it could’ve had 65% because nobody wanted to say Hey, I couldn’t deliver 90%, but let’s start with 65% and grow from that. Chances are that if they tried, they could have figured out how to reach more than 90% in less than 2 years.

So, if you fail fast, you’ll evolve faster.

Lies and Apathy

Everything is on fire, but nobody will step up to do anything. By the way, the fire-starter was thrown away because it could make someone look guilty.

It wasn’t me

— Shaggy (and 94.7% of the humanity)

It’s hard to find someone with more information about a problem than the person who first created it. If this person feels confortable enough to assume it, her/his help can be the key to fix the problem. However, if there’s no space for that a lot of important things will stay under the carpet.

I try to have retrospective meetings with my coworkers periodically. It’s healthy to have an open debate about our own flaws and to seek improvements together no matter the subject.

TL;DR

Fight for your right to make mistakes, give a try to your ideas without being afraid to fail and don’t be a bitch when you see someone else failing, even if that hurts you.

If you ever find yourself in a hard situation occasioned by a mistake you’ve made, take a look at www.experienceproject.com. You’ll find a lot of friendly people like you sharing their experiences in a very open way.

That’s it. Keep on failing. ☺

The most curious thing is that transfers of other values worked perfectly. Well, almost all. People started discovering other specific cases where the problem occurred: R$32.23 or R$155.17.

The idea of this post is not to debate the cause of the problem, but to show a technique that can help teams detect similar problems.

The text includes some code in Elixir, but also includes illustrations to explain each concept. The goal is to make this content useful for both technical and non-technical people.

Would unit tests help? Well… not exactly.

Don’t get me wrong: I’m a fan of unit tests and I (almost) always practice TDD.

But a conventional test for a money transfer function would probably be something similar to the example below:

Isn’t it too specific?

Notice that the test where the transfer is possible focuses on only one case: a transfer of R$25.00. And in this case, the tests are a success:

But we can write a test for the R$17.99 case, right?

Sure! After knowing about the existence of the error we could include an additional test to ensure that bank transfers of R$17.99 can also be made:

Here we can put the famous TDD cycle (Test Driven Development) into action: Red, Green, Refactor.

This test fails (RED), and then we can fix the problem until the test passes (GREEN). And now, having the test as a safety net we can alter the code to make it more readable without fear of breaking anything (REFACTOR).

The test fails because the remaining balance was R$2.02 and not R$2.01

Done! Now when we make this test pass we’ll ensure that transfers of R$17.99 will work perfectly. But some questions remain:

• Will the transfer of R$32.23 work?

• What if there are other values that generate the same error?

• What if there are values that generate a different error?

• How can we prevent problems like this from reaching our customers?

And that’s where PBT comes in — Property Based Testing.

PBT: cleaning where conventional tests can’t reach

It’s quite simple to write the R$17.99 test after we know about the existence of the error.

What happens is that we write tests with cases we already have in mind, in a very linear and specific manner. But the test is so specific that it tests only one case. What if the problem continues to happen with transfers of other values?

In this case, the problem appeared only when trying to transfer R$6.05

But… how could we identify problematic values before even knowing about the problem? That’s where property-based tests come in.

Working with properties means not thinking about specific cases, but rather the characteristics of each variable involved in the test. In this case, we can say that:

• The initial balance of whoever is going to transfer the money can be any value greater than zero.

• The transfer value is greater than zero and less than or equal to the available balance.

To know if the transfer was made with the correct values, we just need to “check our work”, as we did in elementary school. :)

Transferred value + Remaining balance = Balance before transfer

When we define the rules this way, automated testing tools are able to validate several different cases. And many times these “different cases” end up including situations we never even imagined, and therefore would never write a conventional test about them.

Now, when running the tests we discover that there are other values that also generate the error:

Oops! If I have R$0.98 and try to transfer R$0.71 the problem also happens!

Ah! Notice that the testing library says: Counter example stored.

PBT libraries usually store the values that generated errors and use them again until the problem is fixed. That is, when the test passes it’s because the problem was solved, and not because the library selected only values for which the problem doesn’t occur.

Okay, but what does this have to do with agility?

Well, agility is the ability to change and generate results quickly.

It’s like being in a race car on a winding track: to take curves quickly and without losing much speed you’ll need a solid and well-built vehicle. Without it, you’re limited to two options:

• Take the curve veeeery slowly to ensure the vehicle doesn’t break

• Take the curve quickly and dismantle your vehicle

Example:

Imagine the bank decided to allow Bitcoin accounts. They would now have to work with a currency that has way more than two decimal places.

Now imagine the bank can have an application that:

a) Has no automated tests

b) Has some automated tests

c) Has conventional automated tests and some using PBT

In which scenario would the bank be able to have a functional product in production more quickly?

In summary: There is no agility without technical excellence.

Source Code and final considerations

I wrote the code to generate the error on purpose and thus illustrate how a certain technique could help solve a problem.

If you’re curious, the code used in this post is available at: https://github.com/mariomelo/post_pbt

Scrum is simple to understand, but difficult to master

- Scrum Guide, 2017 version

In other words, there’s a universe of distance between understanding Scrum and truly mastering it. And that’s where the danger lies: this distance is the perfect habitat for victims of the Dunning-Kruger effect.

Image created by www.investificar.com.br

From Wikipedia: The Dunning–Kruger effect is a cognitive bias in which people with limited competence in a particular domain overestimate their abilities. Some researchers also include the opposite effect for high performers: their tendency to underestimate their skills.

That said, let’s get to the three fake news!

1 — The problem with Scrum is that it’s too simple

Scrum is a framework, but it’s common to hear people refer to Scrum as a methodology. It may seem like nitpicking, but this simple word swap says a lot about the understanding of Scrum.

After all, what is a framework? Well, according to the Cambridge dictionary:

A supporting structure around which something can be built

- Cambridge Dictionary

Scrum is a structure upon which you should build your way of working. It’s like Ruby on Rails, ExpressJS or Hibernate: they don’t work alone, but they help you work in a more structured and productive way.

Frameworks are incomplete by default and on purpose. They are created so you can think and expand them in the way that makes the most sense in your work context. And that’s where agile practices like Story Points, User Story Mapping, Risk x Value Prioritization, User Stories, etc. come from.

As Scrum implements the PDCA cycle, it’s possible to adopt a certain agile practice, validate its effects and decide whether it’s worth continuing with that practice. And of course, it’s necessary to experiment with new ideas and repeat this reflection at the end of each Sprint.

In summary:

Scrum is simple and incomplete on purpose to make you think of ways to complement it.

If someone tells you that the problem with Scrum is being too simple, this person hasn’t understood anything about the framework yet.

2 — Management 3.0 and DevOps came to replace Scrum

In Minas Gerais (a state in Brazil) we have a commonly used expression when someone says something like this:

WHAT??? — Translation: excuse me, what did you just say?

This statement makes no sense if you’ve already understood the concept of a framework: Management 3.0 and DevOps come to complement, not to replace.

After all, the Scrum Guide says:

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

- Scrum Guide

Yes, Scrum doesn’t talk about automating deploys, for example. It doesn’t talk about feedback wraps, delegation boards or intrinsic motivators.

Because Scrum is a… framework!

I believe that this visual representation used by Alexandre Magno in his training sessions illustrates this idea very well.

Representation of the Scrum framework completed by emerging techniques, created by Alexandre Magno

3 — We don’t have Scrum teams anymore. We have Squads.

This one is quite interesting, and I added it here because I increasingly see organizations using terms from the famous Spotify model. And often the justification is that the teams are multidisciplinary and not segmented by areas of knowledge.

But, what does the Scrum Guide say about its Scrum Team?

• Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

• Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

The concept of Squads was born collaboratively at Spotify and was partially documented in 2012 in this pdf by Henrik Kniberg and Anders Ivarsson. In the document, available at this link, they say:

A Squad is similar to a Scrum team, and is designed to feel like a mini-startup. They sit together, and they have all the skills and tools needed to design, develop, test, and release to production. They are a self-organizing team and decide their own way of working.

It’s always worth reflecting on the model adopted by the organization:

• Does your Scrum Team have the characteristics mentioned in the Scrum Guide?

• Does your organization provide the necessary environment for the existence of Squads/Scrum Teams?

• What problem is being addressed with the adoption of Squads?

• What differentiates your Squad from a Scrum Team?

Squads made sense in Spotify’s scaling context, and they might even be compatible with your organization. But it’s essential to understand which problems Scrum and the “Spotify Model” try to solve before doing a CTRL+C / CTRL+V.

At the end of the day, misinformation will always exist and eventually people can spread it even with the best of intentions. The only way I know to avoid these traps is to follow the advice of the wise philosopher E.T. Bilu:

E.T. Bilu would read the Scrum Guide before starting to use Scrum

So, shall we take some time to reread the 16 pages of the Scrum Guide?

Well, and that’s the problem. Prioritization based on opinions (which usually have a weight proportional to the weight of the badge of whoever is opining). When we somehow manage to tangibilize the value of each item in our Product Backlog, the discussion becomes much more rational.

One way to better understand the value of each feature comes through a simple question: how much are we losing by not having delivered this item yet?

Answering this question is not always easy, and often involves a lot of research work. The important thing is to always remember that we’re not always looking for super precise information here. The purpose of understanding the value of each item is to help us make a rational decision.

For example: let’s say a certain item will earn me between $6,000 and $40,000. This range is very wide and may seem to have little value, but if I know that the cost of the item should not exceed $3,000, I can already make a decision and don’t need to invest more time refining my research to narrow this range.

Each item can have a cost of delay in a different format: some tend to grow linearly and others exponentially. There are also those with a fixed date, like compliance with a law with a date to come into effect, and others whose cost doesn’t have such a relevant relationship with delay time. Understanding which types of items you have in your Product Backlog is the first step to rationalizing your prioritization process.

The most common type of item found in a Product Backlog are those whose cost of delay tends to increase over time, whether linearly or exponentially. Imagine a product with the following items in its Product Backlog:

Each item has an estimated cost per week of delay and an estimated development time. If we divide the cost of delay by the duration of each item, we arrive at the famous CD3: Cost of Delay Divided by Duration.

But why is this CD3 important? To answer this question, let’s try to prioritize this backlog in three different ways.

Prioritization by size

If we choose to deliver the smaller items first, our delivery curve would look something like this:

In the first week we would have a cost of delay equivalent to all items summed up (2,000 + 5,000 + 6,000 + 1,500), after all we haven’t delivered anything.

At the end of week 1 we managed to deliver the Notifications item (which was prioritized for having the shortest duration) and with that we reduced our total cost of delay by 2,000. And then we repeat this process for the next items in the Product Backlog.

At the end, we have the following scenario:

• 1 week with total cost of delay of 14,500

• 2 weeks with total cost of delay of 12,500

• 3 weeks with total cost of delay of 11,000

• 4 weeks with total cost of delay of 6,000

In this scenario our total cost of delay was:

(1 x 14,500) + (2 x 12,500) + (3 x 11,000) + (4 x 6,000) = 96,500

Prioritization by value

When we prioritize by value, things change a bit:

• 4 weeks with total cost of delay of 14,500

• 3 weeks with total cost of delay of 8,500

• 1 week with total cost of delay of 3,500

• 2 weeks with total cost of delay of 1,500

In this scenario we start working with the APP item because it has the highest cost of delay per week. At the end we have a total cost of delay of:

(4 x 14,500) + (3 x 8,500) + (1 x 3,500) + (2 x 1,500) = 90,000

Prioritization by CD3

Prioritization by value generated a slightly better result, but we still have room for improvement. See what happens when we prioritize by CD3:

• 1 week with total cost of delay of 14,500

• 3 weeks with total cost of delay of 12,500

• 4 weeks with total cost of delay of 7,500

• 2 weeks with total cost of delay of 1,500

(1 x 14,500) + (3 x 12,500) + (4 x 7,500) + (2 x 1,500) = 85,000

A good reduction, isn’t it? And a great example of how a person acting as Product Owner can have a very positive impact on product development!

Conclusion

Knowing how to prioritize well is important, and to do so you’ll always need to have a good understanding of the value of each item in your Product Backlog.

Formulas like the CD3 calculation can help a lot once you’ve taken the first step: having this sense of value. But this first step is very dependent on the Product Owner’s proximity to the market and a good understanding of their customers’ problems. And well, there’s no magic formula for that. :)

A simple way to do this is to have key criteria so the team can qualitatively evaluate the Sprint that has passed. But which key criteria should we use?

Daniel Pink defines through experiments in his book Drive that Autonomy is one of the three pillars that sustain people’s motivation at work. We can leverage this concept to create a more participative retrospective model in 4 steps:

1 — Ask the team to think of key criteria

Set a short time limit and write together with the team which factors influence the quality of the team’s work.

Remember that the participation of the entire Scrum team is fundamental during all stages.

2 — Limit the key criteria

You can use dot voting to limit the key criteria that will be used if necessary. The ideal is to have between 5 and 10 criteria at the end of this stage.

Important: You can choose to merge 2 or more themes if they are very similar, just remember to do this before voting.

3 — Ask each team member to evaluate the last Sprint according to the most voted criteria

Here we don’t need to do a super detailed analysis. We can use 3 satisfaction levels, like a traffic light.

Example: A person can vote green for the Interruptions criterion if they believe they were rarely interrupted in the past Sprint.

Just pay attention to two details: make sure that no one on the team has difficulty distinguishing the selected colors and ensure that all members have evaluated all elected criteria.

4 — Evaluate with the team the evolution across Sprints

One of the main benefits of this technique is being able to debate with the team what has influenced the evaluation of each criterion, and having a small history can help a lot to perceive some trends and possible correlations.

Looking at a joint evaluation of criteria that the team itself established is a great way to break the initial ice of a retrospective.

This can be the initial push the team needs to start proposing actions and experiments with the potential to improve their way of working.