Today I had a session with the management group of one of our hospitals. We ended up talking about how to choose what we’re going to do next. Questions like; “but how can we know what is best”, “there’s so many things to do” or “everyone have a different opinion” were discussed during and after the meeting.

I was reminded of a tip from a colleague and (to me) mentor from way back, Lars Littorin. I was complaining about so many things to do, not knowing where to start etc. His answer:

Great! Then you know exactly what to do; make a list of the things you need to do, and then start doing one of them.

There’s much truth in there. I think Lars is a great guy, but I doubt he knew how much use I have had from this single quote. Maybe, just maybe, he doesn’t...

Got a recommendation to read Nature by Ron Jeffries and I did. What a read! I loved it from the get go.

My short review is quite simply;

“This book made me think. It left me with more questions than I had going in. But better more concrete questions. Seeking simple(r) answers. Also it’s sprinkled with challenges and gentle provocations of the current state of mind and process.

The underlying principle ‘Simplify it’ is something that resonate very deeply with me. I recommend anyone doing, struggling to do or thinking about doing this thing we call ‘agile’ to read this book.

And then give a copy to every important person in your organization.

Thank you for a great read!”

This is a just a short post, mainly an idea that I can get out of my head.

I’ve been helping the management team at one of our hospitals to come up with something to track our progress against. The main question was actually quite simple:

How would we know if this hospital is awesome?

We came up with a couple of balancing scores that we will take for a spin in our first experiment round. The idea is the these values will guide our actions - if we can make things that improve the values (one or more) it’s a good thing. In the spirit of balancing scores we are keeping track on more than one to make sure that we’re not tilting our efforts toward, say only financial values.

Hmmm… need to write some of those ideas down, maybe. Ok - now to the topic of...

A couple of days ago I offered my services to one of the hospital directors here. In their current situation they could need some structuring and focus on start executing. I know that I can help them with this (using my normal “tricks” of visualization, transparency and short iterations etc) and hence asked if I could be of assistance.

Now, this particular director is a really smart one and the response was quick, to the point and a real head twister for me:

Thanks for that offer! What is you can help us with, then?

I was a stumped! What do I do? Why would anyone want that? Who am I to think that I can help them? I’m an IT guy, no formal training, no formal authority here. Why should they want me?

I ended up referring to my past work and try to describe that to the director...

I re-read a post I wrote about 6 months ago, after a consultancy gig at Nintex. And one thing in there resounded with me and some of the conversations I’ve been having lately.

I wrote (and said):

Stop changing and start experimenting

This would probably be my #1 tip for change management; don’t do changes - do experiments instead.

In this post I thought I’d examine that recommendation in a little more detail.

Just ran a my count script into the _posts directory of my Jekyll installation. 999! and then I started this post.

That means that this is the 1000th post on my blog!

I only have 3 words: Un. Believe. Able.

I never, ever thought that I would write 1000 posts.

Through this blog I’ve learned so much, connected with so many people and got so many opportunities I never would have got without “throwing myself out there”.

This post has two parts: history and stats.

We’re ready to sit down to eat. The kids comes running and I do the regular check-up: Nope - all hands, some of the faces covered in dirt. Me:

Wash your hands!

The run off, remarkably without complaining. 15 seconds all three of them are back. Hands, faces and much of the shirts are dripping with water. Hands and faces are still dirty.

This is my fault. I was really just focusing on the activity rather than the outcome. I see this sickness in myself, many organizations and even our community at large.

In this post I wanted to examine this thought a little closer. I have no idea where I might end up, but I’ll type on for awhile and then structure it into something worth reading… or you’ll never read this

In the last post I promised to write something about “git, pushing and deploying”. This is purely from a personal need since I have used make for those things. I wanted to see if I can move all of that to use npm and package.json instead.

I’ll also add a compile and minification step, just since that it’s a common need.

[UPDATED] This, and other posts on npm scripting, has drawn a lot of attention. I wanted you to know that I have created a PluralSight course on this topic, published in late October 2015. You can find it here.

Also, don’t miss the other posts on this blog on npm scripting:

• npm scripting: git, version and deploy
• npm scripting: configs and arguments… and some more tricks
• Pre and Post hooks for npm scripting

If you liked this post...

I’ve written two posts on npm scripting with package.json and during the course of these post I’ve picked up some tricks that I didn’t really use in the posts.

This post will hence be a bit less structured by contain some small tidbits of information for you to, hopefully, enjoy and use.

I’ll be working of the code here and add all the features I describe (as far as possible) to that repository.

[UPDATED] This, and other posts on npm scripting, has drawn a lot of attention. I wanted you to know that I have created a PluralSight course on this topic, published in late October 2015. You can find it here.

Also, don’t miss the other posts on this blog on npm scripting:

• npm scripting: git, version and deploy
• npm scripting: configs and arguments… and some more tricks
• Pre and...

npm is at the core of developing in Node. Most of us use it to get packages, set up the package.json etc.

But when you put it together with the vast possibilities in package.json you get another gear. Then npm can actually become a build tool - driving every aspect of your development. Without getting unwieldy and out of control.

In this post I wanted to examine one of the lesser known features of scripting with npm and package.json; pre- and post hooks. In doing so I will most likely brush on a lot of other subjects too. We’ll see how it goes.

[UPDATED] This, and other posts on npm scripting, has drawn a lot of attention. I wanted you to know that I have created a PluralSight course on this topic, published in late October 2015. You can find...