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.

The last week I saw yet another time when embracing uncertainty and embracing an experimental mindset, gave us great benefits and potential productivity gains.

I wanted to share the story since I think it highlights these different mindsets and approaches in an awesome way.

It’s also a great story…

I’m a fan of physical boards. But I have to say: many of the tools I’ve used are amazing (like JIRA, LeanKit etc.) in that they support working with the tool in a great way: shortcuts, intelligent search and great design.

But I can’t get around the fact that I don’t think that they support me and my teams. Already now I can hear defenders of these tool racking up arguments and showing me better ways to do the things that I’ve experienced as problems.

This post is not about that. This problem is about the general notion of any tool has it’s limits and that I run into more of them in electronic tools than I do using physical board.

Also this is my experience - your mileage may vary.

In my last post on Claudia JS we only created a very simple function that echoed some data back to us. Still amazingly cool since that echoing scales to whatever load we will put on it, but a bit meek maybe.

In this post I wanted to up the ante a little bit and store some data, more specifically in the AWS Document database called DynamoDb

Many teams I visit nowadays have ditched story points and start to use Small, Medium, and Large (aka T-shirt sizes) estimation instead. I like that. But very often a smell is creeping into the estimation, removing the “relative” out of “relative estimation”. Here’s how this problem will reveal itself. When someone suggests that you’ll use S, M, and L for your estimates you will soon hear:

Ok - so a S is 1-2 days, M 3-5 and L 5-10 then or what’s the scale?

Don’t do that - it’s the wrong way around. In this post I’ll explain why and what is a better, more trustworthy, candid, and transparent approach.

Why attaching day-span to the estimate is bad

Well, it’s quite obvious isn’t it; doing that (S = 1-2 days) is just giving “1-2” days another name. From that follows “resource-days”, then Gantt Schemes and the suffering...

Recently I’ve been in many discussions about using agile in bigger enterprises that shows that one message of agile has been lost. It goes right to the basis of using agile (or lean for that matter, more on that later) in the first place.

I think I speak too little about this, or at least I feel the need to be much more open and transparent about it. This post is a first attempt to bring some clarity.

NOTE I know that this will come out like a rant. Sorry. It’s not. It’s just the state where I’ve seen it. If anything I think that I have not been candid, clear and transparent in how I communicated.

First time I heard about AWS Lambda my mind was blown to pieces. Quite simply AWS Lambda gives you the opportunity to run a piece of code without concerning yourself about the infrastructure - AWS will handle deployment, configuration, scaling and all of that stuff. You just push your code.

That “just” in the last sentence proves to be quite a lot of grunt-work, sadly. That is, until you meet ClaudiaJs; your Node flight attendant for AWS Lambda - ensuring a smooth flight to the clouds.

In this post I wanted to describe how I got started with Claudia and Lambdas. It will be loads of fun - let’s get on it!

I have a couple of times been recommended the book The five dysfunctions of a team and the last couple of weeks I finally got around to read it.

The book is really great and worth reading. In this post I wanted to talk about a very simple exercise that we used in our team the other day.