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.
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.
7. 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.
8. 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.
9. 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.
10. 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.
11. 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.
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.
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 .
16. 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.
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.
18. 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.
19. 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.
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.
21. 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.
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 ..."