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.

Value streams

We talked a lot about flow and that often our current organizational setup makes flow harder, but the penny dropped around this problem statement when we came to speak about value streams.

I have to say that it’s...

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.

The course

Your first time learning something has much to do with the teacher. I was in the expert hands of Carl Vikman that both were very knowledgeable, had a pleasant way and most importantly understood the main reason for...

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.

The award

Who is Brickell, and where is her keys?

Brickell Key is in fact an funky looking island, located outside Miami.

It was the location for the first Lean Kanban Conference in 2009.

What is the Brickell Key Award?

The Brickell Key Award is an award for extraordinary efforts and achievements within...

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

Our example… again

I’m going to use something very similar to the last post for our example. Here’s the short version:

• mkdir hellotesting && cd hellotesting
• npm init and then some enter-strokes
• npm install claudia --save-dev
• Add a node for files in package.json like this files : ["*.js"]
• Add the following two scripts-nodes:
  • "create": "claudia create --name hello-world-demo --region us-west-1 --handler main.handler"
  • "deploy": "claudia update"

Finally touch main.js and enter the code below

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.

A simple example

As our example let’s use one of the example projects that Claudia has provided for us to learn from. In fact - let’s use the simplest possible: Hello-World.

Create a new directory (called hello-world for example) and in it do a npm init and click through the wizard.

There’s only one development dependency for this simple application, Claudia itself. Install it...

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…

We are chasing a performance problem on our site, specifically on one of our more frequently used pages. Needless to say this have had high priority for quite sometime.

A team was formed, a plan was created and a backlog of items that we thought would solve the problem was initiated. The first feature, our best bet, was further analyzed, setup and development initiated. The whole journey took about 1,5 months to get ready and another 2-3 weeks to develop.

Finally, last Monday, we could do the first proper tests where we could measure against the current solution....

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.

Glimpses of misuse

As I have done for a few posts; let me give...

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

You might want to read up on the basics (creating accounts, what is Claudia etc) in my earlier post. I’ll write every step down here but I will not explain it as thorough as last post.

Dynamo Db?

Amazon DynamoDB is a fully managed non-relational database service that provides fast and predictable performance with seamless scalability.

Ok - it’s a document store just like many others, the only difference is that it’s in AWS which means that it...

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 here:

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...