From time to time we might end up with policies and ways of working that just seems like it’s “the way we do things here”. It can be tooling, procedures and even contractual policies but also many of the practices that we take for granted in agile and lean software development; stand ups, boards or user stories. I’ve found that thinking outside of the context that we have created for ourselves is often very hard, and I am the first one to default to things that worked for me before. In this post I wanted to introduce you to two questions and thoughts that helped me pushed me out of my comfort zone and let me ponder; Is this really important? For who? Customers A couple of months ago I had an opportunity to speak at the inaugural Agile Islands. Among the other speakers was Leif Östling, long time CEO...

I’ve just completed my first ever big room planning meeting (a type of exercise made famous by SAFe in their PI Planning). That was quite an excerises and I’m totally worn out. But also immensely impressed by the team and the amount of learning that took place in the room today. It was quite noisy at times but after 8 hours we went home with our sights aligned and a much better feel for what we will do the upcoming period (5 weeks in our case). Still I could not get one thought out of my head. It stuck there a few days back and won’t get unjammed: This big room planning stuff is really an anti-pattern and should be eliminated In this post I want to explain why and also tell you why I still think it was great. Investments In order to prepare for the meeting we have...

I’m a big fan of David Marquet and his Turn the Ship around book that shows on excellent form of leadership but also challenge the way organisations are viewed and managed. My favourite quote is a simple one: Move the authority to the information I like it so much that I’ve already 2 years ago wrote a blog post about that idea, outlining why this is a good thing and how we can save a lot of effort and time in moving the information back and forth. The other week I realised that there’s other, more subtle and viscous wastes in continuing to move the information to the authority (as we do now). In this post I will describe what that is and how to avoid it. I’ve often been working in quite big organisations and something that often happens there is that you need help from higher levels above...

This is another post in the impromptu series “Marcus explains his tweets in more detail”. In this post I wanted to talk a little realisation that I’ve grown into the last couple of years There are no best practices is knowledge work.Only good practices and context when they apply. Learn principles-adjust and develop practices— Marcus Hammarberg (@marcusoftnet) September 23, 2016 It might sound obvious at first (or not) - but I see many signs of that we, especially in the agile community, do the opposite. Let’s see if I can explain my thinking or if I make a fool out of myself - that alone might be worth reading this. Lets go! Principles over practices I often get thrown into meeting about “help us to become agile” or “teach us how to do scrum” or “should we do scrum or kanban?” Before I started in that end and often ended...

I’ve from time to time said things like: No heroes - is a great starting point to make process improvements— Marcus Hammarberg (@marcusoftnet) September 20, 2016 but at the same time I think that it’s a good thing to: Stand back and let people be awesome In this post I wanted to try to sort these two separate statements out and see where the common ground for them are. No heroics What I meant with the first statement (tweet above) is a reaction to a phenomena that I have observed in many, primarily large organisations; the only way to get things done is through efforts above and beyond what is normal. For example; someone needs to pull a lot of strings and flex their personal network to get a computer installed with the correct administrative rights. Or instead of putting a ticket in the ticket system someone calls someone else...

I’m re-reading the Toyota Kata book right now I had forgotten how much it influenced my thinking. If you haven’t read it - go and do that now. Don’t read this post - read the book. I won’t mind. Toyota Kata is what the author, Mike Rother, calls the mindset and practices that Toyota employs to get continuous improvement to work. Note that Toyota themselves might not recognise the term Toyota Kata, because it’s just how they do. The book is filled with wonderful stories that shows clearly about how the Toyota mindset influence every aspect about the continuous improvement work there. In this post I wanted to relate one such story that I meet so often in my daily work and reason a little bit why Toyota (and other lean organisations of course) navigates out of those problems with ease. Whereas I get stuck again and again. The story...

The other week I attended a course that introduced a lean and agile mindset to a group of leaders in a company. My role was to sit back and observe (and to shoot in some of my experience during the training) - here’s one thing I observed. At one point in time, after we’ve been through the agile manifesto and the principles, and finally the principles of Lean Software development a high ranking manager next to me raised his voice and said: This all sounds very good. I buy all of it. Its common sense. But the one thing that I don’t get is why we realise this now. We are doing something very different than this now - have we been stupid before? The discussion that followed was very fruitful and the people in the room learned a lot. But I wanted to go beyond the question. Because he’s...

Have you ever said something profound and deep? No - me neither… or rather not on purpose. Sometimes though, when I look back I both realise that some things I said was actually pretty good - and also that I didn’t really understand it when I said it. I wanted to share such a moment with you and then explain why I think it was actually pretty good. In this post I suggest that you should: Lead like all the people in your team/org/companies are volunteers The one time… A few months back the Salvation Army in Sweden changed the territorial leader - in Salvation Army speak the Commissioner of Sweden. I happen to know both the going and coming (a couple) commissioners pretty well and really appreciate them as leaders. However the going commissioner, Marie Willermark, was of particular help to me and my family when we lived in...

I’ve just downloaded and started to read the Imposters Handbook., by Rob Conery. It’s a book about all those things that you don’t want to reveal that you don’t know. I most of them I should know since I have read Computer Science. But I don’t. It’s a great (in all senses of the word ≈500 pages!) read and promise to deliver even better things ahead. Go get yours now! As I started to read it I heard a familiar voice in my head. Rob Conerys. And I just realised how much I’ve learned from him. Dear Rob, I first heard your name when you created a course on ASP.NET MVC for the ASP.NET-site. That technology was brand new back then. I then followed you as TekPub was started and I have seen just about everything you ever produced. I’ve also enjoyed some of the courses produced for PluralSight once...

Before the summer I showed you how to build a Slack bot using Claudia - it’s a very simple ping command that you could run from a Slack-client. However that implementation had a flaw; if the command takes more than 3 seconds to complete it fails. This has to do with a restriction in Slack that doesn’t allow requests to take more than 3 seconds. In my mind created a super complex and beautiful solution including me handing a message of to a queue and that I then polled and called back to… I ran out of time figuring out. Which turned out to be a great thing, since the Claudia team not only created a new beautiful site https://claudiajs.com/ but also wrote a tutorial on this exact topic In this post I will re-implement pingu using a delayed response as in that tutorial. Getting started The easiest way to...