Summary
Henrik Kniberg discusses the differences among different Agile processes such as Scrum, XP, and Kanban. He shares the thought that processes wars are meaningless and we need to see each process as a tool; there are no bad tools; just tools used for the wrong purpose.
Bio
Henrik Kniberg is a consultant in Stockholm specializing in Java and Agile software development; he has founded several Swedish software companies and is passionate about learning, teaching, and applying the art of software development. Henrik takes a holistic approach and enjoys adopting different roles such as manager, developer, scrum master, teacher, and coach.
About the conference
gile 2009 is an exciting international industry conference that presents the latest techniques, technologies, attitudes and first-hand experience, from both a management and development perspective, for successful Agile software development.
This is Amr Elssamadisy at Agile 2009, with Henrik Kniberg. Welcome Henrik! Thank you for joining us. Can you start by telling us a little bit about yourself please.
Sure! My name is Henrik, I'm based in Stockholm and I work as an Agile coach, so I kind of balance my time between training and helping companies get started, practice. I've spent half of my life in Tokyo, grew up there and I play music on my free time. That's me in a nutshell.
Excellent! Thank you! So what are you passionate about these days? What' your focus? What are you working on?
My focus is trying to get companies to be able to apply all these great ideas in practice so often it is a big jump from understanding the theory and then actually sitting there and getting it to work. I'm also passionate about kind of getting away from this kind of meaningless discussions about "this process is better than that process, etc." I'm trying to keep it at a high level and just look at all these as tools.
How do you see the current environment and what you'd like to get away from? What's happening currently with the different processes?
For example let's say we have a company that's been doing kind of waterfall style development and then they decide to implement for example Scrum; they do that for a while and then maybe they forget some of the engineering practices which is not uncommon because there aren't any in Scrum. So they realize after a while that "oh... wait a sec! We need this stuff!" So they start maybe doing parts of XP. Of course that doesn't mean tool A or tool B was bad or good, it just means that now we solved one problem, which was the communication and next issue was perhaps technical stuff and maybe a few months later they're doing Kanban because they have other problems: maybe one part of the organization didn't like iterations, so they are mixing and matching, I think that's great! But if we have someone inside the building that says: "Wait a second! You should be doing this method! Not that one!" Then that's destructive. So , that's why I try to stay away.
What I hear you saying is, it's typical, so when people say: "Scrum it doesn't do technical practices!" I believe there is an initiative these days to create a certification for a Scrum developer. That's fine, but Scrum wasn't meant for technical practices, doing exactly what it was and maybe you used it for solving your particular problem.
Well, in fact the technical practices were there from the beginning but then as far as I understood from talking to Jeff Sutherland they decided intentionally to live them out. Not because they weren't important, but because they wanted Scrum to become focused on one specific area and then leave the technical practices really important but not included in specifically Scrum. So I look at it kind of like if Scrum is a hammer, that's great but that doesn't mean you don't need a saw. And you don't really want necessarily to turn the hammer into a saw, because you also need a saw. So they are distinct and different but both really important.
What I hear you saying are: each tool for each problem. Scrum is different from XP, is different than Kanban , is different then whatever else is coming next?
Well, not necessarily either. There is a pretty fat overlap too, like XP includes most of Scrum for example, so I think the best metaphor is kind of like knife and fork. Which one is best? It depends right? Sometimes you want to use the fork, sometimes you want to use the knife and sometimes if you eat a big stake you need them both. There are some functions that they can perform equally well, for example, if you going to throw at somebody to hurt them, than the fork and knife will probably work just as well. So I don't see them as distinct in any way but they just focus a little bit differently.
What advice would you have for the community and for teams embarking or trying to choose between these things?
I think one piece of advice constantly have to give myself and of course other people as well but sometimes I forget to give it to myself as well, is: "Don't start solving something until you understand it!" We had a session at this conference about A3 problem solving techniques from Lean and whether not you call it "A3"and use a lot of buzz words, the thinking is really good. So try to understand what problem they are actually solving, how do we know it's a problem and how would we know when we'd solved it, before we start talking about what specific tool should we use to solve it.
So, focus on the problem first, understand it and then pick the appropriate tool.
So as a coach, you go to the client, and maybe they say: "We want you to come here and help us do TDD". That' s fine! You know, you walk into the door which says "TDD", but then forget that and ask them "What's your problem?" "What's actual problem into you people?" and often is something completely different than whatever they ask you come and do.
Because if they are new, they ‘re not aware of the subtleties in the context.
Yes! They found the buzz word and that's maybe a good start, but that's just a start.
Can you give us some specific advice Henrik?
Sure I can give some specific advice on two levels, of course after " What problem are you trying to solve?", but in general if you're a company doing software development, send people out sometimes to conferences like this, maybe some different conferences, send them to courses, ask them to choose themselves, bring in external inspirational speakers, spread books around office and basically try to help them expand their toolkit as much as possible. So, that's one, general thing.
So the more you expand their toolkit, the better decisions they can make.
Yea! So maybe one of those guys will decide to go away to the conference and come back and say " Hey! there's this cool thing called Kanban". Now to get more specific I wrote the "Scrum and XP from the Trenches" book, and now I have this upcoming "Kanban vs. Scrum " on InfoQ.Com . It's not a coincidence that I've been putting two different methods in these titles, just to make it clear that these are fully distinct. The subtitle of the "Kanban vs. Scrum " book is "How to make the most of both". I think "compare tools is great", that's specific advice; compare tools to understand them, but don't compare them for judgment.
Compare them for understanding, compare them to know what they are good for and what there are not.
Yes. Sometimes is easier to understand what is A if you compare it with something that you know well; a typical example is Scrum and Kanban because Scrum is quite mainstream, at least around Sweden and here too maybe! We found out that a lot of our clients are doing Scrum but in one part of the organization typically maintenance or operations. This was better than we had before but iterations don't feel right for us. "So what do we do? We are not doing the Scrum properly. Does that mean we‘re bad people?" "No it doesn't! This is other stuff as well!" then we start talking about Kanban and how to mix and match.
So the more tools you have, the more tools you're aware of, the more problems you can solve. And conversely what I hear you saying is "There's no silver bullet." All of the methods are complementary. One method is not going to be strong in every single situation.
Exactly! And more importantly never blame the tool or the method. It's a tool!
It's your choice to use it or not!
Yes! So is no such thing as a bad tool! It's just....
A bad tool user?
Yea! Not the user itself! But good or bad decisions about when to use which tool and more importantly why? So I think we should be having these discussions about WHY.
If we want to learn more about WHY, your books are good at comparing and contrasting, but when I think back there ‘re a few book about compare and contrast. Almost each book is, here's a method I'm explaining it ... with the good and bad points of it. It relies on a lot of synthesis. So do you have any recommendations for us?
Yes! Just based on my own trip trough Agile Land I bumped into XP around 2000 and started applying it and then I discovered Scrum later on and started applying that and realized they fit well together and then from there I started dabbling in Lean and digging in there I found this cool soft called System thinking and the theory of constraints. When digging there a little bit into there, the history I suddenly start to understand why these methods work. At least better. And that really helped me explain to others why they work. So if you're going to use these method try to take one step deeper and maybe read a little bit about systems thinking or the theory of constrains. Read the Goal by Goldratt or maybe "The fifth discipline" by Peter Senge .
So read a lot of the things that are outside the discipline but very related
Yes! Because the principles are generic. None of this is really specific to software development at all. So if we dig a bit deeper there' s a lot of knowledge out there.
You've been very involved in this conference and you‘re a new member of the Agile Alliance Board, but in this particular conference you ran the music stage?
Yea! I've been coproducing the music stage. This is the second year. And if the stage continues, I hope to be involved the next year as well.
Sounds interesting! What is it?
It's basically a bunch of nerds jamming. So it's a conference, an Agile conference where we're doing all these workshops and things, but then there is a music stage with a bunch of instruments. The idea is that people can go there to play music. And given a collection of 1300 people you are bound to find something interesting. So there's basically three goals: one is to provide a place for people to jam and have fun, so it's for the people playing themselves. The second is to provide some kind of entertainment at the banquet and the third is a place for people to go and listen to music and enjoy. Note the priorities though! Number one is the people playing the music and then number three is people listening. So it is primarily for the performers.
How does that tight into Agile?
It doesn't really directly, but indirectly it does and I think this surprised all of us a little bit; my main hobby, so to me it's nothing new it's just what I do, but it was fun looking at people's reaction, people who were involved in music. They come and they watch and they say " This is strange! A bunch of people who have never met each other get up on a stage and grab some instruments and they play and it sounds like crap for about 5 minutes and then suddenly start sounding really nice and this guy starts soloing and then the rest quiet down a bit, and he start soloing and they quiet down a bit. It's self organization. And it's a typical small team, and it's pretty much....this is Agile in action in another context. So that's really interesting.
So that's very interesting. In the beginning there‘s this forming. Very much, within minutes you see it...
Sometimes! Sometimes you don't. It changes sometimes, it's dynamic, but mimics a lot what happens in teams. You have the bass player, maybe that‘s a database specialist he has his thing he's supposed to be doing, but that doesn't mean he‘s ignoring what's going on around him. Suddenly the saxophone player is trying to play a solo if the bass player isn't listening to the whole, he's going to be whacking along the bass still and nobody can hear the sax guy. What's also important is that's the result that counts, just like in a Agile team. So I may be playing a really, really cool thing at bass, but if that's messing up whatever is going on in the band, then we as a band don't sound really good.
It's a team success. It's not an individual success.
Yes! So I'm thinking I should be doing a jam session thing as part of coaching.
It sounds very interesting! And you know what? What really peaks my curiosity is you say: "Sometimes it happens that they get together and sometimes it's just discord all the time". What's the difference? What's the individual difference?
Sometimes it's just a matter of training, craftsmanship, and I got to say that buzz word too. Sometimes it's just a matter of craftsmanship, if you get people up there, you don't really know their instruments. You don't need to be really, really good but you just need to get over the basic threshold. Sometimes it's a matter of personality, if you get a lot of people that are more interested in showing off than making nice music then that can mess things up. And sometimes it's just technical issues. I can't hear the singer, I can't really here him right now because the setup of the stage. So that would be like equivalent with team whose continuous integration service is not working, so we can't produce software. And what you do in that case? You stop right? And you fix it. So it's the same with the stage.
13.03 Q: Because if you keep going on it's not going to sound any better 783
13.05 A: It's going to sound like crap and is no audience left, so the metaphor is, "I'm not going to stretch it anymore ..."
It works really well! I can see your eyes lit up when you are talking about it, something you're very passionate about and it's really as you said surprisingly. Well, maybe not a surprise.
I think I've just never seen a connection before; it's been different lives through different hats, like I'm not a musician and I'm an Agile guy. I realize "maybe there is a connection here!"
6 comments
Watch Thread Reply