PUBLIC SPEAKING

Workshops can be powerful tools, but with a clear purpose, full participation, supporting structure, managed time, enough information and trust in facilitator, they are even better.

Unit tests define the collaborators and the purpose of a piece of code. When reading code with unit tests, we can read the tests first, and focus on how the unit interacts with the system. Then reading the computational code is only about the implementation of that unit. Separating concerns like that lightens the cognitive load.

Some testing frameworks are so powerful that they take away all the design pressure. They have a place in a codebase that stinks so much you can't work in it without some perfume. In all other cases they disturb your nose for well designed code.

Code needs something to make sure it works as intended. Using asynchronous code reviews for that will slow the team down. Reviewing code as a group is a good tool for knowledge sharing, but do it on production code.

Estimation is a place for quick assessments that everyone agree on the scope. It is also a way to discover technical knowledge that needs to be shared in the team.

Samman technical coaching improves learning by applying the knowledge in a familiar environment as a team. Everyone learns together and can validate the new skills where they will be applied.

IT-stress has gotten into the top list of problems in the workplace. This is a text about changing that.

When talking about software quality we should separate internal and external quality. Internal quality makes it easy to write software that do what we expect. External quality is software that does what the end users expect.

DevOps and FullStack are orthogonal concepts. One is about technology and the other is about the software lifecycle.

The software quality suffers when a team, and their code, try to satisfy conflicting needs. Communication overhead, and hard dependencies on work by other teams, make it worse. This is a compilation of some things commonly done to limit this.

The SOLID principles help us write loosely coupled code. We also know that the structure of the organization is reflected in the resulting code. So how can we translate SOLID to help with a loosely coupled organization?

Creatures with an innate need to solve problems, like octopuses and software developers, will look for problems to solve. Invite the development team to be a part of solving the business problems, and provide octopuses in captivity with puzzle boxes.

The most important thing to learn is improvement. Copying someone is not enough for true excellence. That is true for clothing and organizations.

Your retros will be more productive if you do them right. Read this post, "Agile retrospectives, making good teams great", and/or get someone who facilitates your retrospective.

The agile manifesto states things that are valued over others. If that is drawn to an extremes, we don't pass on information to the future, making maintaining a system harder. Be aware of your tradeoffs, always.

The agile manifesto is written as a reaction to the IT-industry of its time. As it wins ground it also slowly destroys its original context. If we lose sight of the heart of agile, we might end up in the other ditch. People growing up with agile will sound like waterfall evangelists, but only since they take the agile manifesto for granted.

A personal book review of "Getting Naked : A Business Fable About Shedding The Three Fears That Sabotage Client Loyalty" by Patrick Lencioni.

A brief description of three tools for personal improvement: acceptance, meta cognition and growth mindset.

As Tolkien puts it in *The fellowship of the ring* “Not all those who wander are lost.” and "even the very wise cannot see all ends.” This is a text about agile software development and adventures.

We want to build less inventory, limit cognitive waste and practise continuous improvement. This applies also when working on the project backlog.