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;
Read on ...
Is this really important? For who?
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.Read on ...
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.Read on ...
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!Read on ...
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.Read on ...
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.Read on ...
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 of course not stupid - he’s very knowledgable and experienced. And so was everyone else in the room.
But why does things that sounds very good, is common sense and that I buy all of it - comes out like something totally different and unnatural in many organisations.Read on ...
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:
Read on ...
Lead like all the people in your team/org/companies are volunteers
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.Read on ...
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.
In this post I will re-implement pingu using a delayed response as in that tutorial.Read on ...
Since the first time I heard the term mob programming it has intrigued me. I love things that challenges me and me perceptions.
The idea behind mob programming is deceptively simple and yet powerful: have all the team member (3-5 seems most common) working together on one keyboard, one computer and one feature at the time. Or as Woody more eloquently puts it:
All the brilliant people in the same room working at the same problem at the same time
What struck me is that this simple idea solves many problems that I often see teams struggle with.
I’ve written before but never been full time member in a mob. However just before the summer I saw two excellent examples in action, and I have number of friends that have been full time members of a mob for more than a year. My interest with this has led me to interview them often and deeply.
In this post I wanted to share some things that I’ve seen. Mind you this is only from the 5-6 mobs that I’ve been in contact with thoroughly. Other examples and variants are probably found. This is just my observation.Read on ...
About six months ago I got home from the adventure of our life time in Indonesia. At the time I was actually feeling very underwhelmed and that we’ve failed in our work there.
But the more I think about it and the more I speak and write about our experiences there, and especially the mind blowing transformation we led in Rumah Sakit Bungsu - the more I realize that this is an once in a life time thing that have happened.
This post is just an update about the progress of the work around the “Salvation Army hospital that rose again” that I’m calling it.Read on ...
A couple of weeks ago I tweeted:
In this post I will explain what I meant. And also give a suggestion on how to do something better. I know it’s better - I’ve tested it many times. Just this last hour to be exact :)Read on ...
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.
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 projectRead on ...
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]Read on ...
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:
Vision: “we’re gonna rock the world”,
sticky on my board: “Make the button blue”.
I don’t like it. There’s no connection. Or worse we try to make up the vision/goal, the why, from the work that we do. But I have an idea. We are trying it now at my current client. I wanted to share it with you.Read on ...
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.Read on ...
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.Read on ...
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.Read on ...