01:14 - Jared Richardson Introduction

01:31 - Andy Hunt Introduction

02:35 - Background, The GROWS Method

16:51 - Getting Things Done

19:18 - Transitioning to GROWS

23:45 - Experiments

28:39 - Blind Spots

30:22 - Pain Points and Benefits

35:52 - Where do I start?

43:30 - Can you do GROWS on a small team?

50:25 - Working on Stage 2 before Stage 1 is Done

54:06 - The Growth of GROWS

Announcement

Picks

Dan Wilson: Regarding Ground Rules For Collaboration (Jaim)
Saramonic SmartMixer Professional Recording Stereo Microphone Rig (Chuck)
Unboxing of saramonic smartmixer for periscope. #ufy (Chuck)
Clash of Clans (Chuck)
Derek Sivers: The /now page movement (Andy)
nownownow.com (Andy)
tonymacx86.com (Jared)
Get out from behind the keyboard (Jared)

 

Hey everybody and welcome to episode 133 of the iPhreaks Show. This week on our panel we have Jaim Zuber.

Hello, from Minneapolis.

I’m Charles Max Wood from Devchat.tv. This week we have two special guests; we have Jared Richardson.

Hey, welcome from Raleigh, Research Triangle Park, North Carolina.

And Andy Hunt.

ANDY Hey! Glad to be here.

Why don’t you two go ahead and introduce yourselves really quickly?

My name’s Jared Richardson. Gosh, I’ve been an Agile coach for a number of years; written a few books, [inaudible] a few conferences most recently and the topic of today’s discussion and collaborating with Andy on the GROWS methodology which has been a lot of fun. How about you Andy?

ANDY Yeah, some of that. [Laughter] I’m Andy Hunt. I wrote a little book around the turn of the century with my friend Dave Thomas called The Pragmatic Programmer that you might’ve heard of. I’ve written a total of nine books since then and our publishing company has published 250 titles covering everything from Ruby and Rails and now Elixer and Phoenix to Agile methods – anything the aspiring programmer would want to learn these days.

Yeah and I think your most important accomplishment was an interview that happened about five years ago. You were interviewed on my old Teach Me To Code podcast.

ANDY Ah! Okay. Great, yes, I remember it well. [Laughter]

Oh yeah that. That was awesome, sure. [Chuckles]

It’s not the years, it’s the mileage.

That’s right.

ANDY Ahh, that’s the truth.

But yeah, I think we talked a bit about pragmatic thinking and learning and the Agile manifesto and that was a lot of fun. We’ll put a link back to that blast from the past.

Do you want to give us a fun mail sketch really quickly of what the GROWS method is?

ANDY Yeah, we can do that. Let me talk just a little bit before we get into that about why we felt this was necessary and how we got here. I know no one likes to hear big long history lessons so I’ll keep it short.

I thought it was – it was interesting to me probably about that same time, probably about five/six years ago. I was visiting a client and they were really doing XP on a large scale. They had a large team, 150 people maybe. I have rarely seen such devotion in an organization to getting it right to working and trying to excel at the practices. I went in first and I thought ‘wow, this is great’. Here’s a large group of people who are committed to the ideas of Agile who are really working on it. This is great; why couldn’t the world be more like this?

As we started looking a little closer, cue the dark violin music coming up in the background, it was an incredible dark side to it because they could fall into the trap of trying to perfect the practices at the expense of actually understanding what they were doing or producing software or growing their skills or all these stuff. We’re actually supposed to be using the practices to help us do. They have fallen into the trap of celebrating the practices as their own end. I joked at the time that they got into the point where they had to had a stand-up meeting and story cards to decide where to go to lunch for that day. Literally, it was that bad and I found out just at the conference or earlier this year that that group is no more; they imploded on themselves.

At the time – we’ve all seen people misapply the lessons of the Agile manifesto and get the wrong idea about Agile practices in this sort of things, but that incident really struck in my mind as doing it on an industrial scale, really misunderstanding and running with that misunderstanding as far as I could.

Since then, I’ve seen more and more of that. I’ve seen more of people misunderstanding the Agile manifesto and either just working on the practices for the practice’s sake or more commonly, adopting maybe two or three of the common Agile practices and saying, “Yup, we’re there. We’re Agile, we’re good. We’re ready to go,” and missing the point.

About a year ago, somebody said something about, “I really would like to experiment with this idea of Agile with my team. I’d like to try out some of the stuff and see what works and see what doesn’t work, take the best of it and do that. But I can’t do that because none of the existing methods tell me that that’s okay to do. [Chuckles] Which – I know it’s – this is why Scott Adams is in business [crosstalk]; he just get some stuff in – the material rights itself folks. But that really struck me and I’ve heard similar sentiments and [inaudible] from people, especially if they're not particularly familiar with the ins and outs of software development or particularly familiar with the dynamics of how Agility should work, how modern software development should work.

On the one hand, you got a set of people who really are curious, who want to try stuff but are kind of hamstrung because they don’t have a license; they don’t feel empowered to just do it on their own so they take two or three Scrum practices – sorry, that was just a typo [chuckles] – one or two Scrum practices and call it done and ignoring any level of technical practices like you would see from XP. That’s where they get stuck so I figured, okay, at a minimum I can help some of these folks out and say, “Bang, here’s a new method. We’re going to call it GROWS; now you’ve got a license to experiment. [Crosstalk] If nothing else, right there – now you’ve got mom’s permission to go try and be Agile.”

Do I dare admit that I’ve been on those teams where I get hired, I come in and they're like, “Yeah, we do Agile.” Ad I’m like, “What do you mean by Agile?” “We do Scrum.” “Okay, what do you mean by Scrum?” “We have a stand-up meeting every morning.” “Okay.”

We have an hour long status meeting every morning. [Crosstalk]

We don’t plan anything. We’re totally Agile. [Chuckles]

How about the team that has their daily stand-ups on Fridays? They're Agile right because they call it a day.

Yeah.

I love Fridays. Only Fridays.

I’ve also been on a team where we had the Scrum master that was more interested in the process than he was in getting software written.

ANDY Exactly.

But he had the training and the buy-in from the company because he was trained and because blah, blah, blah and social proof and it was a disaster.

ANDY Sure, and that’s really the big danger right there. All the major methods – Scrum, XP, lean practices – they all will tell you in the fine print how to do it correctly and they’re right. They're absolutely right. Yes, you should do these things, you should not do these other things and so on. The problem is no one reads the fine print they gravitate towards the several popular practices or their interpretation of several of the popular practices and call that done.

