It was a really interesting meeting. I feel really fortunate to have participated in the meeting. Bob Martin, who I worked with at the time also one of the authors of the manifesto, he was organizing the meeting. And he invited me to join in and he told me it was in Snowbird and of course, I said, "Yes, I’d like to go." And in my mind, I thought, "Skiing?" Right, Snowbird is one of the best places to ski in the world, so you got to go there.
And then not only that but we had been working at the time with Kent Beck and Ron Jeffries and Martin Fowler and Ward Cunningham; and so having an opportunity to go and be with those guys and talk some software was really appealing too.
3. When you went there, did you have any idea of what the impact would be of your work?
You know, I didn’t have any expectations and I remember talking with the group while we were there. It’s like, "Who’s going to kick in" after we wrote the manifesto. Do we think anybody is going to care and we were pretty sure that no one would care but at least, we did something. And found out where our common ground was and what it is that we had in common.
Right. Well, you mentioned light-weight, let’s just start with that because what to call the manifesto after it was written was kind of interesting. Because no one wanted to be known as light-weight. So, we needed something different than light-weight. So somehow Agile came to be. I don’t really exactly remember how.
So, it was interesting because there were competing ideas there. I was there with the Extreme Programming contingent where we thought we found the savior of the software world through Extreme Programming and there were people from Scrum, DSDM, FDD - a lot of different; kind of alphabet soup of different ways of doing things.
It was interesting to boil down our differences and find out what’s common, you know, planning poker and the creation of the manifesto had something in common which is: where do we agree? Finding a way to come up with what we agree on and so, when we created the manifesto, people would toss ideas out there. There would be this synthesis of things that we agreed on.
One thing that kind of surprised me as an engineer was all this focus on the people stuff. You know, I’m just not used to talking about engineering from a people perspective because you just do the thing that makes sense, right? So that was an important ‘ah-ha’ moment for me as well.
5. Was there ever ‘ah-ha’ moment over the last decade where you said, "My God, this thing is big."
I was shocked when somebody told me there were 50,000 Scrum masters. It was like: "Oh, my gosh, okay, well I’ll probably be pretty as a consultant helping them with technical practices."
You’re welcome. I wish it wasn’t me and if it wasn’t me, it’s probably mostly you. I think so many people had done so much good work and I celebrate that the industry is not satisfied with just doing stuff the way they always have done it. They’re trying to improve and that’s what kind of gets me excited about coming to this conference it’s because no one is satisfied. It’s not the same things that we talked about last year or the year before. Things continue to kind of push the envelope.
I think that question was asked of the panel, the people at the park bench, and really nobody felt that we would change what was there and I don’t either feel like there’s any big needs for any kind of changes. It was interesting I did go to the 10th year anniversary that Alistair planned in Snowbird on the day of the 10th year anniversary just a few months ago. And again, I went without expectations and to go skiing; so keeping up.
8. So you haven’t changed much in ten years?
I haven’t personally; but it was interesting the conversations we had there. It was a wider group than the original group and one of the things that I was happy to see there is there’s kind of a feeling that individuals need to take ownership for their learning and advancement and you know, just saying your Agile is not enough, we have to kind of first try the ideas and refine them and adopt them to our needs and don’t think that we’re done; because were always going to have other things that we can address. And so really the Agile way is more of a way to proceed and not a destination.
9. So, Agile is a journey, not a destination? Later, you can quote me on that.
Well, okay. We’ll be quoting someone else so we don’t know about because I’m sure somebody famous who probably said that by now.
Now for a start I thank Mike Cohn right away because Mike read my little paper that I wrote back in 2001 and said: "This is kind of neat" and I’ve started using it.
Mike, thank you because you made it go viral and refined it and enhanced it but where it came from? Well, in the old days, at Object Mentor, when we’re trying to spread the good word about Extreme Programming, my friend, Mike Hill, said it best. He says: "What coaching gig is like: is you’ve got a bowie knife, a stack of index cards and you are parachuted in to enemy territory." And then you have to make something happen.
Well, I was in this meeting and I was facilitating as their business coach. My background involves technical and managerial and almost marketing a couple of times, it’s been kind of a broad background over all these years.
So, I was facilitating the planning meeting and we had this table with about eight guys around it, the two senior Lead architects were at the table and they kept going back and forth debating how they would build the story. Now I can detect that really quickly, but then it was taking me a while, half hour or an hour goes by and I started to notice that the numbers that they were talking about at the beginning of the hour, were the same numbers that they talk about at the end of the hour were the same numbers that they talk about at the end of the hour and then all they did was argue about how they were going to do it and which approach was better the whole time.
The other six people around the table were falling asleep. They were disengaged because we had these two guys that were the alpha dogs of the technology. And so, they were kind of monopolizing. Now, John Johansen might listen to this and say it wasn’t like this because he was there but this was my recollection, anyway.
11. And it’s a correct recollection?
Of course, you’re hearing it first hand here. So we took a break and I had my pocket full of these.
12. You do have some cards right there?
Oh, I do have some right here. This is not enough to facilitate a planning meeting but so I had everybody take a card, we listened to the story and I said, "Now, everybody don’t say a thing. Write your estimate on the card and when you got it, put it on the table and we’ll flip them over all at the same time." So we got the story done in 5 minutes instead of an hour. And then we did that again. Everybody agreed and they asked me, and we got another one done in 1 minute.
And after a little while, everybody who was sitting on the table has got their index cards which they kept collecting back and it kind of looked like a poker hand. And here I am in Utah and I know maybe half of the population doesn’t play a lot of poker but it looked like we’re playing poker. We barely left the table either. So, we had what looked like people playing poker and I just wrote up the story and put it on the Object Mentor website. Mike Cohn found it and made it famous.
He introduced other ideas like Fibonacci numbers and all these other kind of stuff. Which were never part of the original. The original is just, "Let’s not talk. Let’s find out where we agree."
I just did some research and I did a talk on this at the conference, and most of the people that cite benefits talk about all the good conversations it causes and nobody cited the real reason I originally started doing it was to get rid of the conversation when we did not need it.
13. I guess it’s a focused conversation obviously?
Well, we then focus on the parts where we needed to and we got out of the way with the things you agree on really quickly.
Sure, yes, well actually back probably in 2001 or 2002, Lowell Lindstrom, who I also worked with at Object Mentor, started showing us an idea he had which was Affinity Grouping and that triggered some brain cells which was, probably in the ‘80s, when we were doing total quality management, we used Affinity Grouping for lots of things and laws involving that at the company we used to work at before Object Mentor.
And so we started using Affinity Grouping for estimation. And so now, I’ve started to promote that, actually since probably 2002, I haven’t even used planning poker. And I’m kind of amazed at the following it has.
And so, in today’s session, I give people the history of planning poker and then told them not to use it. It’s kind of funny. They were not expecting that. Then I described using the Affinity approaches and there are a series of activities which I named after poker game, you know, a different card game just to follow the tradition. I call it the planning poker party and I’ve got a blog about that on my website and I’ll put a link up there for today’s presentation, so, kind of fun.
It’s interesting. There are a number of these side games: there’s value poker where the customer product owner people are trying to rank the values and such - you got the risk poker, (what else has there been?) those are three I know of: planning, risk and value.
16. Well thank you for your influence in a positive way.
Very good. I’m looking forward to getting my deck. It will look well with the other 20 decks of planning poker cards I’ve played for a couple of years.
It’s interesting back in 1999 when I was just first started learning Extreme Programming, I was involved in an embedded consulting job at that time and we were not going to have hardware nor an operating system for quite a while still and what the client wanted me to do was work with them to write Use Cases and draw up an architecture and we were going to do that.
After writing up the Use Cases, I went to the first ever Extreme Programming immersion that we did at Object Mentor and started hearing about some interesting things which I really wasn’t that aware of; Kent Beck’s book was recently out.
When I saw the demonstrations of what was called test first development at that time, now it’s called test-driven development of-course, maybe it’s even a follow on refinement of test-first development.
What I thought right there was kind of synthesis moment which was, "Wow! We can break dependencies on things that we don’t have." So, for instance, if we need to build some system, and it needs to interact with a hardware and we don’t have the hardware, we can still create the software and provide fakes, and stubs and mock objects and such to do the things that don’t yet exist.
And that was like a shock. It’s like, "Oh my gosh! I can hardly wait to get back to work on Monday and tell these guys how we’re going make this progress. And I got pretty excited and I got to coach my first Extreme Programming team. I think it might have been the first team that was ever coached by Object Mentor in Extreme Programming and I didn’t even know it yet but we were learning.
We had seen it done by the experts. I’d seen it done by the experts and started showing the team I was coaching over there. And it worked out really well for getting our ideas together and getting code that worked before we had the hardware. So, that was kind of how I got started with it.
You know, that is the big secret. I was telling Michael Feathers that I was thinking of writing this book and he kind of looked at me funny and he said: "James, why do you have to write that book because it’s just the same as any other software?" I said, "Oh yeah, it’s true except that the guys doing embedded won’t look at the books for Java programmers, for business applications. It’s not on their radar screens. It won’t mean anything to them.
20. There he goes. It makes sure you always have it.
So in 2002, kind of getting back to your question about the influence on the industry and where the industry is going, I started doing talks in the embedded system conference on applying Agile to embedded software.
First, I wanted to see what was offered and nothing was and I was kind of shocked because these ideas seemed to fit a lot. So, I started doing talks and the initial reaction from the embedded systems attendees was: "You should not be here. This doesn’t have anything to do with us." But I had belief in my mission and I knew I was at least going to be right for some of them and so I continued and now I’ve been there nine times.
Yes, they let me come back and refined my mission and I’ve refined my way of explaining it to people doing embedded such that people tell me the book is pretty good.
Yes, it’s true. The language is often different and I don’t mean just the programming language but the way the people communicate with each other is essentially different because they are talking about different things: devices, and registers and clocks and things where business people are talking about databases and GUI’s.
There’s a whole, like different world but there’s so much that can be learned between the different groups and this was kind of one of another lucky thing about my career was probably starting in embedded and being able to work with Bob Martin and seeing a lot of things that weren’t embedded as well and then kind of being able to bring those really kind of mainstream or state-of -the-art software development ideas from object-oriented and extreme programming and such to the embedded world. Without that it’s harder for them to discover not that no one does, some do. But I’m trying to make it more accessible.