Export all images from a Word (.doc) document .. and rename them

During the summer, I faced a challenging task for the book: “…and also, if you could hand us all the images in the book, thank you very much. Oh yeah, if you could name them CH01_01.png, CH01_02.png, etc., it would be great.”

Yes, I felt a bit overwhelmed.

Since Kanban In Action now spans 13 chapters in different .doc files, I immediately realized two things:

• Marcus, you’re foolish for not tracking these images somewhere.
• This is too massive to handle manually.

This post details how I tackled the problem. It took me about 2 hours in total.

Export all files in a Word document

The chapters are written in .doc format (for some reason), but I remembered that the newer format .docx is essentially just a zip-file. Maybe, just maybe, that could...

I ran across a great post by Dan Kindeborg that taught me a lot about effect mapping (prequel to Impact mapping). “Sadly” it was in Swedish, and I couldn’t keep the material to myself. So I asked Dan for permission to translate the original post here on my blog. He was totally fine with that, so here it is. When you read stuff about UX and design below, it’s Dan’s words. I still know nothing about that. But I learned a lot by reading this, and I hope you do too. So, from the next paragraph when you read “I think,” it’s actually Dan thinking. Just so you know. Over to Dan.

Lean UX with effect map

An IT project often starts with an idea about how business impact can be created. Someone has invented a new way to make money or streamline their business...

I was asked to help a client facilitate an Impact Mapping workshop. An initial map had already been created, so we discussed it to understand where the conversation would lead.

The main goal (referred to as the WHY on an impact map) was well-established: “Get 100,000 active users by 2014.” This clarity was a relief since such goals can often lead to lengthy discussions with political undertones, especially on a company-wide level.

However, the proposed WHO on the map confused me. It listed different teams in the organization as the WHO that would “help us reach our goals.” This didn’t sit right with me, and I sought clarification.

I tend to explain the level of impacts as “not you” and the level of deliverables as “you.”

Gojko Adzic provided a concise answer: “I tend to explain the level of impacts as ‘not you’ and the level of deliverables...

Well the title really says it all, but there’s big changes coming for me and my family this autumn. We’re moving to Bandung, Indonesia to work at a hospital for the Salvation Army there. That statement may cause some questions to arise in your head. Let me see if I can foresee them?

Why?

There’s three big answers to that question and they come in chronological order. On my first date with Elin (8 years ago now, my wife since 6 years) she told me that she wanted to work abroad. In a “developing country”. That’s her life long dream and the reason she’s decided to become a nurse in the first place. Now the opportunity has come to fulfill that dream - and I get to be part of it!

Secondly: I have the Salvation Army to thank for so many things. Things that I use in my everyday life at...

I was at the hairdresser yesterday. I’m not very particular about my hair, but it was starting to look a bit like this:

When I want it to be more like this guy to the left.

The conversations at most hairdressers in Sweden are not very interesting, mostly due to the fact that I’m not interested in hair, particularly mine. So while I was seated in the chair, thoughts from some discussions on prioritization and flow for a team at a client came to mind.

Low WIP and flow are concepts that are well understood and often implemented at this particular client, but the implications of such a strategy were interesting. And, oddly enough, I saw some great strategies implemented at my hairdresser.

I sat down with some guys, and we talked about Mob Programming as they had read my blog post on the...

I’m back from AgileSverige, the premier agile conference in Sweden (IMHO), and this year was no exception. Or rather, it was—exceptionally great from where I sat.

One of the talks that really got me thinking was about mob programming by Tobbe Andeberg and Ville Svärd. Not the technique itself but rather the implications of such a team.

Mob programming is easy to do: put your entire team in a room, give them a single keyboard, and work together to solve the problem at hand. Then take the next problem. And so on. It’s like pair programming but for an entire team.

I’m not sure a team would benefit from mob programming all the time, but the concept got me thinking, thanks to the great presentation by Tobbe and Ville. What if… In this post, I’ll share some ideas and thoughts that sprung from that...

In recent years, the Lean Startup movement has gained significant traction. It offers a compelling framework for rapidly validating startup ideas. However, like many concepts, it’s often misinterpreted and misapplied. In this post, I’ll share some reflections on the concept of Minimal Viable Product (MVP) and its relationship to learning.

MVP

At the core of Lean startup methodology lies the scientific method, emphasizing experimentation and learning. The MVP, or Minimal Viable Product, serves as a vehicle for conducting these experiments. It’s not merely a delivery package but a tool for validating hypotheses and gathering insights from customers.

User Stories, MMFs, Themes, and Epics

It’s essential to distinguish between MVPs and other project artifacts like user stories, epics, themes, and MMFs (Minimal Marketable Features). While these terms often overlap, they serve different purposes and represent different levels of granularity in project...

I’m surrounded by brilliant minds at work. Both at my company (Aptitud), at my clients and in my community. They make me think a lot and quite clearly thinks a lot themselves too.

But sometimes I think we think too much (cannot wait for the reaction to that contradictive sentence :)) - and we should do things instead. It’s in doing we learn and see how stuff work out and how well our hypothesis stands up to the reality that we throw them into.

Let me give you a few … well examples and ideas that have formed my thinking around this.

Getting to know new people

I have never been in a situation to hire someone - although I have done A LOT (50+) prospect interviews. This is a ridiculous situation; 1 hour with someone that I never have met and then asked if I think they...

In my last post, I shared two stories that got me thinking about what we code for: change or stability.

The post received unexpected attention, prompting questions that led me to reflect further. Here are some thoughts and answers to recent discussions:

Mindset vs Practice

My initial post didn’t emphasize the mindset aspect. Coding for change means anticipating future modifications and making them easy. It shifts how we approach coding, focusing on simplicity and adaptability.

Consider a thought experiment: imposing a constraint to rewrite code every few months. How would this change design, coding, testing, and documentation practices? While impractical, it prompts valuable reflections on code flexibility.

“WHAT WAS CHANGED IN THE GAME SPECIFICATION???”

A question from Reddit referred to a game development scenario where we introduced a new player feature. We adapted our code to accommodate this unexpected change, leveraging existing infrastructure and generic constructs.

Let me tell you a story: when I was in university I took an “advanced” object oriented programming course. This was my first exposure to the topic and I was lost big time. The course was taught in SmallTalk had a very different format; the first day we got an assignment from the professor that ran throughout the 4 week course.

We were very excited since we were going to write a game. An old-school text-input adventure game a la Zork. We teamed up three people in groups and went to the professors small crammed room. Here we got the instructions on a single sheet of paper. We almost ran out of there.

Just as we reached the door of the room he called us back (I’m sure he had time that call to perfection):

“Oh yeah, almost forgot. Two weeks from now I will come by and change...