I’ve written a few posts on Claudia now and as often I jumped almost too early on the boat - it turns out that there’s significant improvements to both Claudia herself and the entire ecosystem around the main tool. The main tool Claudia: automates and simplifies deployment workflows and error prone tasks, so you can focus on important problems and not have to worry about AWS service workflows In this post I wanted to check out a new tool around Claudia that helps you to build bots for use in chats - specifically for this post in Slack. AWS Lambda is really cool but it leaves one of those: Oh wow… now what am I going to use this for? feeling. It’s just code that scale infinity without you having to worry about it. It’s a very open playing field. What we’re going to build To build something a little...

When I started to learn about lean I naturally heard a lot of Toyota stories - it’s pretty inevitable since the whole thinking comes from there. One thing that I learned about was translated as autonomation. I was pretty sure it was a mistranslation. But the other week when one of my team members said: What’s the big deal of many things going on? If I’m blocked on a few items I can equally well just start a few more. (Not his exact words but still those lines of reasoning) At that point I saw the time to implement some jidoka (as automation is called in Japanese) in our project What is this “jidoka”-thing really? Ok, there’s an excellent article about autonomation on Wikipedia so I’ll just summaries it here. The jidoka concept is at the heart of continuous improvements at the Toyota. When a machine detects a problem the...

Just a short post on a little thought experiment I’ve been testing out. I am right now in a big company trying to apply agile and lean practices for software development. We struggle because we meet the current organization that is not built to move in the way we want it to. [Please fill out the rest of the story from your own experience while I yaaawn] […] […] … and now everyone wonders why things take so long and we are not getting more through the system. [I’ve been through this many times] I started to ask a question to people I discussed this with: Imagine if the company, instead of creating a project in the organisation, would have create a new company to solve this problem. First and only employee the current project manager. One goal build the best product you can! Here’s your budget for a year....

I have a problem; I often have a hard time connecting our vision and overarching goals to the items that we are actually working on. I want to be able to pick up anything we do and understand why we are doing this now and how it will take us closer to our goal. I’ve blogged about this before and in my time in Indonesia I even thought I had a great way of uncovering what those high-flying goals really means, by simply asking this question: What can we measure to see progress to that goal? But it turns out, understandably once I think about it, that question is too hard. The gap between the vision and the work is quite simply too big. To me often the connection between vision and our work reminds me a lot of the business of the underpants gnomes in South Park: It’s like...

I’m writing this post in a small crappy hotel room that will be my home for a few days. It’s quite the change after being station at the nice, beach-side hotel where Lean Kanban North America 2016 was held. I was very honoured to take part in this event - first time for me at Lean Kanban Inc. conference (I think… ) and it was really something special. I wanted to jot down a few thoughts and comments. Thank you Since I was both a speaker and an attendee I got to experience the full features of the conference and I have to say that it was brilliantly organised. Thought out the two days + workshop day I didn’t see or experience a single glitch and hiccup. The Lean Kanban team really knows their stuff. I wonder what kind of methodology for organising things like this they use? Thank you...

A few weeks back a team mate, developer and agile dude extraordinare, said something profound: I’m used to people coming to me with problems they need solved. Not solutions. It was in a backlog grooming meeting and we were discussing if the item was ready for the development team to start to work on or not. It was. Well and ready. But the people writing the requirements felt that it was not worked through enough. At the time I just giggled a little about this but it got me thinking and herein lies the heart in how the work with a backlog changes when you start to “do agile” or work in shorter releases. I’m reading Jeff Pattons awesome book User Story Mapping and it’s full of learnings on close to every page. In one episode mr Patton retells the events when he questioned Why a certain item needed to...

I got a request by a nice man call Brandon Garlock to share some failure of mine. My contribution will be part of a: collection of stories about experienced and established developers (such as yourself) and the failures, setbacks and hurdles they overcame over the course of their careers. It will serve as an educational guide, motivation and reference for burgeoning programmers as they learn their craft. You can read more about the project at http://www.iamascrewup.com/ That sounds both fun, worthy and useful. And I’m very honored to be part of the story. Any experienced developer will tell you that the greatest learning came from overcoming, maybe not always doing, great hurdles. I asked Brandon if I could share my story on this blog, as that how I mostly write stuff, and he kindly agreed. At the time of this story was a young developer creating a support system for...

This post could be summaried as you summaries an argument among kids; and then he said, so I replied, and then she went, and I’m like SAY WAAAHHAT?! but also hmmmmm… and then I went back home and asked a few friends and then I went Aaaaaah! And then I learned something deeper of what I until that point only was a belief. The last week I was in a lively and good discussion, again, about user stories and value. I think user stories often is misused as just another tool to write requirements in. Also we discussed that flow is something that we really should strive for, but to what extent? Over value?! As often, for me at least, it took a few days to think this through. That and some excellent help from some friends and tweeps. I’ve been proposing, and we have celebrated great victories, by doing...

The last couple of weeks an old “friend” has made it’s appearance; fear. This time it is a special kind of fear that I’ve seen many times in organisations that started their agile journey: the fear of forgetting important things. In this post I wanted to rant 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 manifest itself by very long lists of work not done, or backlogs that just goes on and on. I’ve seen list 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 loose it Often when I ask about why we should keep it on 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. Ditching iterations When I started the project the teams where working in sprints of two weeks, and releasing to production after 3 sprints; making a release every 6 weeks. Naturally each release contained quite a lot of new functionality and the “stakes” of failing the release was also quite high. A lot...