Henrik Kniberg on Lean From The Trenches, Translating the Agile Manifesto and Living Agile

Recorded at:

Bio Henrik Kniberg is a coach and consultant at Crisp. His background is a mix of development and management and his passion is applying Lean and Agile principles to help debug, optimize, and refactor companies. Henrik is the author of "Scrum and XP from the Trenches", "Kanban and Scrum: Making the Most of Both" and "Lean from the Trenches" and is a popular keynote speaker at conferences worldwide.

Sponsored Content

The Agile Alliance organizes the Agile series conference, which bring together all the key people in the Agile space to talk about techniques and technologies, attitudes and policies, research and experience, and the management and development sides of agile software development.

It’s a geeky way to phrase it but yes, debug and optimize and refactor, right; debug is in terms of helping companies solve problems, and optimize in the sense of help companies do whatever they do better or faster or; and what was the last one?

Craig: Refactor and optimize.

Refactor yes; sometimes they want to keep doing what they’re doing but on a slightly different way so reorganizations and things like that.

Craig: So what would you do if someone asked you what your job title is, how do you describe that to your parents?

It is a kind of a weird thing; I was not planning to write a book; I was CTO at a game company in Stockholm and we learned a lot and I had a habit of taking pictures; so and at one point I was sick at home; I had a fever, I was lying in bed and I was for some reason thinking about that engagement and everything I learned and I was like I better write some of this down or I might forget it; so I got on my computer and I started typing a little bit and then I just went mad; just kept typing, I couldn’t stop, maybe because I had a fever or something went nuts.

Anyway so I just kept typing pretty much without stop for like three days; I just fell asleep sometimes I kept typing; and that was pretty much the whole book except for like two chapters; and then I didn’t know what to do with it; I was like this is not a blog entry; it’s too long and this is; I don’t know what to do with it and somehow it ended up at InfoQ as a mini book.

Yes; a lot of people told me that and I realized that that’s the kind of book I would have wanted when I was learning Scrum because okay I read the theories, I kind of get it but give me concrete examples please.

Yes; that’s why it was easy to write; it was just spill it out, it’s in my head, it’s in my photographs; it’s you know.

Craig: Yes, exactly and that was pretty popular right?

Yes, I was amazed; it was just an article I wrote; I didn’t know what to do with it; I put it on a mailing list and people raved about it so that’s when it turned into a book and then people started calling and say “could you come and help us, we’re doing Scrum” and so that’s how I got launched unplanned into the land of coaching.

Yes, I’m at Crisp; I was at Crisp then too; I was CTO; that was actually my consulting engagement; but yes, Crisp is a 30% consulting house in Stockholm; although it’s really kind of a – it’s like an umbrella organization because everybody is independent underneath so it’s more like a, we call it a run time environment for consultancies.

We’ve got about two thirds of us do mostly coding but kind of an Agile mindset and we work with pretty much every kind of company, any company that has fun and interesting software related projects then we have people there.