One of the things I was talking to Jared and we realized, if nothing else, people will do the practices that you give them. They may not understand why, they may not care why, they may not ever do anything else; they will do the practices. Okay, let’s use that to advantage them. Let’s come up with some practices that even if they don’t do anything else right, at least this will help get them on the right road and inculcate some of the values that we want them to have by using the practices as a vehicle to get them there.

The other thing we realized, Scrum for instance says ‘inspect and adapt’ but every single Scrum team you’ve ever encountered is inspecting and replicating and duplicating what they learned in their first class. Most of the practices out there, we tie it in with what Andy brought over with the Dreyfus model of skills acquisition and the Refactoring Your Wetware book. With the Dreyfus model, it talks about the beginner’s needs steps and moves up to stage five where you get a lot of freedom. And most of the existing practices either give you steps that beginners latch on to and won’t let go of, can’t pry it out of my cold, dead hands, or they're all principles and the beginners have no steps to get started with. So GROWS is trying to map that; here are the steps but if you're looking at GROWS, it’s really, really clear that you have to move up through the stages and eventually throw these steps away. Don’t know if any other practice walks you through that.

I’ll tell you that one thing that I have seen work really well on some of the teams that function well was that they did what you're talking about where initially, yeah, we started out, we were really, really specific about how we’re going to manage our backlog, how we’re going to do estimations, how and when we were going to pair program and how we’re going to pull all these other things together. Eventually, we started doing the retrospectives and we sit down and we’d say, “Okay, we’d like to try this other thing,” or “We like to go in this other direction” or “We’d like to see if this will work for us” or “This particular practice, even though it’s recommended with all the other practices we’re doing, seems to get in the way so we’re going to do some experiments around that”. Eventually, what we’d wind up with was nothing that you would recognize as a specific methodology if you understood all of the Agile methodologies; it was just something that pulled in practices from everywhere and worked for us.

That’s exactly how it should be. That is the goal that we wanted. Back in 2001 at the turn of the century, there was the Agile manifesto. That meeting in Snowbird with the 17 of us that got together and thought that would be a good idea to do. There was a couple of interviews at the ten year reunion mark of that. One of the interviewers said, “Given all of the decades that has passed since then, what did you all expected to see happen that didn’t?”

One of the things at that time was it was a common thought amongst all of us there that you would see an explosion of Agile methods. You wouldn’t see one or two or three; there’d be 50, there’d be 100. Every consultant and his dog would have their own mix and match of variations on the popular practices at the time and you have tons of this stuff. That didn’t happen. The world largely gravitated to Scrum practices or a subset of Scrum. They call it jokingly ‘scrum-but’; “We’re doing Scrum but we’re not doing the important half of it,” largely, scaling over XP or the technical level practices at that level.

Even if they had done that, XP still isn’t complete unto itself; it assumes you're doing things underneath that that they don’t mention like using version control properly. So you’ve got these several layers of – you got to have the underlying – for God’s sake, use version control. It galls me that in 2015, that’s not 100% guaranteed.

I meet people at every single conference I go to where their model for version control is a big shared disk and the last one in wins. Still, I’ve made that joke for 10 years not and it’s not funny anymore. [Chuckles]

It’s depressing.

ANDY But you’ve got that. Then you’ve got maybe one or two bits of XP is flavor for the most advanced teams; everyone’s doing the stand-up meeting and they're trying to do iterations but it’s a six month iteration that gets stretched out to a year.

Yeah, I’ve seen that, too.

ANDY Kind of missing the point here. So what Jared and I thought we would do is we’d put together some of these thoughts. We’ve got the Dreyfus skill model to say one of the problems why people are misunderstanding and misusing Agile is we threw them all into the deep end. We gave them the end product and said, “This is what an Agile team should look like, it’s what an Agile developer should look like. Go!” And really didn’t appreciate the growth that it takes to get from a novice stage to advanced beginner, confident, proficient expert – however you want it. That’s what Dreyfus does but it doesn’t really matter. However you dice the stages up, you’ve got to go through this learning process to get there. We as a community weren’t really good about leading people through that process, about using any kind of educational petty guide, it’s just, “Here, do it,” and it didn’t work out.

So GROWS, we’ve got the Dreyfus model to help guide us through the things. We really like this idea of experiments for a couple of reasons. First of all, you mentioned Charles with your experience in that company, not everything’s going to work for you. One size doesn’t fit all. If you’ve got a huge team with separate people as architects and UI and UX experts and all these stuff; you’ve got a three person startup and all of you do everything, that’s a very different model. Any particular given practice is not necessarily going to work well with both of those or any of the other million variants that are out there.

On the one hand, you need experiments to fuel adoption to say ‘will this work for us’, but also possibly more importantly, the idea of an experiment is that you’ve got some control over the process, over the adoption of the process. Instead of going in and neither having an anointed Scrum master or an interested executive or lead developer who’s into this, somebody cramming it down the team’s throat and saying, “Yay, we shall be Agile starting tomorrow,” which doesn’t work. Instead, it’s like, “Guys, let’s try this.”

It’s an experiment. We’re not committing to it. You get over that fear of commitment and all that psychological resistance right out of the gate by saying, “This might not take. We may not like pair programming. I may not like sitting next to you ever.” [Chuckles] These things happen and that’s fine but it gives you a chance to try it and work with it and adapt it if necessary because, after all, inspect and adapt is supposed to be the name of the game.

Yeah, the other thing that’s interesting is first of all, I’ve seen companies where different teams actually had different methodologies within the same company [crosstalk] but working on the same product.

ANDY And there’s nothing wrong with that. There’s absolutely nothing wrong with that. In fact, I would say that’s more the natural state of affairs if needs be because – I like to say it in all my talks ever since the thinking and learning book, the context is king. Context is the most important thing to bear in mind and that’s the prime example of it. You’ve got two teams that happen to work for the same company on the same project, alright, but what are they actually doing? Are they actually working on very similar pieces or are they working on very dissimilar pieces – dissimilar talent sets, deadlines, expectations. I don’t know the particular context there but if the context is different then it makes perfect sense that the team organization and structure and methods would be different.

Yup. So one thing that I have to point up though with that kind of set up is that in a lot of corporations, especially if they get large, they tend to like to streamline their processes. And they tend to have everybody use the same process. So how do you get the people who are higher up to get over that tendency and get over that being the right way so that developers can build the software in a way that makes the most sense to them?

ANDY Fundamentally and certainly as a business owner – I can vouch for this – with my business hat on, I don’t care. What’s that line in board games? I don’t care if you piss on a spark plug as long as it gets it done. As a business owner, I just want it done. I would like it done for something less than the gross national product of Switzerland; I would like to get it done quicker than the heat death of the Universe, but other than that I really shouldn’t be poking in at that micro-management level to particularly care.

