I have created a course, a boot camp to teach people to become programmers in 12 weeks. It’s quite amazing and you should apply if you want to change career. Check out Salt - School of applied technology Obviously, that cannot be done. But we do it anyway. And we succeed - we get rave feedback from the places where our awesome students are working. There are a few ingredients to the successes; people being highly motivated (I can write books about that) and mob programming are two of them. But in this post, I wanted to write about something that I think stood out for me after observing 3 classes in a row now. And it’s something that you can do and get a lot out of too. Memory lane I think (hope) that everyone has a favorite teacher that they remember from their early school years. I do...

Been talking a lot about the consequences of prioritizing today at my client. And about psycological safety This excellent story that Staffan introduced me too, came to mind. (I’ll summarize it below - this is just an intro, to get you to read on) And I came to think about how the consequences of prioritizing one thing over others, often end up becoming blame for the team. When it really should be praise… The Story The Warren Buffet story goes something like this: Mr Buffet asks his pilot to list his top 25 career goals. He does and returns to Mr Buffet only to get another request: Now please circle the 5 items on that list. This is, of course, tricky but after some time he comes back. Mr Buffet now ask his pilot: What are you going to do with the other 20? and obviously he answers that this...

Reading books is awesome - because it changes how you see and think about the world. I’m an avid reader and a non-recovering learn-o-holic. I read a great book the other week - When Will It Be Done by Dan Vacanti and it changed how I saw the world a bit. I wrote a whole array of blog posts on process metrics and now Mr Vacanti threw some of it on its head. Not that much when you think about it, but enough for me to want to correct myself with this new knowledge. It all has to do with averages… What I got wrong In his book, Dan Vacanti is actually referring to another book called “The Flaw of Averages” by Sam L. Savage. I have not read that yet, but the gist of it is: average is a pretty misleading fact that doesn’t (properly) take into account outliers...

Before I start I want to give credit where credit is due: One of the things that I love most about being a consultant is all the amazing people I get to meet at my different client; brilliant, fun and experienced-oozing people that I don’t see or meet online or at conferences. They are out there. Scott Hanselman calls them Dark Matter Developers. This blog is sparked from one of them; Yngve! Thanks! At this client (where Yngve works as an infrastructure architect) we were struggling to measure software quality. The teams felt like they never got the time to take care of technical issues that have been lying around forever, that they were forced to tack on “yet another new feature” and that we had no good way to communicate this. We needed a quick way to measure and track this - such as our non-technical coworkers understood what...

Friend: So in short - they too need to scale their agile initative. Marcus: Oh - cool! Up or out? Scaling agile has to be the term that I’ve seen most discussions, posts, comments and conversations about the last couple of years. And Google seems to agree - it at is peak or going there right now. But very seldom I’ve heard an explanation to what kind of scaling that is meant: do you want to scale up or scale out? My guess is that many times people talking about scaling agile mean scaling UP but worse I think that most times we have not decided. That is not really wise because it’s two very different problems to solve. In this post, I wanted to reason a bit about those tradeoffs. Computers The distiction between scaling up and scaling out is something that I first picked up in computer science...

I have been involved in many organisational changes that turn the organisation sideways. From functional departments to cross-functional teams, from projects and completing activities to continuous delivery and focus on reaching effects. Just about always this creates some initial confusion around where decisions get made and how the old ways fit into the new. Quite often worry about chaos break out. For example; Who is in charge of the overarching architecture, now that each team is deciding everything by themselves? I realize that I’ve done a bad job describing how this is going to work. The other week I found myself describing this with a pretty simple model that I wanted to share. Disclaimer I’m pretty sure this is not news at all and I’m making a pale copy of something brilliant. But … it’s my copy and I’m standing by it. TL;DR If you are in a hurry this...

I just had a conversation with a client that I keep coming back to. It has to do with how we are using electronic systems that manager our work, for example JIRA and TFS. I needed something to refer back to and I hope that you can get something out of me writing this down. In this particular case the question was very straight-forward: I think we are overusing the tag ‘Need investigation’ My question back was simple: How is that tag going to change your behaviour? Because it should, right? We are putting this tag on the item for some reason. Needs investigation - we should investigate then, I hope. The tagging feature, that we use in many electronic tools, would be some kind of marker on a physical board. A magnet or turning the card sideways, or what have you. We do these things because we want to...

Although I often preach about embracing uncertainty and sometimes get comments about always being calm… despite that; I worry. As do we all. But sometimes, in rare moments of clarity, I have the opportunity to stop and reflect over the what I am worried about. It just about always brings me to the realization that I worry in vain. Let me share three things in particular, that I have worried about lately. That gave me nothing but more worry. HOW problems are solved One of the things that I come back to very often nowadays is that we need to let the people closest to the information decided HOW to solve a problem, or handle an opportunity. They know better, best even, HOW to act and also can change their ways faster if they are given new information. This is why we focus on the OUTCOMEs a team produce, rather...

UPDATE I have learned new stuff. There are a better ways. Find the update here It’s time to wrap this series up. I have one final thing that I want to visualize: queue length. How much stuff is waiting and how long will that take us to complete? And maybe even, “if I add something in the queue now, how long before it’s done?” Lead time Lead time with filters Throughput Where time is spent Single numbers - averages, median and max of lead time As always my sheet is found here and you can make a copy of it and use it. Please let me know how it’s working out for you and if you end up doing something cooler than me. Let’s do it - queue length! Why queue length? I picked up queue length as a metric from the awesome book Principles of Product Development Flow by...

I stumbled over a new concept the other day. As it was conceived by Kent Beck, that inspired and thought me a lot in the past, I got interesting. [UPDATED] I read Kents blog post a bit too fast and missed that this idea was actually proposed by Oddmund Strømmer. Very sorry that I missed that in my writeup, Oddmund. Thanks for correcting me, Raquel. And after some even more research the origins seems to be traced back to a group of people that took a workshop with Kent Beck. Not only Oddmund Strømme but also Lars Barlindhaug and Ole Tjensvoll Johannessen. Those Norwegians… always a few steps ahead of me. [BACK TO THE OLD TEXT] When I read his blog post I got to this quote: I hated the idea so I had to try it. I felt the same actually and now I’ve tried it. I was so...