[Craig's full question: I guess a couple of years after you wrote the “Scrum and XP from the Trenches”, the software industry was moving on and then came along the next one which was “Kanban and Scrum: Making the Most of Both”, which we’re just talking off camera and I said to you that it’s a book that I really love because (a) it’s free and (b) it’s very easy to read; so how did that one come about?]

That’s actually quite funny; the first book was called “Scrum and XP” and one of the reasons that was not a coincidence; I know the Scrum and XP camps were kind of, there was a bit of rivalry there and I felt that that’s silly; these techniques work well together so I wanted to kind of bridge that gap; and then later on Scrum and XP became friends and then came this new kid on the block called Kanban and then they were kind of rivalry so; and it was the same thing there; I was noticing that Kanban and Scrum they really work well together, so I wanted to write a book about that.

It was launched because I just noticed that the techniques work well and I noticed that there was some confusion and also some tribal, you know, rivalry between the camps and I felt that was unnecessary; so I wanted to just write a book showing that these are both valid useful techniques; they can be combined; they can be used separately and I just wanted to make things more clear.

[Craig's full question: One of the things I really like about that book is that it is pictures so anybody can kind of read it and it’s really good for people who’ve been doing Scrum to make that leap to Kanban; so was there any reason you went with that style of book? ]

It’s why I use visual; people are different; I’m a very visual thinker; like I can hardly have a discussion with someone without having a whiteboard to draw on so that’s one reason; also to save time because as I’m trying to understand something I’m doodling and then why not just put in the doodle and then I don’t need so much text.

I also noticed that when I do coaching or when I do training, people ask you questions and I’m drawing on the whiteboard while trying to explain and sometimes I notice that this particular way of drawing it made it click; people are ah, I get it; so those particular drawings I try to save those, remember which one it was and those end up inside the books; it saves me a lot of writing and it saves you a lot of reading.

So the background to “Lean from the Trenches” was I was at; it was yet another one of those really interesting projects; of course not all projects are very interesting but the ones that are interesting are the ones I write about; and there we really did a hybrid of putting these techniques together and it was also the first time that I had a chance to really experiment with scaling; so we had 60 people on the project and for various reasons I was given pretty much free rein there in terms of how we’re going to work; and we found some; we applied a lot of useful techniques and I felt that I want to share this so that’s when I…

It was pretty much the same story; I was on a flight to Portland and had nothing to do; I was sitting on a plane and I just started typing away and looking at my photos and I typed the whole flight to Portland and the whole flight back again and that was pretty much most of the book; very similar story.

Yes, the reason I called it “Lean from the Trenches” was because we had a big project and it was quite chaotic and a bunch; my feeling was that if we can get lean principles; there were some lean principles we needed to have there like the fast flow of things; instead of building everything at once slowly, a few things quickly; and the value stream thinking so we want all the way from concept to production, we want features flowing as quickly as possible along that pipeline; and also the idea that improvement is everybody’s business and not just the Scrum master or the manager or; so I wanted to get these principles in place and it turned out that the combination of Agile methods, Kanban, XP, and Scrum were a great way to implement Lean principles.

And it’s also one of my kind of sneaky bridging the gap things; Agile and Lean are cousins to me and I really see those principles as complementary so I wanted to show how Agile methods help you become Lean in combination with some Lean techniques.

Well for example at this project we had 60 people and the first thing we noticed was that test was a bottleneck; all of this code was being written and it was stacked up in front of test and the testers were working very, very hard but nothing was getting actually done; so we measured velocity in terms of how much stuff is ready for production and velocity was zero every week right, but everybody was working very hard; so by making that visual on a board which shows end to end; like every team had their own board but we had one single shared Kanban board for the whole project and everybody could see; “darn everything is stacking up”; and once that realization came in place then it was easier to talk about cross functional teams and WIP limits (work in progress limits) from Kanban and all these kind of discussions became possible once everybody could see the problem. And that’s a very typical Lean visualization technique.

Yes; so we had three cross functional teams and they had their own Scrum boards; we added another board which was kind of an overall project board where what flows in on the left is epics and flowing out the other side is features going into production; we wanted to show the whole flow and get everybody engaged in the whole flow rather than just their team and that caused much better collaboration between different parts that were previously silos.

So this was actually not a portfolio board, although I like that concept; this was one project so it was a project board in effect; and this was updated every day; it was real time; in fact it was updated more often than every day.

Each part of the board had people that were focused on that area so in the middle of the board we had three swim lanes, one for each feature team; so one person from that feature team would come over and keep their part of that board up to date; we had people focusing on tests like system test and would keep that up to date; so it’s quite dynamic; but we also had daily meetings in front of this board; so there are no strict rules about who updates what but it was quite clear if something needed to be updated just somebody will update it.

Yes, we had three layers actually; first all the feature teams meet and do their daily Scrum and then all the specialty teams meet so kind of all of the communities of interest; all the testers meet here, all developers here, all the analysts here; and then at the third level we’d have like a project team; one person from each specialty, one person from each feature team about ten people in total plus me and the Project Manager and we would look at the high level picture; so three layers of daily meetings every day. Seems like a lot of meetings but they really liked it so, yes.

This was working and they were just 15-minute meetings and things were happening; they’re updating the cards or solving problems. So these conversations replaced a lot of process that we otherwise would have had to have.

Yes, build quality in. In concrete terms by having a clear definition of ready which means that we have to know already ahead of time what is the test that we need to pass; and before handing off anything to system test, it needs to be properly tested at feature level; we need test automation; we put in all these kind of routines in place to make bugs found earlier; another thing we put in place was when a bug is found, fix it now; if it’s a critical bug fix it now; don’t put it in the bug tracker or anything like that; just put up a pink sticky, find a developer, fix it now; so that was a pretty big cultural shift actually; but the idea is don’t save the bug until the end fix it now instead of just building big bug databases.

[Craig's full question: One of the other things that you’ve been quite instrumental in is the Agile Manifesto translation. So obviously; Agile Manifesto written in 2001; kind of the reason why we’re all sitting here in Dallas and why we all have jobs; but translating that to other languages must have been a huge effort. ]

I had to learn; we have 42 languages up now and after about 30 languages I found it hard to learn new ones; that was hard.

Yes, actually I was just kidding, I didn’t learn 30 languages but the background was this; I was on the Agile Alliance board and we talked about internationalization as our kind of our focus; and I figured that we have this great document this manifesto; it’s a historical document but it’s still kind of valid and many people around the world are struggling with how do I actually translate the terms; and there is a certain importance in using at least within one community agreeing on what’s the terminology and also we wanted to make it easier to export the Agile values to different cultures.

So yes, we figured that let’s get this thing translated and I set up; I translated the Swedish myself just to experiment with what’s the process for that, how can we involve the community in that; and then we did Japanese together with a guy called Kenji Hiranabe; and then after that we had a process in place for how to find good translators in each community and how to do it as a community effort and that was pretty much it; so then; now it’s like running, yes we have 42 languages it’s really cool.

And a really interesting surprise also was that it’s not really about the document, it’s about what happens when a community gathers together to discuss well what do we mean by customer involvement, what does that mean for us; and they have these discussions and these arguments and it seems to kind of revitalize communities around the world.

I mean we have these 17, I think it was 17 strong willed Agile manifesto authors and they have found the phrasing and they really nailed it; in fact ten years later the same 17 strong willed people agree that we nailed it and that’s pretty unique; so I didn’t really realize how much they nailed it until we tried to translate it and it’s like okay, getting that right feel of it; it was really hard and sometimes we have to make compromises, yes.

[Craig's full question: You mentioned as you said that the Manifesto is a historical document and it stands up mostly; having spent so much time trying to reword it into Swedish and working with the other languages if you had your way, is there anything in there that you think you would change if that was possible?]

I might change to focus to product rather than just software, that will probably be the only thing, so working product instead of working software etc.

Yes; the principles have proved to be useful beyond just software and at that time our problem is we couldn’t deliver software in a good way and now many companies can do that; they know how to deliver software and a lot of question is what software do we deliver to get a good product; so the question is kind of it’s a higher level question and it turns out that the Agile Manifesto principles are still perfectly valid, but sometimes we alienate people who are not in software because you’re like, oh it says software; but if you just replace the word software with product, it turns out that it actually works great in hardware and other areas too.

[Craig's full question: So you’re looking nice and fresh at the moment; your fans have been following your movements; you’ve been just back from a six-month tour around the world with your family. What inspired that? I guess somebody suddenly looks to you and goes "Wow, how could you ever take six months off?" but you’ve done it; so kind of what inspired that and what was in the highlights? ]

It was a combination of things, but it pretty much started with me and my wife talking about like if we could do anything what would we do; just it’s a good conversation to have sometimes then we were like, oh, it would be interesting to travel someday you know take the whole family and go somewhere for a longer trip just for a change; and then we’re like yes that would be interesting, but we can’t because of blah, blah, blah; but then we’re like but if we were to do it someday when would we do it just hypothetically and that’s when the “oh shit” moment hit us because we realized it’s not going to get easier to wait because we have four kids aged at that time 1, 3, and then 6 and 8; and the longer we wait the more kids are in school and the harder it is to get away; so we decided that if we ever do it we have to do it now or wait like what 16 years until they’re all out of school.

Pretty much; it’s like either we do it now or we just decide not to do it so that was the background; plus I realized that right now I have a good international network so I can actually do it as a little bit of a lifestyle experiment just doing a little bit of work in the different countries we travelled to.

Craig: So did you make it right around the world?

Yes, we did; we did Japan, China, Thailand, New Zealand, Peru, Brazil, and West Indies and then home.

[Craig's full question: As an Australian I’m sorry that you missed our fine country. Any highlights along the way? I mean obviously because you’re in this community you do meet up with people that you know so is there any sort of inspiring things? ]

New Zealand was quite fun because I started in the north; I spent Christmas with Gabrielle Benefield and her family which we know and talked a lot about Agile stuff and then kids played with each other and it was nice mix kind of work and fun; and then I drove down to Wellington, I met some Agile folks there and then down to the south island and Mary and Tom Poppendieck were traveling there so we hung out with them; we parked our camper van outside of their cabin and hung out and it was just fun going around and hanging out with different people around the world.

[Craig's full question: One of the things that you talked about your kids before and I read your article in Yves Hanoulle’s “Who Is…” book which is a good read for those who haven’t read it, but one of things that I was interested in there is that you’re actually quite a musician from what I read; how does that articulate into what you do in the Agile world?]

That’s my hobby, yes. I guess there are some commonalities in the sense that I love improvising as a musician and I love improvising at work too so it helps coming in not having a plan but having a goal; there’s some of that; but it’s also some of the maybe teamwork aspects; I really like the dynamic you have when you’re on stage jamming with other artists and kind of how you have your part, but there’s also the whole and if you optimize your part too much then you’ll ruin the whole.

Continuous delivery; I have a band and we play at weddings and every wedding, we’ve probably played almost a hundred weddings and every wedding is a fixed scope, fixed time project; the music has to be there or the wedding wouldn’t even start; so when they’re going to dance; you can’t fail that; and I realized what has helped us do that well is actually the Agile principle is quite similar; the idea of the cross functional team, shared responsibility, standups, retrospectives; of course we don’t do that strictly; we don’t follow any method but I realized that in practice those ideas are universal; even in a band they’re helpful.

Well four kids, four small kids aged 2 to 8 in our case it’s by definition a self-organizing team; if we don’t respond well they come out of control; and it turns out that the stuff that helps them be happy and work is similar to what is in an adult cross functional team; there’s not as much difference between adults and kids as you might think in terms of what drives us; so I just noticed that, that there’s a lot of similarities.

That’s a really good question how does it make me a better coach; I guess because I get a chance to experiment; I get new ideas from my kids that I could apply at work and I get ideas from work that I could apply at home; so things like you can do a sprint planning meeting with cards on the wall and have people collaborate around priorities and things like that and then I come home and the kids are going to do a birthday party and they can organize their own birthday parties in the exact same technique and they’re having fun doing it; so yes it’s very fun.

About five years ago, I was just playing around with the idea of it would be nice to have a collaborative workspace on the web that’s instant without having to log in or anything so I did a prototype; I just worked one day and then I didn’t have time anymore so I just left it a prototype; one year later I did the same thing I spent one day, the next year I spent one day so one day per year for about five years building a really dinky little prototype; and now this summer I had some time and I was like what the heck, nobody has built this yet and five years have passed, what the heck; and I kind of missed coding so why don’t I just build this; and then I had just read “The Lean Startup” and I wanted to apply these techniques so three reasons to just dig in and code.

So I took the early prototype and made a so called minimum viable product in Lean speak and put it up; so webwhiteboard.com; the typical scenario usage scenario is I’m on the phone with somebody or I’m in a Skype call with somebody and we want to take notes together or we want to draw doodles or do our sticky note thing and we want to do that right now so let’s go to webwhiteboard.com, click once, now I have a whiteboard we can share; so I want to remove all the barriers to entry.

There’s lots of tools that do similar things but they tend to have a longer setup time or they tend to be very good at just authoring or just drawing but not the other; so I want something that is really fast setup and has a little bit of drawing, a little bit of sticky notes, and a little bit of writing.

Yes; I have a bunch of hooks, features that I don’t know if I’m going to build or not; and when someone clicks on that feature like undo, they get a survey pops up, how important is this for you, would you pay for it in the future; who knows; and that information helps me show what features are people trying to use, what are they actually missing; so that’s one.

I also have some kind of key things I’m measuring like how many active whiteboards do we have and in the future I’m going to do an A/B testing little thing so I can put out a feature and say does that influence if people are using it more or not; and I’m doing it mostly for fun but in the future I might do a freemium thing so certain features I will charge for and then mostly it will be free.

Yes, one is the pain of delivering something that’s not finished at all and knowing it kind of sucks but not knowing how it sucks and what I need to fix next; so sure this product works, people are using it, it’s fine but it’s way not at all where I want it to be in the long run; putting it up anyway it’s kind of like a good kind of pain; so I’m getting feedback people saying we really need undo; I know they needed undo but I didn’t maybe know that that’s what they need first so now I’m building undo. Things like that.

Actually right now I’ve been working with some very interesting companies lately; I’ve been working with Skype and right now working with a company called Spotify; it’s a really cool company, cool product and one of the few companies I’ve seen that was actually really born Agile; and I decided to be more intentional about which companies I help so I’m focusing on that one company; and incidentally they are interested in applying Lean Startup techniques.

We have 30 teams, we want each team to actually work like a startup so it fits very well with what I’m interested in anyway. Plus I’m moving in more towards coaching teams of coaches; so they already have a great team of coaches and my job is to help them grow and get focused and really perform as a team.

[Craig's full question: So what exactly does that mean; I mean I assume coaches and being a coach myself you obviously are already kind of the so-called experts in the organization about that and are the experts in their organization; so how do you approach trying to train a bunch of people that already think that know these concepts? ]

Well it’s just a different focus because at a company in this case each coach has their teams they are coaching but then we also have higher level issues we want to deal with; so we want to collaborate as a coach team to solve higher level issues that are not related to specific areas of the company; so it’s really about can we use Agile principles on ourselves; can we the coach team act as an Agile team; using Kanban, WIP limits and boards, task boards and definitions of done; so pretty much applying our own principles on our self, but that’s sometimes hard to do; it’s useful sometimes to have someone external to hold up the mirror; so I guess yes even coaches need coaching.

It’s really just practice what you preach; like use the techniques, do retrospectives right; and if it’s hard to look at yourself bring in an external; maybe just borrow someone from a neighboring team can you please facilitate us because we want to do a retrospective; and things like visualization, doing things like standups; it’s in a way quite easy because all the techniques we use to help our team succeed, we can use to help ourselves succeed, but sometimes we forget that; we’re so focused on helping them over there we don’t notice that maybe I should do this myself too.

Yes, I’ve been talking to a lot of people about the how do you coach groups of coaches thing for obvious reasons because I noticed other people are experimenting with the same thing, that’s part of it; I’ve rediscovered the pleasure of pair programming because I’m sitting in a couch coding on web whiteboard and somebody drops by and helps me; first I was like, oh it’s a pretty big threshold to get into this code but no it wasn’t, ten minutes later we’re coding happily so; there’s nothing specific that stands out; it’s just really nice to be in this environment and talking to people and trading experiences, things like that.

I think maybe focusing less on the specific schools in Agile whether it’s Scrum or Kanban or whatever and keep going, keep the current evolution going and the current evolution seems to be that combining different techniques; and I think also this has been mentioned in early conferences but I really still think so that the term Agile is kind of fading away and that’s not necessarily bad; it’s just that we’re not really focusing on Agile, we’re focusing on how do we develop products well.

I think we need an Agile, we need a brand to hold on to to launch us into the next step and now we’re kind of there so we’ve realized that it’s not just software anymore it’s product and it’s not just Agile, it’s just how do we work together effectively. And Agile provides a bunch of techniques for that and so does Lean and so does Getting Things Done and so does other things.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.