There are some concerns about training and going to the cross teams and what-not but on the other hand, your team should be small and stable anyway so you shouldn’t have a lot of crosspollination of pulling people from one team into another in the first place.

How small is small?

ANDY Under a dozen. Because what happens – there’s tons of communication studies out there that show this that the more people you get involved in something, the communication overhead goes up exponentially which gets into a whole discussion of scaling Agile which is frankly an oxymoron but that’s about a six-hour discussion for another time. [Chuckles]

Yeah.

ANDY There’s a great – I forgot who said it – somebody who has a great comment on Twitter saying instead of seeking to scale up , first, try scaling down your mess and then worry about that other thing.

You mean adding something that’s already messy makes it more messy? [Crosstalk] Imagine that.

ANDY Stunning isn’t it? But that’s a good point. I would just say this briefly; the idea of scaling Agile is – scaling is going to take something and make a lot more of it and make it a lot more entrenched. And if what you’ve got is crappy or even vaguely crappy then all you're going to get is a lot more crappy, that’s a lot more engrained and hardwired into the organization so that may not be the best way to go.

So let’s say that I am a company that has invested heavily in XP. So I’ve gotten people trained, I’ve got all my people doing what XP says I should do, I’m looking at this and I’m thinking ‘okay, maybe there’s something here that says that there are things that I can do better that aren’t strict XP.’ How do I start making the transition from XP over to GROWS?

I’m getting the impression from you that you're not going to say ‘throw out XP and start over’; you're going to say ‘start [crosstalk] from where you're at’. Where do we go from there?

ANDY Definitely. What we have, and you can go to our website at growsmethod.com – nice subtle pitch there – where we layout some of these things. There’s a couple of aspects to that. The first thing is what we want to make sure happens with GROWS is that even if you are an experienced “XP shop” or Scrum shop or lean or crystal methods or whatever you're doing, we want to make sure you haven’t skipped any steps. So even if you are at a higher level, you want to look at the novice level steps and say, “Okay, do we have that covered? Does this cover the basis?” The beginning steps are really brutally simple. Is everything in version control? Can you build your product on a bare machine with suitable build tools? Can you check everything out and build a product release in one go? Do you have continuous integration, automated bills that – very boring but very necessary safety and hygiene level of automation and infrastructure?

30 AM. You can talk to the users all you want, you can do user stories and cards and planning poker and all stuff, and if you can’t actually get the software out, none of that matters.

First thing, we look in the mechanics; make sure you’ve got all that stuff covered then you start moving up the skill stages that we’ve got laid out. Now we’ve got that done, let’s talk about doing this, let’s talk about doing that, more customer involvement and so on and so forth and up the chain you go.

One of the several keys that we want to make sure is that you’ve got that basic level covered and that development is done in a genuinely incremental and iterative fashion using the idea of Tracer Bullet development that we coin that term back in the Pragmatic Programmer. Jared expanded on that in his book Ship It. It’s similar to – the folks call it Walking Skeleton or a Thin Thread Model or a Red Thread Model or this idea off idea where the very first day of development, you’ve got a ‘hello world’ that goes all the way, end to end. So if you're doing web development, it’s going all the way from a browser to your web server engine through a database, any other kind of middleware, other stuff you’ve got glued in there. Whatever you’ve got, you got all of it strung together. Very thin; literally hello world. One or two lines of code all the way through but you’ve got all the pieces, and you go in to fill that in as you proceed.

So these are the things that we think are at the fore end and even if you're in an existing shop, these and several other ideas are things that you might have skated over, maybe you’re not doing as well as you could. Maybe there’s room for improvement there. On top of that, we’ve got the idea of introducing experiments for iterations. You can say, “Okay, we’re not very good at some particular practice that we’ve identified here so let’s try this this time.” We’ll get some concrete feedback from that and say, “Okay, yes this is really definitely a problem. Here’s what we can do better.”

So what’s an example of an experiment?

ANDY I am so glad you asked. [Chuckles]

I like the JavaScript example. You get [inaudible] on the team and somebody says ‘I want to use this framework’; someone else says ‘I want to use that one’. Someone else says ‘hey, I just wrote that one while we were talking.’ [Crosstalk]

Boy, you understand JavaScript because that’s just about how fast it’s moving. [Chuckles]

I do. So who wins? It’s either the loudest voice or the most senior person. Not the most suitable tool. Andy’s been saying we suggest it, I’ll go a step further and say we require it. You’ve got three competing tool kits and I have this – I’ve had this at several clients. You say, “Okay, I’ll tell you what, for the next iteration, each of your three different camps go right a very basic yet useful app in your toolkit of choice. Use the JavaScript toolkit.” Usually one group raise their hands and go, “We can’t get a hello world in two weeks,” and you go, “Aha. That’s good information.” If this team wants to use this server framework versus that one, go write something. And if you’d just have one experiment, what is it? It’s proof of concept that we’ll get pushed into production. That’s real code.

You can’t have one experiment; you got to have two, you got to have three. You have to have multiple experiments so that you can learn something from it. As Andy says, software’s soft, you get used to throwing away some of these stuff. It’s cheap to create if you have some competition and learning going on in there.

You’re going to give somebody a hernia saying throw away software. [Crosstalk]

Throw away software.

ANDY That is absolutely critical. That’s – let me [inaudible] experiments in there but that is a critical point. The worst thing you can do is keep half-baked software roughing around to smell up the place. You got to consider, software is really more like sour cream than it is like pottery. You really don’t want to keep it around too long, it starts getting funky. [Laughter]

If we can get people to – I mentioned this in one of my talks that we really want to look at code as disposable. In fact, as an architectural principle, for any given piece of code that you're writing, any part of the system, if you cannot easily rip it out and replace it with something else, then your design sucks. Period. It’s that simple. If you can’t rip it out overnight and replace it with something better, different, more responsive, more agile then it sucks and you shouldn’t be doing that. But that’s what I want to talk about. [Laughter]

Let me go back to the previous question about experiments and just clarify something. There’s two different takes on what an experiment is in GROWS. On one hand, there’s experiments for technical learning; somewhat you're doing a prototype or a spike or something like that where you're going to try something and gather whatever feedback is important to you. Did this make it manageable? Did this make it more reliable? Is it easy to write? Was it easy to maintain? That kind of things viewed in the technical light and that’s not too far a stretch.

