How do you get so much done? Where do you find the time?

This is a question that I often get asked and it always catch me off guard. I don’t have a recipe (or do I?) and I don’t think I get more done than others.

But last time when I was asked this question I stopped for awhile and thought to myself - what do I do, and is that something others don’t?

In this particular case I referred to a blog post I’ve written and the question back was:

How do you find the time to write blog posts?

In this blog post I share a couple of my … tricks.

Yes, yes … I know. I do way too much Google Sheets for my good. But that tool is SO amazing. It’s becoming my first go-to-tool when it comes to small simple tasks at the office. And it allows us to be more data-driven and visual.

And it’s very easy to build aggregation tools for people around the office. For example; the other day we were wondering what kind of technologies that was hot in different cities in Sweden.

From that question, until I’ve created a simple but powerful tool to scrape data from Indeed.com, presented it with a simple filtering function and got it in the hands of the sales team was 45 minutes.

In the process, I learned about two new friends; IMPORTXML and the slicer-feature of Google Sheet.

Let me show you what we did.

Where’s the information?

I headed out to the Indeed...

In my current job, as Head of Quality and Curriculum at </salt>, my thirst for being data-driven is frequently useful. In particular when it comes to test results for the developers in our courses. We test the developers every weekend (for 10/13 weeks) and we have now run 4 courses using the same tests… A gold mine of knowledge if you can mine it.

To help each developer and us, understand how they are doing we produce a diagram that compares their results to the result of their class (ca 30 people) but also compared to all classes (to date 4 x 30 people).

In the end we want to produce charts that looks like these:

But getting there has been quite tricky but oh so rewarding. At the end of this blog post,...

I’ve just finished a huge project here at work. I have recorded reference recordings of all the lectures in the </salt> bootcamp. It was quite fun, quite exhausting but also quite rewarding as it basically drained me of every system development knowledge I have in me. And some that I didn’t have in me (there’s CSS in there, my friends…)

Obviously, I cannot share the result - but what I can share is what I learned.

I am a fan of embracing uncertainty since I first heard Dan North all those years ago. Most of the work I do is development hence naturally uncertain, as learning is the main constraint. This has led me to ditch the idea of being able to estimate how long a task or project will take before we start.

But still I and teams I’ve coached are often asked this. Before the...

I’m about to run a few retrospectives with a group of people with little to no experience of agile previously. In doing my preparations I went back to the core and start of retrospectives, why we do them, their purpose and meaning, etc.

Before long I stumble onto something that I have had some issues with; the Retrospective Prime Directive. But as I read it and was thinking about how to introduce the whole concept to retrospectives to my friends I realize that without the Retrospective Prime directive being agreed on - retrospectives are not worth the time. Or at least not interesting in the long run.

Let me explain what I mean.

The retrospective prime directive

The retrospective prime directive is originally written by Norm Kerth in Project Retrospectives: A Handbook for Team Review, all the way back in 2001. The same year as the Agile...

No - this post will not be about Christianity per se. You don’t have to worry.

That said I am a Christian and proud member of the Salvation Army and I wanted to share something I observed during two (actually) spiritual days. Something that I think is sorely missing in business today. Something crucial.

I’m not talking about God now - although he’s often out of the picture too :)

Having an (any) work in process (WIP) limit to your workload is the best way I know to improve speed, quality and focus on value in what we do. This goes for individuals, teams and whole organizations alike.

As you apply a limit of how many things you will work on at the same time, you very soon will start to prioritize among your work. (Psst - I’ll let you in on a secret: if you don’t have limit you still prioritise, because at any one given time you are only working on a thing … but that is a topic for another post)

Being nudged to do this prioritization is a Good Thing (TM) if you let it. It starts moving you towards knowing WHY you are doing something NOW and away from ensuring that you are kept busy (or keeping people busy)

Ok but inevitable very soon we...

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...