James Grenning on Agile, from co-authoring the Manifesto, to fathering Planning Poker, to Agile for Embedded Development
Bio James Grenning, founder of Renaissance Software Consulting, trains, coaches and consults worldwide. With 30+ years of software development experience, both technical and managerial, James brings a wealth of knowledge, skill, and creativity to development teams and their management. As his roots are in embedded software, he is leading the way to introduce Agile to that challenging world.
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.
1. This is David Bulkin from InfoQ here with James Grenning from Renaissance Software. James is one of the original authors of the Agile Manifesto. James, thank you so much for taking time out to join us
David, thanks a lot for the invitation, great to talk to you.
2. And we have a number of topics, let me just go quickly through a list that we agreed to. One of the is looking back at the Manifesto as one of the original authors, we’ll take a peek back to what it was to be there and the impact it’s had. We’re also going to look at planning poker which you actually invented and how planning poker works and influences the industry; its genesis and other forms of estimation techniques that you worked on and then finally we end it with talking about embedded Agile, another space that you’ve made major contributions in. With that being said, we’ll get started. Starting with the Manifesto, as one of the original authors, can you give us some background and how that all went down and what was it like to be there?
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.
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.
4. So tell me about the common ground, if I understand it correctly. I assume there is: each of you had some perspectives and so forth, some light-weight approaches. And when you’re meeting to understand what that common ground was, and in that manifesto define, I guess, that core?
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.
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."
6. So you had a larger impact than anyone obviously could ever imagined, which is a good thing. I got my start in the Agile field soon after the manifesto was signed. So, thank you. It helped me get my certain Agile theory after the manifesto was signed.
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.
7. On Monday at the Agile 2011 Conference there was a kind of get-together of your self and the other individuals most of them who signed and worked on and were authors of the manifesto. Were there any take-aways from that; would any of you guys have done anything different or worded it differently?
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.
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.
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.
10. Whoever that was, I apologize. Some of other areas that you participated in or another huge area that you helped the community with, I should say, is planning poker. Can we talk about that for a little bit? You know, the genesis of how planning poker, why it was invented?
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.
Of course, you’re hearing it first hand here. So we took a break and I had my pocket full of these.
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.
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.
15. I’ve read it. Now, I can’t help myself and show yourself since you mentioned Lowell Lindstrom, and playing poker. I have, not long after you came out with planning poker I started using risk poker, I never took it to market; take a quick look. This is risk poker and Lowell has actually used it in some of his classes. So, I could say that you motivated me and helped give me direction. So, thank you for that.
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.
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.
17. You may get a deck when I get the book. And talking about the book, so you’ve written a fairly new book, Test-driven Development for Embedded C. Before we talk about the book itself, let’s just back-track a little bit: A lot of what you do is embedded Agile. I think that Agile is certainly becoming very popular in the embedded space. You see more one more conferences but that’s more recent, in the last few years, at least in my perspective. So, can you give me a little bit of background about how, I guess, the organizations doing embedded software can benefit from Agile the same as organizations developing business systems?
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.
19. I guess the point is: picking up your book again. What I do each day in and day out is embedded programming. I’m assuming that the language in this book will be oriented to that type of individual; it’s going to be easier for them to learn and grasp the concepts. So, here’s the book and I recommend what it offers: buy at least two, one for the home and one for business, right?
Or buy the electronic copy.
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.
22. So in kind of a wrap-up then, some of the common themes I’ve heard is looking for the commonality and the focus on people. So, I knew we looked at a few different topic areas; manifesto itself, we looked at different ways of estimating and it’s a way of collaborating coming to common decisions. We looked at developing software for embedded system which we see to some extent is the same as developing software for non-embedded systems.
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.
You’re too kind.