What I think is probably more important is the idea of using experiments for process adoption. On that front, in the actual GROWS material on the website, we try to put – for the description of each practice, we list out an adoption experiment for it. So we’ll list up how to set up to do the experiment, what to do as to trial and what feedback, concrete feedback to look for and evaluate at the end of the experiment. So just as the simplest possible example is for version control; it’s at the very bottom of the pyramid, the most basic thing. So the setup is very simple; tell us how to set up an instance, install version control client, check in all your local stores. The trial is to try to build the product directly from version control into a releasable state and evaluating that feedback. Could you do that? What’s missing? What do you need to check in? What other tools do you need? These kind of thing.

So every one of the practices tries to have this layout of set up trial and evaluation so that you can say this is working for us/no this isn’t. Of course the trick is as you go up in skill levels, as you go up the skill model, the lower level skills are much easier to specify concrete feedback for. If you got a continuous built set up going, it’s pretty simple to determine yes, it’s working/no it’s not. It’s a pretty black and white thing.

When you get into more interesting things like did you satisfy the customer’s requirements and is the customer happy? That’s a little fuzzier. That you need some judgement for. As we find from the Dreyfus model, you don’t get that judgement until you're a level three or four up the model. Beginners don’t have that which is another whole can of worms.

Something you mentioned earlier Andy about coming in with new teams. A common blind spots – I’ve never a team that didn’t have a few glaring omissions in their process. What they do, they do really well. That’s how they make a living and gotten by. But there’s always some area that they completely have just – didn’t see it, didn’t know about it, blanked out on it. So you go to the GROWS method website and look at each roll. We have a series of little post-it notecards with the steps that say ‘this is the practice; this is how you should be using it. This is what looks good; this is what looks bad.’

I recently had a technical lead; very senior guy at this particular organization; few – over a thousand developers. He was considered one of the top ones. He was explaining to me that we were using continuous integration wrong. I said, “Really? What are we doing here?” He said, “Well the people on these teams are checking in code four or five times a day. That’s four and five times – they could break the bill. If you just hold your code until the end of the month, you're only going to break it once.” When he broke it, it would stay broken for a week but he only broke it once a month. So in his mind, he was doing continuous integration, but if you look at the GROWS card checklist and talk to most of the industry using continuous, they might argue that he wasn’t using it very well so he had a big blind spot.

Looking at the Dreyfus model, when you're just learning something you need steps, it’s possible you have a huge blind spot somewhere in your particular home-rolled process. Here’s some steps; have a look at them. See if you're covering the basics. As a doctor, are you washing your hands or are you just cutting from patient to patient to patient?

One thing I like about the – I just clicked on the continuous integration part to [inaudible] and list some pain points and benefits so you can instruct the team that you're working with to go through and read the pain points and saying, “Does this resemble our team?” So you have a way to go and actually look/find things that you maybe not – you have a blind spot on.

We originally had that final blop which I think now is titled something much more polite but originally said stupendously stupid – it was –. [Crosstalk]

ANDY It was stupendously stupid ideas which I really liked but we I had to change it to ‘how to fail spectacularly’.

We had a number of early beta people come back and talk with us and said, “Hey, at my client, every single one of these practices is what they're doing but I can’t show it to them because you're saying to them how stupid it is. Could you maybe tone down what you call it but leave it in there so we could actually show him the pages?”

There’s a lot of people out there that are doing “the right things” but they’ve stumbled on the basics.

What’s [crosstalk] funny is I’m looking at all these principles and a lot of these things – continuous integration is mostly focused on code but there are parallels in other areas where I run my own business. A lot of these things like version control, just having one place for all the stuff; continuous integration where I get a head check every time I change something. Time boxing is another one where knowing when something has to be done and what we’re going to try and accomplish over a certain time period. A lot of these things are – it’s focused on coding teams but they really apply to a lot of other areas.

ANDY Absolutely. As a server side thing I think it’s funny because a lot of the stuff that we’re running into in software development is not particular to software development; it’s just because it’s such an advanced –. We don’t have the distractions of a physical assembly line and the seasons of farming and vagaries of rainfall. We don’t have these other distractions; it’s literally just us and our brains. So we’re running into limitations of the species [chuckles]. These are things that our brains just don’t do well.

We look at the problems of getting teams to work and to manage teams. If you look at the folks who write on an organizational theory, organizing humans to do stuff is, relatively speaking, new to us as a species. We haven’t really been doing it for all that long. You could argue we’re not really that good at it yet, certainly not as good as we’d like to be at this point in time.

A lot of the stuff we’re running isn’t particularly specific to coding or developing software; it’s inherent limitations in us. Wow, that had brought the house down. [Laughter]

Preach!

ANDY And everyone’s thinking, “Oh God, I’m quitting my job. I’m going to go raise llamas now.” [Laughter]

A good friend of mine always says, “That’s it. I’m done. I’m going to go be a pig farmer.”

ANDY That’s it. We have a whole different set of problems, but the thing is we’ve reached this point now – we started – a lot of the Agile ideas started long before the Agile manifesto came to be. There was plenty of ramp up to that over the five, ten, twenty years before that and we’ve had ten/fifteen years now since the manifesto to see what people misunderstand, what we’re doing wrong, what we didn’t explain well in the first place. We’re trying to capitalize on some of that and say, “Okay, for each of the practices that we’re listing, putting in the warning signs.” If you see this, then you're not doing it right or you’ve got a problem.

Putting in the How To Fail Spectacularly which, as Jared said, a number of folks identified it as their business plan which is unfortunate [chuckles] but it needs to be said. It’s not enough to say do pair programming. As a novice, what does that mean? How do I do it best? What’s a sign that I’m doing it wrong? How do I know what I’m doing?

We’ve failed to provide a rich enough level of support for novices which is something we’re trying to address here, and then give the [inaudible] path of, “Okay, now that you’ve got the basics under your belt, now you can start looking at doing this, doing this other thing and eventually getting up to the level of an expert where one of the things that we promote as – if you're an expert level at some skill is that now you're in a position to teach what you're doing. You're going to try to replicate your learning, replicate your successes. You're not replicating nay particular process necessarily but you're replicating what you’ve learned and what you haven’t learned and all those things.

We’re trying to get that – the reason we put the name GROWS is it’s really two-fold. Not only you growing the software using the Tracer Bullet development style where you’ve always got something there and you're just growing and adding to it but you're growing the skills of the individuals and the team, you're growing the skills of the team, and ultimately you're growing the skills of the organization itself which, as an executive, that’s something I’m interested in. I don’t want my programmers to be dumb as rocks, I want them to be the sharpest tools in the box.

One thing that I noticed getting into this because I was like, “Okay, let’s say people don’t have any process,” and by ‘don’t have any process’ it means they don’t know what their process is because everyone has a process; it’s just a lot of them, if they're not explicit, they suck. Of course a lot of the explicit ones kind of suck, too. [Chuckles] anyway.

