00:13:41 video length
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.
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.
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.
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.
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.
4. 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.
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.
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 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.
Yes! They found the buzz word and that's maybe a good start, but that's just a start.
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.
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.
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.
12. 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!
Yes! So is no such thing as a bad tool! It's just....
14. 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.
15. 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 .
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.
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.
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.
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.
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.
Yes! So I'm thinking I should be doing a jam session thing as part of coaching.
22. 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 ..."
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!"
Re: As always Henrik
Re: As always Henrik
Rem ten Hove
I agree on the nice interview part, but not on your statement about there not being any relationship between scrum and music. When writing music you do adopt an approach similar to scrum.
Ritesh Man Tamrakar
Re: As always Henrik