The last couple of weeks an old “friend” has made its appearance: fear. This time it is a special kind of fear that I’ve seen many times in organizations that started their agile journey: the fear of forgetting important things.

In this post, I wanted to talk a little bit about that just as a concept and then give a few pointers and indicators on what you can do to get rid of that fear.

What’s with this fear really?

Often this particular fear manifests itself by very long lists of work not done, or backlogs that just go on and on. I’ve seen lists of more than 500 items, some of them more than 3 years old.

And yes - they are all important. Prioritized but important.

We don’t want to lose it

Often when I ask about why we should keep it there, the answer is...

When I started my current gig about 3 months ago the tension around releasing was tremendously high. Also we had failed the last couple of releases resulting in even worse relationships with our customer and messy rollback handling and procedures.

We have now done three very simple changes in our process and technology that made a big difference for us and for the relationship with our customer; ditch iterations, shorten release cycles and feature toggling.

In this post I wanted to tell you a little bit around how we did those and the benefits it had for us.

I downloaded a new markdown editor called Typora that looks amazing. Now I just wanted to try it out, and needed something to write about.

Also I’ve noticed that Claudia has come out with some new releases and that AWS Lambda now supports Node 4.3.2 - which is awesome.

This post gave an opportunity to fix both itches above in one go. So this is an updated “Get started with Claudia JS for AWS Lambda”-post.

At my current client I don’t have a role name. Or rather I do but that’s not what I do, nor what I am there to do. It struck me that I have had this problem before. Many times.

Here’s some way it manifests itself:

I’m not “development manager” that some people call me. I have no formal authority, no staff and no budget. And I have responsibilities that stretches over the development team.

I’m not scrum master that is the fall-back term for anything that is around agile and doesn’t fit the normal organizational scheme. However none of our teams work with scrum and i’ve not worked with scrum for at least 6 years. I’m also pro-flow-based processes rather than iteration-based.

I’m not a agile coach since that’s a term that I barely myself understand what it means. I don’t want to be a coach to make people more...

Yesterday we had a couple of very interesting discussions in the team, that got me thinking on being clearer around the purpose of kanban.

In this team we have made a lot of changes lately to try to improve our lead times and throughput. One simple thing that we changed and that made a significant improvement was to simply release more frequently. When I first arrived here the releases were done every 6 weeks. Going to every 4 was just a simple change, and increasing frequency to ever 2 weeks was a very natural next step that no one objected to either.

But then a question came…

I was in a couple of very interesting discussions yesterday, through the mean of a SAFe course. Just sitting in the room with your peers and stakeholders, off-site, discussing how to work more effectively is really powerful - it turns out.

“Who knew?”, he exclaimed with some irony in his voice but still some hope and joy.

Ok, in our discussion I, again, ran into the point where I simply don’t understand the reason for organization your company in a certain way.

I just have to write this down, and see if it becomes clearer for me. You can read it too if you want.

I’ve been on a SAFe course. I was very interested, because like many people I’ve heard much about this, had opinions on it but haven’t experienced it first hand.

The context of the training was that it was given for my client. Not as “let’s get started with SAFe” but rather to align and give us all a common understanding on nomenclature and concepts.

I wanted to share a few thoughts in this post. If you were looking (or hoping) for a SAFe-bashing by a Kanbanista… Sorry - I’m not that guy. I’m also in way too good mood to bash anything right now.

Something amazing has happened! I am one of 6 nominees to the prestigious Brickell Key Award.

Not in my wildest dream did I think that the kanban community would appreciate things I’ve been involved in enough to nominate me for this award.

You can help my nomination by supporting me in the form on that page.

But first - let me tell you a little bit about why you should do that, and what this price even is and some other questions that might go through your mind.

In writing the last post I stumbled into a little nugget of gold that I never tried before claudia test-lambda.

This is a quick and simple way to verify and smoke test your lambda function once deployed.

And it’s super easy to use. Tag along

AWS Lambda functions are really great since the server is out of the picture. We don’t really need to care about it, since AWS will handle scaling, patching, starting and stopping for us. It’s just us and our code. Ah bliss!

But wait a second: what if I do a console.log? Where will that be output? There’s no console, since I don’t have a server. Or is it?

Spoiler alert: Claudia got you covered.