ANDY A lot of processes suck.

Yes. So I got in and I was like, “Okay, if I’m just brand new to this and Andy and Jared had sold me on this idea of Agile, and they sold me on this idea of GROWS, where do I start?” So I jumped in and I went to the website and I was like, “Oh, they’ve been talking about these stages.” So I clicked on ‘practices by stages’ and I see immediately core concepts and stage one which is really interesting to me.

So you moved from one stage to the other. You're trying to master some core concepts and you have a place to start, the safety and hygiene stage.

ANDY Yup. And that’s, again, the most important to at least get a solid foundation. In fact, if you go on the website, if you go to foundations, there’s a link under there on how to start or starting with GROWS or something like that. It mentions some of the key core concepts of always taking small steps using the Tracer Bullet ideas. Getting agreement from all the participants; we have a core concept of ‘agreed to try’ recognize that in any kind of initiative like this, anyone involved really has the power to torpedo the whole event. We try to get them to say yes, I recognize – as a participant in this, I can kill the whole thing but I’m not going to. I’m going to actually give it a try.

Some of these core concepts we go through – take a look at this, make sure we’re on the same page, we agree we’re going to try, we agree we’re going to use experiments to adopt new things; we’re going to use experiments to look at architectural decisions and design decisions, technology choice, Stack choices – that sort of thing. Then, we’re going to go through the practices in stage one and make sure we’ve got that covered and if we don’t, then that’s where we start; get the safety and hygiene practices done first. As Jared mentioned before, it’s like first teaching surgeons to wash their hands and scrub really well; you got to get the basics down first.

So we give them a list of – here’s how to start, get that going and then once you get through the first stage, we’ve got practices listed by role and by stage so you can look at them both ways. Once you get through base level thing, then we get up into a checklist driven development, we call it. This is still fairly novice-y; it’s a formula, it’s not a recipe and the difference being the formula’s very exact. These are checklists – do this, do that, do this other thing. Once you get past that stage, then you get up into more recipes where it’s like ‘cook until done’. That’s my favorite expression; the difference between a formula and a recipe. A recipe says ‘cook until done’ – well, what does ‘done’ mean?

My wife had on a corn muffin recipe some years ago and said, “Stick it in the oven at about 325 and cook until done.” And I’m like, “What the hell?” As a novice at this, I have no idea. As someone with experience, because that’s what makes the difference, experience knows it smells a certain way; you can stick a knife in and it comes out clean, whatever the metrics are. You know what ‘done’ means in that context but as a novice, I don’t know.

So by the time that you get to our level three, that’s what we would consider a modern shop using thing similar to XP practices, Scrum practices – the typical stuff you would see. Then we move on to stage four where you can start doing more customizations saying, “Okay, now let’s really tweak this and make this better and better.” Then you get up to stage five, the expert stage where you begin teaching – inventing new things that we haven’t seen yet replicating your successes. This is, again, where we sort of fallen down on the job. At best, we have really great teams out there doing the Agile practices and being Agile as it has been envisioned for the last decade and a half, but where’s the new stuff? How many new practices have really been adopted by the community in the last 15 years? One, two – a small handful at best. I’m certain we can do better than that. So that’s the kind of thing we want to try to grow people toward and get into these higher level stages and actually try and move the industry forward more than we have so far.

And Charles, your question earlier about what are they looking for in the big companies, what are they looking for in the enterprise brings us back to Andy’s recipe metaphor. A great chef is not going to use your Betty Crocker box they're not going to be using the recipe but there are still a lot of people using recipes. McDonald’s uses recipes. Any mass produced, big chain restaurant has recipes because they want a consistent product and they're willing to sacrifice the creativity and the quality that you're going to get at a Ruth’s Chris or some nice, high-end restaurant. In a startup, you get very, very smart people, you get out of their way, and you hope some level of creativity is infused into the product, is infused into what they're doing and they come out with something really great.

Maybe a large insurance company doesn’t want something innovative and original and great; they want a lot of stage three, follow the recipe, turn out the same sort of thing; they're willing to give up that performance. I think a lot of the executives wants you to welcome through the Dreyfus model and say, “Look, this is where we’re starting, this is why we need steps. Here’s where you need the freedom.”

I’ve talked to some folks that have gotten to look at this and say, “What percentage of my team should be stage four and five versus stage three?” So it’s interesting; the big enterprise companies want predictability and quite often, they're willing to give up innovation or speed to get that predictability. So understanding that lets a developer make a better decision about the type of shop they want to be in. I tell people the Dreyfus model helps me deal with my mom.

When someone is at the stage four and stage five and you're trying to teach them principles, and you have someone at stage one, two and three who needs a recipe, who needs steps, they're asking you for help. You walk in to the great chef and say, “How do I make a cake?” and you’ve got this, “Oh, just dash of this and a dash of that –,” you getting really [inaudible]; you're like ‘how many teaspoons? [Chuckles]

You don’t understand, that leads to frustration and once you understand, they need steps but I don’t or vice versa. For me, it makes it a lot easier to communicate and understand why people are getting frustrated dealing with each other and that leads to the development shop stratifying, all your stage four and stage five. People pocket off to the side. All your stage one, two and three’s pocket off to the side. It’s a really bad situation that’s easy to alleviate if you understand about the Dreyfus model and how the friction can come out of trying to get those layers to interact without understanding why they're butting heads. Wandered way off the trail with that one, sorry.

[Chuckles] I was on the roll.

No, it’s all good. Alright, so the next question I have is I’m kind of in limbo with my role with the development team that I work in because at this point, we’re building stuff for my business; we’re not building stuff for clients as much anymore. Some of the stuff may eventually get published so that other users are going to use it. For the most part, they're building software that I’m going to use and I’ve hired a few people to help me do that.

So you are the evil management in this scenario [crosstalk] just to clarify. Okay. Just checking.

I also sometimes jump in and write code because stuff has to get done and then were out of time. Sometimes I’m just like ‘you know what, I want to work on it’ so I work on it. For the most part, I’m on the area of vision and keeping things moving along as opposed to actually writing the code and getting the work done.

On a team of one or two people where one person is the visionary or it looks like this role is the executive in GROWS versus somebody that’s on the development team that – as a developer, can you do GROWS on a team of two or three people?

It’s a role, not a job title. It’s not an HR. Andy and I have bounced back and forth on this one quite a bit. It’s not an HR job title; it’s a role. Someone has to fill the role of the executive and it sounds like in this position it would be you. Someone has to provide the vision. Someone has to proxy at customer information but that’s a role somebody fills, not an HR hiring slot.

