In my current job (School of Applied Technology) we give out weekend tests each weekend of the 10 first week of each course. With 30 developers in each class, it means that on Monday after each weekend we have a lot of work to do to correct the developer’s tests.

We have basic validation through a suite of tests that we run against the developers’ code. And we run linting. The real value, however, comes from comments and suggestions for improvements that we could give to the developer.

To speed the tedious part of the work up we have created a script that helps us:

• Get the developers code into the correct place. The developers upload their solutions to a shared Google Drive and we have the Google Backup tool to synchronize those folders down to our local disk.
• Run the linting and test towards each developer’s code....

One thing that I love in coaching and consulting is when things stick. My way to try to get there is to tell stories (psst - there’s a book on that) to try to emphasize or bring out certain points.

What I find very rewarding is to hear people relate these stories to each other later on, when (they thought) I was not listening.

Just the other day I walked passed two people and I heard:

Yeah, exactly. Remember: when was Lars happy?

This is one story that I’ve told many times and I wanted to share it here too. It was a powerful lesson on true value, customer focus and lead vs flow time for me.

I have been involved in many agile so-called transformations over my, let’s face it, long career. And the more I get to do that the less I care about the word agile. Because agile is “just” a way to behave - it’s not an outcome. The outcomes are what we are after, the effects, the values. I’ve found it much more fruitful to discuss what those values are and means, than to argue whether Scrum holds up for scaling or not.

In this post I wanted to discuss three shifts in mindset and culture that I found: Important - as these shifts in thinking will or will not, hold your agile efforts back.

• Fundamental - as in; goes beyond (below?) being agile or not.
• Not talked about or understood in the same way
• Start asking some tough questions and hence rapidly increase learning.

These topics are:

• Shift...

Many years ago I wrote a little site to keep track of fun things that my (then only one) son Albert said. I called it Abbe Says and it has been granting us and our friends great joy.

At its core, it is a very simple blog/content management system that I wrote in .NET (3.5 I think) and published on the first serverless offering I heard about - AppHarbor. I didn’t even know the term back then it was more like: HEY! Give them your codez and they'll make it run on Internet My feeble brain exploded.

Anyhow - I cannot update it for various reasons and I need to move it to a more modern stack. Thinking of Svelte and to run it from some static served …

I’m getting ahead of me - first we need to get the data. This post describes how I...

Agile is soon (?) to be forgotten and ditched like yesterdays clothes if you ask some agilistas that I follow. I think the reason is that we have watered down the meaning of the concept by applying the name to more and more un-agile things. Soon we will be able to become agile without letting its ideas and principles changing a thing about what we do or how we act. Because agile is just some simple, yet powerful, ideas - originally described in the Agile Manifesto.

I yesterday posted the following at twitter:

This is a companywide board we created at a client. It shows all the #valueStreams their #impact and deliverables. At weekly meeting representatives for the entire company gathers and prioritize and replan. A continuous #bigRoomPlanning if you like. I’m at back of the room pic.twitter.com/gXbqu8y3eu — Marcus Hammarberg (@marcusoftnet) August 13, 2019

I wanted to write a short little post on a misunderstanding and confusion that pops up once you start to create cross-functional teams;

Autonomous doesn’t mean isolated

I have created a course, a boot camp to teach people to become programmers in 12 weeks. It’s quite amazing and you should apply if you want to change career. Check out Salt - School of applied technology

Obviously, that cannot be done. But we do it anyway. And we succeed - we get rave feedback from the places where our awesome students are working.

There are a few ingredients to the successes; people being highly motivated (I can write books about that) and mob programming are two of them.

But in this post, I wanted to write about something that I think stood out for me after observing 3 classes in a row now. And it’s something that you can do and get a lot out of too.

Been talking a lot about the consequences of prioritizing today at my client. And about psycological safety

This excellent story that Staffan introduced me too, came to mind. (I’ll summarize it below - this is just an intro, to get you to read on)

And I came to think about how the consequences of prioritizing one thing over others, often end up becoming blame for the team. When it really should be praise…

I’ve always believed in the transformative power of books—they alter our perspectives and enrich our understanding of the world. As an avid reader and unapologetic learn-o-holic, I recently delved into When Will It Be Done by Dan Vacanti, and it revolutionized my approach to process metrics. My previous musings on the topic, documented in a series of blog posts, were challenged by Vacanti’s insights, prompting a reevaluation of my methodologies.

The Fallacy of Averages

Vacanti’s work references “The Flaw of Averages” by Sam L. Savage, which elucidates the misleading nature of averages in statistical analysis. The book’s premise—that averages fail to account for outliers and distribution nuances—resonated deeply, highlighting the inadequacies of conventional metrics.

Consider these illuminating anecdotes:

“If Bill Gates walks into a bar, everyone in the bar is, on average, a millionaire.”

“Never cross a river that is, on average, 4 feet...

I’d like to start by acknowledging the remarkable individuals I encounter as a consultant—those brilliant, fun, and experienced professionals who seldom surface online or at conferences. Scott Hanselman aptly dubs them Dark Matter Developers, and they are the unsung heroes of the industry. This blog post was sparked by one such individual, Yngve, whom I had the pleasure of collaborating with at a client’s site.

At this client, where Yngve serves as an infrastructure architect, we faced a common challenge: measuring software quality. The teams felt overwhelmed by the perpetual neglect of technical debt, constantly being pushed to deliver new features without addressing underlying issues. We lacked a concise means of communicating this dilemma to our non-technical colleagues.

To address this, we devised a simple yet effective metric: the Marie Kondo-index for software quality.

The Complexity of Measuring Quality

Measuring software quality is notoriously complex, as eloquently discussed...