The last couple of weeks I have talked a lot about prioritization at my current client. In many conversations, I’ve felt the need to go back the foundation of things that I build my coaching and consulting on. For example, I might question how we prioritized as we done, and then I notice that people become defensive - thinking that I am questioning them rather than the way. This has led me to reflect, formulate and then re-iterate three basic assumptions that are increasingly important to me:

1. Everyone did their best, and continue to do so
2. There’s always more work to do than we have the capacity to do
3. We don’t know what will work best

Let me describe a little bit more what I mean.

At my current client, we are trying to make a change to focus more on flow than on resource utilization. This is harder than it sounds because much of the current ways of working, structures, roles and rewards are built to support another mindset.

One of the things that lately have popped up for me are the words we are using to describe the roles we have in different parts of the organization. This heavily prevailing in the IT-industry and maybe agile actually has helped to cement a few of these (an excellent keynote by Michael Feathers put me onto that idea).

This also ties into a great quote from David L. Marquet and his excellent Turn the Ship around book

There’s no they on Santa Fee!

Let me try to explain.

Recently, I received an intriguing question from Enea Zuliani and Michele Degrassi, who, after delving into Kanban In Action, began utilizing Kanban in their work. They posed a question regarding selecting a kanban (card) to work on when all options possess identical characteristics. With their permission, I’m sharing the question and my response here.

Deciphering Kanbans

Firstly, kudos for embracing the essence of kanban as a visual card system. In the realm of lean workplaces, the term “kanban” embodies the concept of visualizing work. However, in the IT industry, its interpretation varies, often encompassing process improvement methodologies or the visual board itself. Nevertheless, the core principle remains:

The purpose of kanban is to limit the number of kanbans so that each kanban flows fast over the kanban.

Thankfully, that wasn’t the question at hand.

Crafting a Response

In essence, the query revolves around how to...

I’ve just attended Agile Greece Summit which was a wonderful event. Many awesome speaker, met a few of my heroes (Linda Rising, Michael Feathers, David Snowden and Mark Schwartz) and met new friends (Portia Tung, Alison Coward, Lisi Hocke, Gary Crawford and Gwen Diagram, just to mention a few) and finally had many interesting and challenging conversations throughout the conference.

All in all it was a very good event to attended, expertly organized by an awesome team and I consider myself lucky to have been here.

As with many conferences an underlying theme starts to emerge from the different talks. I suspect we take inspiration from other speakers and conversations, but I’ve observed this too many times to think it’s a coincidence.

I wanted a few reflections that I got during this conference. It can be summed up in a...

I’ve had the great opportunity to do some extra work in a very different environment this week; I’ve been a musician in a professional orchestra - the awesome Östgöta Blåsarsymfoniker.

It was quite a treat to work in this group and get to play my instrument on a high level. Also, as an amateur, getting paid to play my instrument is … mind boggling.

Being part of this group for a few days made me notice a few rituals and practices that I think we can learn from. I wanted to share a few thoughts on them here.

Recently, I undertook a fascinating task for a client. As the “Head of Curriculum” at the School of Applied Technology, my responsibilities include crafting the content for bootcamps. Our inaugural bootcamp, “Fullstack JavaScript Developer with React and Express,” required me to swiftly set up 33 developer computers to ensure students could start coding within hours.

Here’s a rundown of how I accomplished this feat and the insights gleaned along the way.

As an agile coach working in bigger companies you are sound exposed to JIRA. JIRA - a tool that started out as a good idea and then grew into … a not as good idea.

But hey - we got to live with it, I suppose.

</rant>

In this post I wanted to show you how to easily import data from a JIRA query to Google Sheets (or Excel I presume). That is, in all honesty, not that complicated so I will share a few other tips around this whole process.

In short:

Tweaking export of JIRA data for fun and profit

At my current job, we heavily rely on Google Apps (Docs, Slides, Sheets, etc.). I’ve grown quite fond of them, especially the seamless integration between different apps. One of my favorite features is the ability to create a chart in Google Sheets and easily copy it to Google Slides for presentations.

Today, I want to share a small hack I’ve implemented to keep those slides updated automatically. This is particularly useful for dashboards or presentations displayed in a kiosk-like setup.

Copying the Chart

When copying a chart from Google Sheets to Google Slides, there are two options: as a picture or as a link. For our purpose, we want to use the link option:

1. Open the spreadsheet containing the chart you want to copy.
2. Click on the chart and then click the three dots (…) in the top-right corner.
3. Select “Copy chart.”
4. Open the document or presentation where...

I’ve been playing around with refactoring a Koa application to use modern JavaScript constructs like async, await => and do away with generators etc.

In doing so I had an epic battle with mocha, monk and supertest to use async / await etc. I finally found a good structure for this purpose that I wanted to share.

This is the fifth and last post in a series where I refactor an old (4 years) code base (an API written in Koa) to modern Javascript and tools.

Here are all the posts in the series

• Part I - get the tests to run
• Part II - where we clean up the test code a bit
• Part III - where we start to move over to async/await testing
• Part IV - where finally do something about the production code, and fix the other parts of the application
• Part V - wrapping up by refactoring the root application - this post