In a small startup, lots of people fill several roles. In a large enterprise, you might fill half a role [inaudible] that junk there but it’s a role, not a job title. Does that [crosstalk] make sense?

Yup, that makes sense. But is this something then that I can implement if I’m filling all the roles or a

lot of the roles? Am I going to create more overhead by doing that, then I’m going to solve problems?

I’d like to think you're going to solve some problems. On the one hand, you’ve looked at it so you tell me. What do you think?

Yeah, I’m just looking at stage one. We do some of these things well and some of these things really not well. I think a lot of these principles really would save me more trouble than I would spend implementing them. I’d have to say that it does look this way.

So say you're company does really well, you're a runaway success and you have to hire ten times more people tomorrow. Is it going to be easier to put those foundations in place later?

No. Heck no. [Laughter] Quite asking me questions that I already know the answers to that I don’t want to say, “Okay, I’ll do it. I’ll just do it.”

A very wise man I know named Andy Hunt likes to say when you're building a house and the foundations’ cracked, you don’t built the house anyway and fix the foundation later. You stop building the house and you fix the foundation. If you don’t do it on day one, you won’t.

LDS temple, the Mormon temple in Salt Lake City, when they were building it – I’m not going to go into all the history but initially, they were building – it’s a granite temple and they were building the foundation out of sandstone. The mortar cracked and got crushed. As it settled, the larger pieces of stone actually cracked. So yeah, they had spent five years building that foundation and they had to dig it all up and start over but they knew that there was no way that they could build a granite temple on top of a sandstone foundation if the main pieces were all cracked.

So they did; it was five years worth of work, they had a ton invested in it, they pulled it all out and they put in the granite foundation.

ANDY Kudos to them for recognizing that and for actually doing that because Henry Ford had that great quote about sunk cost or sunk and that is, psychologically, something is very hard for us to come to terms with. You see this all the time; he was like, “Well, you have to use this big expense, a quarter million-dollar product for tracking our requirements because we spent a quarter million dollars on it therefore you must use it.” Even if it is actively hurting development and actually hurting their ability to get code out the door, they don’t buy into the idea that yes, it’s a sunk cost. It’s done; it’s gone. You're crying over spilled milk now. Get rid of it, move on. Do what you need to do.

Again, we’re up against the fight between common sense and the way our brains are wired which really don’t work well with common sense. I always love to look at the page on Wikipedia that shows the common cognitive fallacies that we experience. The common bugs in our system, bugs in our thinking, they list ninety – over ninety of them on a Wikipedia page and those are just the common bugs. I’ll accept people’s got far more than that but – a lot of stuff looks like common sense. I’m looking right here on the core concepts and one of the first things we have is one thing at a time.

From a process point of view, if you're changing – you want to adopt a new process, you want to do something different, you don’t throw out everything you're doing and do all new the very next day. We’ve all heard horror stories of people trying to adopt XP this way or Scrum this way and saying, "Alright, we’re throwing out everything and starting tomorrow, everything’s brand new and all different.” What happens? Cue the audio, cue the screeching tires and then slam into the wall. It doesn’t work out well. [Crosstalk]

Yup. Everybody’s like, “Well, what are the rules for XP? What are the rules for this? How do we do that? Yeah, nothing gets done.”

ANDY It’s too much. So you do one thing at a time. The thing is we know that already because that’s what you do or should do when you're debugging code. You go and change fifteen different things and then compile it and hope for the best?

Not if you're good. [Chuckles]

ANDY You don’t. You don’t do that, right? You change – because then you don’t know which one actually work. You change one thing, see what happens. Change one other thing, see what happens. That’s just discipline and it’s the same thing here; we do that in code, we know that’s common sense. We should do the same thing with process. And if we’re doing it, if we’re doing process because the XP book told us to or the Scrum book or the GROWS book or whoever told us to do this and it’s not working. It’s hurting us. It’s hurting our ability to get software out the door than A, we’re doing it wrong or it’s not appropriate to our context, to the skills that we have on the team, the sort of work that we’re doing. Whatever our context is, this is not working for us so for God’s sake, stop doing it. [Chuckles] “Find something better, find something that does work.

One other question I have about the stages just looking at this is let’s say that I’m really good on version control and continuous integration, we’re working on time boxing. We’ve got the team-wide interruption protocols done. We’ve got a pretty good hand along everything else. Can we start working on stage two while we’re still finishing off some of the things in stage one?

ANDY Yes, sort of. It’s a really good question and we don’t have a really polished, formal answer for that because again, context is king. It sort of depends. For many of the things at the lower levels, they're fairly critical and if you don’t have them done right, it’s just going to bite you if you try to go up beyond that. If you’ve got the basics down and you're just polishing it and tuning it a little, that’s probably okay. You can probably start looking ahead and doing the next bit but you don’t want to skip over something major on a lower level just because it’s hard or because for whatever reasons it might be.

For instance, we’ve got – we split out practices for different roles beyond just the development team, of course. We have practices for the executives. This is what we expect from you and here’s what we’ll give you in return. We have practices for users. If we’re going to work with you as a user to build a software, here’s the practices for you. This outline’s what we expect you to do, what we’ll give you in return and how we expect to work together because fundamentally, I think one of the things we tend to forget is that the methodology is just a way of working together. There’s no magic to it, there’s no magic bullet; it’s a way to get us feeble, limited humans working together slightly more efficiently than just throwing around throwing stones at each other which is a default.

Also just to reiterate, if you look at the stage one practices, use version control, continuous integration implying you have a script to build your product – these are very basic things that a lot of the teams do skip over.

There’s a TV show a few years ago called The Unit. I love that show. Bunch of crazy soldiers and these guys are really good, world-class. They're doing a sniping mission and they're breaking the standard sniping rules. The guy looks at his boss and the sergeant and says, “But that’s against sniper doctrine?” He said, “Yes, but we know the doctrine and we’re breaking the rules intentionally. That strategy – you break them accidentally and you're dead.”

I would say that applies to the level ones. If you skip them because they're inconvenient, you're now backing Scum-but. You're back doing for Agile. If you sit down and look at it and say, “Okay, we’re not doing a time box because of this reason or that reason. You understand the principles behind it and you're making an intelligent, informed decision after having spent a rather serious amount of time doing time boxes then it’s okay. But 99% of them teams that skip time boxing are not doing it because I’ve never done it before therefore it can’t be done on these products; our stories can’t be broken done that far. It’s just impossible.

Have you ever done it? No. have you ever tried it? Not really. I looked at it and decided I couldn’t do it. While Andy’s right – it does depend – most of the times I’m going to hold someone’s feet to the fire and say I want you doing all these level one practices first [crosstalk], a long way to say it depends.

