Lizard Optimization is another great book by Gojko Adzic. I have probably read everything he’s written by now and I think this book is one of the best he’s put out there.

In the book Gojko gets a chance to use not only his fun and engaging writing style, but also his fascination for weird events and fun stories. He puts those two elements together to help us to appreciate the rare, annoying and down-right bizarre usages of our software. One of Gojko’s earlier books was called Computers vs Humans and was only about stories where computer misusage, bugs and strangeness led to fun and even dangerous situations.

In Lizard Optimization, Gojko makes the claim that there is value in these unintended usage, strange bug reports and frustrated admin-users. They can actually guide us to pivot how our software can be used. By following-up on what the misconceptions or...

Back in 2010, I was very interested in BDD (Behavior-driven Development) as a stepping stone into agile testing-thinking as a general great tool to foster better conversations.

Since I was working on the .NET platform I naturally looked at SpecFlow which was very much in its early days back then.

Those two interests, in hindsight, might have been the most important things in my programming career.

I wanted to write this, not to boast (because it’s not much to boast about honestly), but to inspire and celebrate the amazing ingenuity and drive of our community.

Ever since I first read When will it be done by Daniel Vacanti I have been fascinated with how much prognosis work that can be created using very little data. I have written extensively about these “kanban metrics” in other blog posts, should you want a deeper understanding.

Dan and the Actionable Agile Team have created a brilliant tool called Actionable Agile which has many more capabilities than I will show here. This is a straw-man version, BUT I learned a lot of the mechanics behind the scenes in creating this and I hope you will too.

English is not my first language, as I’m sure any reader of this blog knows. But I chose to view this as a superpower since I then can see things with fresh eyes. For example, the true meaning of words and phrases.

I still remember when I understood the difference between effectiveness and efficiency. Those are the same word in Swedish, but when I understood the difference a lot of things made sense when it comes to agile and lean stuff. Read more here

Last week I had another revelation like that - when I realized the difference between value and valuable. According to Dave Farley it’s a common mistake he sees for teams to adopt user stories effectively. I think he is right.

Hold on? What are we testing here? Now I’m only testing the framework code

I’ve had this conversation many times, mostly with myself, and a few days ago with Johan. It might feel and seem like a failure but it is often the beginning of improvements and deeper understanding.

A long time ago I stumbled over the motto of Bob Bemer and it is both cool, nerdy, and useful

((((DO SOMETHING!) SMALL) USEFUL) NOW!)

In this post I wanted to unpack, what I think, it means and show you how it can be useful to tackle beasts that you haven’t dared or have the strength to do something about.

I even have a screensaver picture that you can download here

One little nugget of gold I picked up when working for Spotify was:

Always assume positive intent

However, I’ve now realized that it’s a bit one-sided and it opens up an unexpected opportunity for building a bad culture. Also, it touches on one of the reasons I never wanted to be a manager.

Let me explain.

Always assume positive intent

Always assume positive intent as a general rule I think is good advice. I’ve seen many conversations that could have benefited from some “hey - maybe they don’t want to hurt me?” at the outset. Just taking a little effort to think that the question comes from someone with good intent, before jumping to conclusions about them wanting to do something bad to me - that’s how I understand “Always assume positive intent”

Interestingly enough, every time I talk to people that have had this saying floating...

A common problem I see on #kanban boards is that we are moving tasks, not stories. This misses one of the core ideas of #lean, is hard to report status for, focuses on resource utilization, and invites compartmentalization (anti-teamwork). But other than that – it might be a good idea 😊 Let me explain.

Over the years I and many around me have periods of time when we have too much to do. That is we have more to do than can fit in the time we have to do it. Pretty common, especially in the workplace.

In these times I’ve noticed many people trying to be helpful and give the following advice:

Be more careful in how you plan your time.

It’s said with the utmost well-meant intentions but it is honestly not helpful. Quite the opposite, in fact.

Yesterday I had a really weird experience and I wanted to share it, not as something reflecting good on me, but a reminder of the value of sharing knowledge and learning from people around you.

I have bumped into people that have taken #agile and #lean to other and better places than me, and done more of it than I ever thought. Of course and it’s lovely.