So I’ve gotten a little overexcited and asked a whole bunch of questions. Jaim, do you have more questions.

Well I’d like to know how do you see GROWS expanding?

I’ll tell you the quote I like that I stole from Andy, again. If GROWS looks like this in five years, we fail. GROWS is intended to be modified by the community, to be voted upon by the community for these practices; to be added to, edited and expanded. Right now, it’s Dave and Jared’s view of the world. With significant feedback from some very smart people. Tony Brill’s had a lot of insight; a lot of our beta users have had a lot of input into this but as it grows, the people that become more involved – this lives in the Git repository – it’s not going to be just us. If it doesn’t grow and evolve, we’ve done a poor job.

Alright, how long are you – if I google GROWS won’t work here will I find anything? [Chuckles]

ANDY You could write it. [Chuckles]

I’ll try it. By a one-man company, GROWS won’t work here.

ANDY To be fair, we actually – we do have a section like that. If you look on – let me see if I can find it – if you look at the skills model, traditionally, the skills model goes in five stages for Dreyfus and we start with safety and hygiene as the first level. But I put – there’s a stage zero underneath that which we say is you’re not ready yet. So in order to try GROWS, you have to have a certain level of open-minded commitment and a willingness to experiment with this sort of thing. If you don’t have that then none of this will ever work for you. Don’t even try. Don’t even start. If you can’t get people to agree that they want to try this, if you’ve got people who are excessively territorial, inflexible, uncomfortable with uncertainty, treat all developers as commodity widgets – I need Java programmers for this; would you like a nine pax or a six pax and what sauce do you want with that sir? No that’s not going to work in that environment. One thing I’d like to think is we’re pretty upfront about that. If you're not willing to actually work with this and give it a shot and grow, then don’t try.

Do something else.

Now you have to come back for the ‘how do you skunk-works this into the company’ episode.

ANDY Start your own.

Let me ask you a question; how many times and how many companies have you seen an Agile adoption that was skunk-worked in that was this team, that team, the other team and suddenly all the development teams are doing this but you’ve got no executive buy-in, you’ve got no managers on-board with it and they let you run with it until something happens, something stumbles, the project is late and suddenly it whiplashes back, management steps in with an iron hand, kicks out Agile; it’s now no longer welcome here. And maybe if you bring anything similar back, you're going to have to call it Lean or Kanban.

But one of the things – again, level zero is you don’t have anyone filling the executive role. If you're not able to get that buy-in, you can get a lot of benefit out of these practices, you really can, you can work at the team level. You only have team buy-in only use team practices. You don’t have team buy-in, use the individual practices. You will be better for it, you will become a leader, you will be better at what you do. But if you really want this to succeed, it needs to go to the top. If you can’t get the executives on-board with this, it will not be a long-term success.

ANDY That’s absolutely true and that’s why we really felt it important to make this more inclusive than a lot of the traditional Agile methodologies have been, recognizing that this is a way for all of us to work together, us being everyone from the executives to the users to all the development – everyone. Whoever’s got a hand in this, we’ve got to figure out how to work well with each other and serve each other’s needs. The executives have needs that need to be met; they need to know some traceability and visibility into the process and we don’t want them micromanaging the small details so let’s give them what they need in a way that works for them and try and make everyone happy.

You hit on another good point Andy. If you don’t give management something to let them fill – it’s their job to manage the work and have some understanding of when it’s coming down the pipe. If you don’t give them a way to do that, they're going to get really creative in what they ask for and how they “help” you.

So one of the things we push really hard in here is burn up because a burn up chart shows you what’s been committed to and lets you see that commitment level when executives and sales spoke at clever ideas, how the commitment for the release client’s just as fast as the development completion rate is climbing. There’s all sorts of interesting insights but if you don’t give them something useful and actionable, they're going to come up with something all on their own that you won’t like. Fill that need. Get ahead of the problem.

ANDY I think their heads just exploded. [Laughter]

I’m just trying to think about what else we can dig into here but we’ve already been talking for an hour. This show usually doesn’t go this long.

Well if you like GROWS, it’s free to use. If you want to call yourself a GROWS consultant, we’ll end up changing some coin for that but we’re still ironing out that program, but if you just want to take it and use it, download it, print it – go crazy.

Yeah, I’m going to be spending some time on here because I definitely see it solving some problems for me.

ANDY In a very meta sense, too, we say that everything’s an experiment. When you're trying these things as an experiment, GROWS itself is an experiment. We’re trying this. We’re getting feedback. We’ve made changes already, we will continue to make changes based on feedback. It’s not static. The whole point of being Agile is that it’s dynamic development, not static development and the same should be said of the methodology. This is not static. We will fix it, change it, evolve it. As development changes, as developers change, think of just – leave it as a closing/parting note here; think about the way development was done twenty years ago.

Think about the way products were done twenty years ago. Shrink wrap CDs, long release cycles – all these kinds of things versus how many times have you updated apps on your phone today. It’s a different world. It’s a very different world. Why are we using the same techniques we used twenty years ago? That doesn’t make sense. So this is our excuse to say let’s let the cat out of the bag a bit here. Let’s try some new things, see what works, go from there.

So can I become certified GROWS master? [Laughter] ANDY No, you may not.

Oh, c’mon.

It’s a two-day class and if you fail the tests, you’ll still get the certificate. Yeah, just send us a check. [Laughter]

ANDY I’m seriously considering making a certificate that has – in big letters with cherubs on the sides and big old English letters and it says ‘this is a certified, original piece of paper’.

Oh there you go.

Perfect.

ANDY [Inaudible] right? No, we don’t want to do anything like that. Ultimately, I would love to do some kind of community karma voting system. You say your team is great? I don’t really care what your users say about you.

Yeah.

ANDY You’re management says they're great? Well what does the team say about them? What do they say about the team? That’s – I would be much more interested in that than, as you say, take this course for two days and get a certified piece of paper. That doesn’t tell me anything. If you’ve got a reputation in the community, if you have a reputation in the company, that’s valuable. That counts for something. That counts toward showing that in this organization, these folks have learned how to work with each other. They’ve learned how to work together and are happy with it. That’s valuable; I’d like to give them points and kudos for that. Anything else is just a piece of paper.

Alright. Let’s go ahead and start wrapping up. Now with these shows, I’m going to do something a little bit – I’m going to start doing something a little bit different right before the picks and instead of doing silver sponsors which is something that I’ve done on the other shows because I’ve had them filled out on the show, I’m actually going to call out briefly about some of the online conferences I have coming up.

To this audience in particular, the next two that are coming up that are going to be interesting are in the end of February, we have a Freelancer Remote Conf. so if you’re a freelancer, go check that out. And then in April we’re going to do an iOS Remote Conf. so if you want to go submit calls for proposals, you could do that right now. It’s only up on allremoteconfs.com and then you can scroll down and find it. I am eventually going to plug in some domain. I think I own iOSRemoteConf.com or something and then you could just – it’ll redirect you to the right place.

Anyway, if you want to submit talks, you can. If you want to buy tickets, you can so go check it out. I’m also selling season passes and three pax, six pax and nine pax because I’m doing a conference every month next year. We’re going to be covering some of the stuff we talked about here like Git and Postgres and stuff like that. We should probably have one on process or development or Agile or something but anyway, that’ll be next year I guess or the year after next. Anyway, I’m just going to shout-out to that go check it out, see what you like and shoot me an email. Let me know what you think.

Let’s go ahead and get to the picks. Jaim, do you have some picks for us?

Yeah, I’ve got one pick today. Most of you probably don’t know who Dan Wilson is but he’s a song writer, and you definitely know some of the songs he have written. I’m not going to go into him but he was big twenty years ago and he’s writing a lot of hit songs now. But he’s got a vine for the past – I’m not sure how long – six seconds where he gives tips on song writing and he’s been collaborating with Adele and a lot of people you’ve heard of. He’d [inaudible] listen to but he’s doing a good job.

One thing in particular, he gives six ground rules for collaboration so if you're thinking he’s a musician, that doesn’t really matter to what we do, he should stand with big rock starts to write songs with them which is a bit like what we do everyday as developers. We collaborate, we do things, we sit down at people with sometimes little big egos and we had to get stuff done. He’s got a list of the things and he’s got six ground rules for collaboration. If you know vine, that’ll take you 36 seconds to get through so good use of your time.

For example, number five – propose alternate ideas. To make a bad idea go away, replace it with a good one. So if you're working with people, don’t tell them no. give them a better idea. That’s my pick for today.

I like it. And it really applies to what we’re talking about so bonus points I guess. I got a couple of picks. One of the things that I am going to be doing again, I did this for a while and then we had a baby and stuff and I got off-track but I’m going to start doing Periscopes again in the morning. So if you want to be on Twitter about 9:30AM mountain time, I’ll be on and I’ll be talking. And I kind of wanted something that would work a little bit better than what I was doing because I kind of point the phone at me and I have to finagle it to get it to work.

So I actually bought a mount for my tripod that has some microphones on it and it pipes the sound into my phone so now I can just set it up in the same pace all the time and stand in the same place and you can see me talk to you. It’s a Saramonic sound mixer or smart mixer that cost me about a

hundred bucks on Amazon. It comes with the tripod mount screw hole and everything else so I’m just going to go ahead and pick that.

I actually did a Periscope where I unboxed it earlier this week. So if you want to check that, you can. I’ll put a link to that on the show notes.

The other pick I have, and this is just something I’ve been playing with for my leisure time is Clash of Clans. So if you play Clash of Clans, you can find me on there. I’m cmaxw just like I am on Twitter so go check that out. Looking forward to playing online with you.

Andy, what are your picks?

ANDY I’m not sure if this counts as a pick but I find it interesting and it may be relevant. My friend Derek Sivers had a post about a month ago about what he calls the /now page movement where whatever your personal website is, you add a URL of ‘now’ to answer the question ‘what are you focused on?’ What’s most important to you? What is driving you right now? If you actually go to his website, it’s sivers.org – S-i-v-e-r-s – sivers.org/now3, he explains how he came up with it. You can actually go to the website nownownow.com – that’s the three nows – and it lists everyone who’s put a page together and submitted it to him.

Now before you go looking for mine, I have a clarification here; I haven’t set mine up yet. I have it in my head. It’s just a matter of setting it up and typing it in but I think it’s a really interesting notion because it’s an interesting question. What is it that you're most passionate about right now? Is it your hobby? Is it your album that you're trying to get out, that song you're trying to write, the novel you're trying to write? Is it a piece of software? Is it chainsaw carving a bear cub from a log? Whatever it might be, it’s an interesting thing to ponder because once you publish that, once you’ve put that out there to the world, there’s some power to that. There’s a bit of public commitment to that. This is what I’m into now, this is my most passionate subject. This is what’s important to me.

Of course, it’s your page. You can change it, do whatever you want but it’s just that exercise of trying to consider what is important to you right now is very valuable. So kudos to Derek for that and for sharing that with us.

Alright. That sounds really cool. I’ll have to do that as well. Jared, what are your picks?

You guys are so much cooler than me, I don’t know. [Chuckles] We have a lot of people in our group that use Macs. The laptops are great but the desktop’s a little overpriced. I love – I just said it in the Skype window there – tonymacx86.com. Don’t try to make it run on an AMD; get an Intel set up because it’s very similar to what Mac is using these days but my home desktop is a nice Macintosh with 16 gigs of ram, a couple of monitors. Fun to play with.

The same pick I had the last time we talked – jeeps. Get out from infront of the computer. Don’t go buy a brand new jeep. They're overpriced and they’ve got tons of problems the last year or two. You saw that guy that went viral out of Australia about a lemon, he was talking about a jeep, that’s great. Go buy an old one. I spent this weekend with – my daughter’s a little older than your kids. She’s 17 now. We spent the weekend ripping the jeeps out of her – the seats out of her jeep. She just bought herself a wrangler, stripping it down to the metal, spraying it down with a rubberized [inaudible] and putting the whole thing back together again.

Go do something else and when you come back you’ll find you're a lot more refreshed and creative. I like to tear things apart. Andy like to make music. Everyone has a different hobby then get out from behind the keyboard on a regular basis and I think you’ll find you’ll be a lot more effective when you come back to it.

I am so waiting for the Jaim and Andy jam session now. [Chuckles]

I’m grabbing my axe. Let’s go. [Chuckles]

ANDY Excellent. I play trumpet and flugelhorn in the [inaudible] cover band so yeah, we’ll get it together already.

Alright. We’ll fire up [inaudible].

So if people want to see what the two of you have going on, what should they do? Where should they go? Not just GROWS method but anything else you’re working up to.

I’m at agileartisans.com and Jared Richardson on Twitter.

Okay.

ANDY My personal pages are toolshed.com. I’m @pragmaticandy on Twitter and of course our – Dame and mine’s publishing business is at pragprog.com. The GROWS method is at growsmethod.com – all pretty straight forward. And there’s always Google.

Awesome. Well thanks again for coming. This has been really fun to talk about and hopefully people are getting some ideas about how they can make things better in their team and their software practices and the way that they do things in general.

ANDY Alright. Thanks for having us.

Enjoyed it.