So, can you tell us a bit about yourself, and what you're working on?

A lot of times when people ask me who I am, I say Agile geek-a-large. I started off my life as a musician and I did a lot of work in a recording studio before I started working in software. And I think that kind of prepped me to get into the Agile space. So who am I right now, mostly what I do is Agile coaching and training but I also practice all the Agile techniques when I'm coding, that's my full time gig right now. My background is various languages: assembly, C, C++, Travis, C sharp, whatever language du jour, the space is all about, just a few languages is like things that get in the way of delivering solutions some of them are less cumbersone than others. I'm not necessarily a super-go-faster coder guy, I definitely follow the pragmatic programmer space where I think it's pretty important to keep saying "why are we doing this again?" But not in a way that's pretentious, to say "my question is the smartest question", more in a way so you and I can work together and make good decisions, and pragmatic decisions, about development costs and complexity.

You mentioned "super-go-faster." Where does that come from?

Yes, that's actually my company "Super Go Faster" - SGF. The people that might be scared by the name, Super Go Faster, probably also might be scared maybe by "Extreme Programming". It comes from my background as a musician, I went to buy an instrument one time and someone told me if I bought this guitar I would play faster; and I do. It's a little bit of a joke in the industry, my partners and I chose it because we think that so many things we do, have to do with trying to be "go-faster". We come up with a new technical solution and we think "oh this is the bomb, I'm going to do this, it's going to allow us to code faster", and sometimes in lieu of wanting to be super-go-faster, we actually go slower. Other times we actually do go faster, you know: you and I get together and we do something very simple, or we use some open source space, and so a little bit of a poke in our industry but also a compliment at the same time.

So how do you sell Agile methodology within the company?

That's a question I was asked a lot; i sell it as anyone that's out there doing this kind of coaching. Today at No Fluff Just Stuff, someone asked "how do you sell it?" and I said "what is IT?" I think sometimes they think it's like a can of soda, and I'm just trying to get you to buy it. And in truth it's not like that, it's not a recipe, it's not really a thing, it's a collection of things and you have to say "what's my organization about? Why do we want to do this Agile stuff? What are mapping our motivations to the practices or the principles that we chose, that are going to not collide with our company?" Much the same way that you would, when trying to use a design pattern, just jamming it in 'cause it's cool (or go-faster), kind of putting it in to say "well I'm working on this problem, hmm it seems that it's matching this motivation for using this pattern, I think I'll see if this pattern works". So one of the things I always want to do is understand my audience: why do they want to do this? And I'll go in and talk to them and sit down and say "what are the things you're trying to solve? What parts of Agile do you want to use?" and listen for their words, how do they talk about their problems to see if there's a straight corollary to Agile or if there's kind of a thesaurus-like translation, like "they call it this, Agile calls it this", to try and kind of speak their language, I think that's something, that sometimes in transition to Agile there's a reaction to it that's negative, because someone thinks it's not what they do and indeed it's exactly what they do or possibly even on their company's little badge, about values and how we work together and things.

What are some of the culture shock that a manager might go through when the team demands Agile and how can the team ease his fears?

I think if you go all the way back to like the early Agile movement, I think some messages went out a little bit, and not to lay blame at anyone's feet because it IS a movement, there's a lot of really passionate people excited, saying: "we want to do things differently now, we want to be better, we want to deliver, we want to meet our promises, we want there to be good quality", and a group of people kind of took the reins and did that. And somewhere some message came out like "we don't need managers, we don't need testers". I'm not sure those people even said that, but somehow this myth kind of gathered around that. So for me, a lot of that is going in and doing some myth-busting with these mangers, to make sure they don't feel ostracized, to make sure that they're part of a larger community, and engage them and say "what are the things they have to do," because they have to report to someone. What are their wants? What metrics are generated by an Agile project, 'cause so many things come out, whether it's metrics around risk or quality or progress, that plug right into their world. And if you say "Oh I don't want to go play in the PMI space" then you throw out all things good about Agile, because you just offend someone overtly.

That was a good answer, but more specifically how can a team address a manager's concerns?

Try and understand what they want. That's where I was kind of going with that one. What does a manager need? Try and make sure that they know how they could be a part of the team, and that when you say "the team" it doesn't mean just the developers. Who is the person that connects to the manager, what do they do? Because I think sometimes managers get these messages from Agile teams: "well I'm just here to count beans" and that's not really true. Being able to post things like technical debt in a common workspace or somewhere, so the managers knows the things that are blocking the team, is a great way to enlist them, to get them involved, because those are quite possibly things a team has nothing to do on, or can't really solve. I also think that making sure that what's being measured speaks to the needs of the manager. And actually having a plan, there's nothing about Agile that says "you can't have a plan". You don't want to live and die by the plan, so you need to do continuous planning, but another myth that came out, I think early (and again not to the people that started these movements), is that Agile doesn't have a plan and that offends the managers 'cause that's what they're trained in and incented in to solve.

So planning in Agile: some people think that's an oxymoron. How does planning work in Agile methodology?

Again, that's kind of a sad myth. I think one of the big differences in the Agile space is that, as opposed to starting out a long mission together, a journey together, as a group of people and saying "This is our plan. How are we doing? How are we doing?" The Agile space forces you to say "Here's how we're doing. How are we going to change the plan? Do we need to change the plan?" To the whole notion of change management, it's also not mutually exclusive of doing Agile, but you're almost always doing change management, you're always talking about: we try to get these things done and if we didn't get them done, what are we going to do to try and get them done next time?" Because we need to get better. So it doesn't wash away the notion of, like, here's 5 million dollars and a bunch of people, when do you think you're going to have that done? What it does do is give you points along the plan and a lot more points to say "we're on track, we're on track, we're not on track", and as soon as we go off track it's a small variation, so we can assess why we went off track, you know, which could be the myriad of things that exist on many projects. Many of which are shut down in the Agile space because it's such a high level of testing, so quality is less of an issue but you still have possibility of requirements changing, which is supported by many of the Agile practices. But that doesn't mean someone need to account for or communicate it outside of the core of developers, as to how it changes the plan. It's like the Eisenhower quote, "Plans are useless, planning is essential." I can only imagine what it was like to try to plan D-day. I'm sure everything changed after the first ten minutes, or an hour at least.

So what does a plan look like? Is there a specific format to it or is it whatever the team needs?

I think it's very much cultural and corporate based, like "what are their needs?" So to the manager question again: If the manager needs something specific we might end up translating it back into their needs. For me the plan is like a combination of things where you get everyone to gather and you do some kind of a chartering: "Who are we? How are we going to work together? What roles do we all play in the project? What are the goals for this project, mapped to the success measures?" And then go through some initial exercise of creating a body of story titles that we feel like we have the product owners, the customers, or maybe the subject matter experts in the room, and we come up with maybe 80 % of the project. Some chunk where we feel like "this is a lot of what this thing is". And then we toss it into some plan, in buckets, buckets in the form of releases, maybe a month or two worth of work, or a week or two worth of work, some delineation that make sense based on the history of the players involved in the planning. And I don't think it's ok to give a prescriptive answer, because I think a lot of the Agile stuff is more descriptive, and that's why it works. So if you have a core of people that say "you know we know this space, we've built this before", they actually might be able to do some high level estimates that are meaningful. But you might have people that really don't know that, so you really just initially prioritizing based on the business needs, but you are trying to do some prioritization: I would like this, before this; and bucket it over time, time based on that initial line in the sand that someone drew and associate it a bunch of money with. So you can say consistently "How's that money being spent? Are we getting there? Are we getting there?

How does deadline setting and expectation setting around deadlines, work in the Agile way?

I don't know, again, if there's like a magic one that says "oh, we're doing Agile now so we can tell you where we're going to be with these 20 people working their hearts and souls out in three years". In fact, I would just say I don't think that's very realistic. My experience is the longer the time and the larger the budget the less likely you're going to be able to kind of get even close to trying to plan. Maybe those are the sentences that started some of these myths! This doesn't mean you don't take a swing at it, that doesn't mean you don't put something down. I like to plan 3 to 6 months out, the further I get from today though, the more I know that's probably not accurate. But what I do see when I do that, trying to do that long range planning, is the things that are risky, the things that are expensive, are known to everyone, to the managers, to the stakeholders, to the architects, so that you can say "let's move that up front, let's make an investment and kind of try to understand the costs around that, the risks around that, because we could do a small investment, a spike-ish thing, without saying "Well, we'll just move this out, we won't worry about that for 3 months" and I think to project management, that's really true risk assessment, and it's not one person's fears driving it, it's a collective, and those meetings can be done pretty efficiently with a small group of people.

So you mentioned 'user stories'. What are 'user stories' and what are their role in the process?

So that's a pretty big topic, we can talk about that for hours and hours. I get asked that a lot: "What are user stories? How big are user stories? Who writes user stories? When do they come in?" and I think, like a lot of things in the Agile space, there's not exactly any one size, or any one person that writes them, nor is there any one way that everybody uses user stories. I think that's why sometimes we struggle with using use cases, because we think there's just the one use case template and everybody should use it. And in truth, the people that effectively do use use cases realize that it's different, in different organizations.

So for me, sometimes user stories, when you're doing that high level planning that we were just talking about, are vehicles to talk about the values of the product, and break the product into chunks, and I think that's one of the aspects of Scrum I really like, because people are talking about a product. When you get closer to an iteration where we're actually going to try to build it, the story moves from being a statement of value as well as that, or maybe it morphs into also something that also says, "it's a unit work, it's something that we can get done predictively", and that decomposition is very similar to how people might effectively use use cases, if you go find the places where they are doing that, or any kind of informal requirements gathering.

Another really important aspect of a story, the story tells the needs of someone, and the word that's important in that sentence is 'tells'. Stories have to be told, they have to be shared, there's a strong verbal aspect of Agile that says "don't try and put everything in prose, don't try and write every little thing," because lot of people that I meet that are in the analyst space, the customer space, the product space, they're quite frankly kind of fearful of developers, because developers are pretty sharp people, they break problems down, their whole gig is functional decomposition, and these analysts have years of experience and they're saying "I have 3 months to write this document, and give it to you, and no matter what I do it's not going to be enough, I might be blamed for the project failing because the requirements weren't clear".

The Agile community says "write to the point where you can have a discussion. Organize your thoughts, break down your stories into themes, into some kind of buckets that make sense, and then bring them into a format." Bring in whatever you need, if you have other existing documentation that helps to talk about it, but don't drag that in as a vehicle to develop software. Have the story be the vehicle and share the story and modify it as you need to. One of the good things about the Agile space is you can actually take a story and rip it up, because there's not sacred. Sometimes when people spend months writing a document, they're less likely just delete it and say "I'll start again." So that's another aspect of stories, they speak to someone's needs, but they're not this sacred text, they're more fluid. And that's why I think the "Story", the guys that have come up with this chose a really good name, it says use your story, it's verbal, it's kind of like that's how things are shared, in communities that're more based on language than are on written history.

So you mentioned a few times that user stories should fit on half of piece of paper, so what would be the example of what a story would look like? How is it different from a use case?

If there's notion of what a use case exactly was, that would be an easier question to answer. Because in my history with use cases some are 40 pages and some are 1. And clearly the ones that are one page are much easier to work with than the ones that are 40 pages. For I guess someone with 40 pages thing, I'm going to break it down in some way, because I just can't live like that, it blows my mind out, not because I'm a weak developer, just because I want to try and deliver something to someone, and always have. The smaller use case, if it's down to like a page or two, and it doesn't have the kitchen sink in it, doesn't have like business logic, data modeling, user interface design, business rules, all sorts of things in there, if it's really focused to say "here's an actor playing this role and here's their wants", then I think stories kind of get closer to use cases, but a big difference between stories and use cases is the story has two parts on the front side of this 3x5 card, and one part is the story and the other part is the story tests, so the notion of what we're going to talk about, to discuss the features, the story, to try and understand what I want you to build for me, and when it's done, are not a disconnected conversation. And that's one of the healthiest aspects of user stories, that I talk to you about it and then I say "oh, these are the story tests, these are the reasons that make it valuable, these are the reasons that satisfy the user's needs" - whether they're happy tests or unhappy alternatives, in use-case-speak.

So what does a user story test look like? How does it translat into code?

A simple vehicle that I use to discuss them a lot is: retail software. So you're building a purchase order system, and one of the things you need to do in the system is: in order to sell things, you have to be able to add them to the purchase, or add them to a sale at some point, scan, scan, scan, maybe type in a SKU, and that could be a story. So the casher needs to add items to a sale so that the company can make money. So you can like sell goods.

A test might be, you know, "Show that she can add something to a sale with no items," "Show that she can add something to a sale with existing items," have a test that says "What happens when she tries to add something and it doesn't exist in the system," some unhappy path, that's a really good combination, that's what I do with people when I'm kind of coaching them around writing stories, it's like don't get wrapped if you don't know exactly what the story is, don't feel kind of in that paralysis, like "Oh my God, the story has to be right," just kind of keep jamming through story titles. ... Having a music background, what I use a lot is to say, for musicians, especially if they're rock 'n rollers: "Sit down and play a song and at first it sounds like a rock tumbler and it's kind of bad, but they keep hacking their way through it, and because they don't stop and say 'oh no, in the next measure you play this, and you play this,' and then they play a measure and stop again, they just kind of keep rolling through it, the jam, the groove, kind of presents itself.

When people do that with stories, especially with like 3x5 cards on a table, the product owners, the customers can kind of generate those faster. If they're having a hard time with a story I might say "well tell me when that one is done, when would that user be satisfied and then the story test can kind of come up as a way to help them understand: maybe they need to break the story in half, maybe the title is bad, maybe they need to rip it up and start again.

So how would a user story tests translate into testing code?

OK, so maybe a way to talk about that from a layer prospective is, somewhere underneath the presentation layer, there's a web service or if it's just a generic term of the use service, there's something that says "I need to be able to add items to this sale". You could use a framework like FIT, which is a really nice one to do that or you could just run it to unit test that says add one item, add 2 items, add an item that doesn't exist and validate it. The exception you get back is exactly what you think it should be, it has a message you can translate or whoever the consumer's responsibility is in the system.

So let's see in an organization, they've written some stories, they've written the tests, there seems to be understanding between the programmers and the business clients. What are the next steps to get going?

I didn't want to say that they had to write all the tests up to this point, they may just have written story titles and in scram terminology they kind of hydrated this product back log they have an idea of what this thing is. And I think today...for just a second, I think that's a really good part of the scram, is the term of the product and the product owner really drive home, that they were building things.

And one of the jokes I kept saying in no fluff, is we don't know what our product is, we name our projects after constellations, because that solves things, but when I come on to the O'Ryan project it's really often hard to write the users stories, because no one can name what the product is. So that's where I was going with the story tests to help that. So once you have an idea of what the product back log is, you kind of like talk about who you guys are as a community, and how you're going to work together, and what the project is, what the goals through this period of time are.

Then I think you need to go on to the next level of planning, which there's tons of books written about it by people that are much better writers then I am. And yet it still gets skipped over a lot and the expelling which that will be a release plan, without people being confused by the term of release meaning a public release being like: "so we got this persona writing these stories about, and here's a collection of stories that are meaningful to them". It's not just "I'm going to pick these ten of the wall and throw them on the table and what do you think?" It's kind of like "well these work together and this is why", so you have a goal for the release of the sprinter or whatever you call that larger psycho, and kind of go through and do those high level estimates. For me those are like one to 3 weeks, you know, small medium or large. Some way to give the business the ability to use their one to prioritize by value, by business value combined with some kind of sizing, some kind of cost or risk. Maybe you throw a story out there and all the technologists in the room give you that blank stare. You don't have to be, you know, an absolute stout or level 6 certification in any kind of methodology to know you have a little bit of a risk, you need to make an investment or reducing that risk. So that release plan is really important next step.

What else do you need to know to get going?

We talked about some foundational things like understanding the community, getting this story and this backlog in place, doing this release planning, but certainly before you say "ok we're going to start doing iterative development." I think traditionally the XP community called this iteration zero. Whatever you call it, making that initial investment to get some core things in place so you can hit the ground running is really important. And again there's lots of writing about this, but fundamental things for me now are setting up a continuous integration environment, making sure CVS or whatever source control system is in place, getting all the tools in place, getting all the work stations set up so that we're really not spending a lot of time trying to figure out the difference between your machine and my machine. I don't know if it's really fair for the customers to pay for that. They want us to build things, in many cases they're frustrated because we're not delivering things; that's one area we as technologists can solve. I like to do that in combination with a couple of users stories so you actually have to take a story, break it down, map it again so you see what your initial idea for architectures is, build it, check it in version control, have it checked out, rebuilt on an integration box, and then send a message to everyone; then you know you have some kind of life cycle in place, some kind of heartbeat.

You mentioned the word community a lot. Can you talk more about building a community within an organization?

I think part of that question for me is what's beyond the existing literature. There's some really sharp people that have written a lot of really good books about this, and whether it's tactical stuff like refactoring to patterns or whether it's the many books that Kent Beck out out, or Ken Schwaber, about how to do this stuff, I think that there's an aspect to it that really has to do with who owns the central idea of getting these people to work and play well together.

It sounds a little bit "hippy" sometimes but you know the XP community has this idea of a code, and the Scrum community might have this Scrum master who kind of owns it, but what I see when I go into an organization is: it's not always one of those people or the other. Sometimes it's like there's a self organizing equation in amongst the small community and they just come together and work together; other times that has to be nurtured; someone has to be there saying "how do we make sure that when we say "team" we don't just mean the people that write Java? How do we get to those managers, how do we get everyone, involved? How do we build that community?"

The reason I mention this is because the teams/communities that I've seen that are successful, they're the people that work together, they're the core of people that come together and they're bonded by a common goal. Not typically bonded by something like snacks and beers, more bounded like "look at this thing we built". When you talk to people, especially developers and you say "tell me about your favorite project" it just comes right out, and they're really jazzed: "one time I worked on this thing and bla bla bla..." they'll tell you all the things they did that were successful and you've just got to listen to them and write them down.

They did a bunch of unit testing, they had fun together, they gave each other weird names, they figured out a way to meet every so often. I think some of these early Agile movements said "these are the things that work, let's do those a lot". But I don't know if a lot of people understand that those collections of practices and principles are embodied in the community and they don't name the community, and so that's why I use that term. There's a bunch of different people bandying that around, like industrial logic (IXP), they have this notion of chartering a project, something that they borrowed from someone, but they also have this idea of the project community, naming it.

How do you build a sustainable Agile community?

I think you don't build it by focusing solely on the practices. And I love JUnit, NUnit, whatever-unit and I love test-driven and those are things that help me be sane as a developer. But I think that to make it sustainable you have to make sure it maps into the culture in which you're trying to do it.

If the organization is very command-and-control and you're doing it in this low-fi,covert fashion, it will probably will be squished out eventually. If you go in and say "you know in our company they use this word and they're very scared of this other word", then maybe you shouldn't use this. I'm not trying to put spin on it or dumb it down or something, but "pair programming" is something that happens successfully in tons of industries like in the medical industry, in the airline industry, and a lot of embedded programmers work together because it's just less expensive than to burn through hardware.

But somehow when we say pair programming there's all this baggage. I'm really careful about how I say that, if it's a hot button in an organization. But I do think the idea of spontaneously working together, pairing, is a really important aspect of software, and something that helps people succeed: like developers working with testers to automate story tests, or testers working with customers to help them write story tests or even flesh out a set of stories, because maybe the customers are just the product owners.

So all that said, I think that what makes it sustainable is staying connected to the values. The Agile manifesto says "collaboration over documentation". It doesn't mean you don't document, but it means if you started arguing about "well it was in the specs, it was in the story, didn't you read it?"; then you've lost that notion, you've decoupled from the values and the principles behind it, and you're just focusing probably only on the practices. So to roll it up, you have to map the process, the selection of Agile things that you put together, into the culture of the corporation, the community, the company, and say how are these things going to marry to one another and how can you get people to say "I want to do that", instead of saying "someone told me to do it". Because then it's just another edict that comes down from on high and people are not involved, they're not invested.

There's something in a lot of this Agile stuff, whether it's stand up meetings, Scrums or the retrospective, where everyone's asked to share and participate, and the notion of "I'm just a developer, don't ask me how I feel" kind of goes away. And I think that helps to draw out that stuff, draw out those values. But you have to do those, have someone championing them, you have to have someone getting people to talk, setting up a space where people feel free to say "I wrote that, it's stupid let's blow it up".

You mentioned that the community should involve all the stakeholders from developer up to the executive. What about executive? How do you involve it in the community? When do you talk to the executives?

I think it's important to get them involved certainly as soon as they want to be. I don't think it's a good idea to shelter these people. I also don't think it's a good idea to demonize these people. We call them "the suits" and that's kind of affectionate but it's also kind of slang sometimes. Last year at the XP conference in England someone named John Favarow did a really nice presentation where he gave the whole XP community a quiz on finance and strategy, everyone at the conference.

So the people that had background other than development knew some of the answers, some knew all the answers, but most people didn't do very well at the quiz. Then John gave us a quiz on XP which we all excelled at, then he went through and did a really nice presentation to say what are the goals of these people doing finance and strategy and what are the goals and motivations for XP or Agile in general? He showed us how close they were; what he really challenged all of us to do was this: "If you want to communicate with these people you have to speak their language". I've just said "these people" like they're this other world. I don't find them to be as evil as we may be talking about them sometimes.

I do think that there are some of them that are very critical, they want a real answer, they don't necessarily want to talk about JUnit but they care quite a bit about quality. And a lot of what I do in coaching is communicating that to them, is translation and figuring out what metrics makes sense. Most often it's one or 2 metrics that show consistently how healthy and how much of the project is being built, is enough information to say "yeah, thanks for doing things that way". They don't know if they're really up for like someone swinging the Agile hammer saying "look at us, look at us, we're Agile" because they think about many other things.

How do you deal with team members who don't like the Agile process and the daily meetings and that kind of accountability?

This is an interesting sentence: "How do you deal with them?" . I'm not sure what the embedded metaphor is, but I think anyone that doesn't like something, or has a reaction to it, what I want to know is: what's their experience. Is it the way I communicate it, is it threatening, is it something they just don't agree with, is it asking them to be very open and that's something that's very uncomfortable for them as an individual?

Do they not like it because they feel like that's going to take their power away and in truth it's going to give them actually more power, or allow them to influence others? So that's one of the things I always want to do, not just come in swinging the Agile hammer, but try and understand what people's wants are, what their needs are, what their reactions are. I think that goes a long way to getting people to say "I can do this, but I can't do this. I want to do this; I don't want to do this".

That said, there are people that don't work in community, there're people that don't want to work with others, they want to be that developer or that person off by themselves, maybe they're a manager who really doesn't care about the team. I think that what Agile shows you is the value that person adds and if all they do is show up and they are in negativity, I don't think it's a good idea to just keep people around and say "we'll work with them".

I don't think that's really changed by Agile, but I think it's really brought out into the open. You can't run away from that person who doesn't want to work and play with others; because, for instance if you have a developer who really doesn't want to communicate with everyone other through formal code, is it really better to have that person down in a corner just banging code a millions miles an hour? I think what the Agile community says is "Oh, let's talk about what's going on there, what are the costs in that space, is there a way to bring that person into our world? Why do they want to sit in the corner?"

What's going on in the Agile space that you're personally excited about, what's changing, what's new?

I think one of the things that's not necessarily new in the Agile space but surely does not get a lot of press yet, is the importance of automated story tests. Josh Kerievsky came up with this idea that he's calling "story test driven development", and a lot of us came to that at the same time. Forget that it's another name for something, it's the same kind of thing that's important about test driven development, with green bar, red bar, and JUnit and NUnit; but this time when I give you the story as the customer your first focus as the developer is to say: "I'm going to automate this story test.

I'm going to make sure that every time I tell you that's done and you sign off that story by using a working system, that I automate one of those tests for you, five of those tests. I'm going to start building that wall of automated story tests like that wall of automated unit tests, so the need for an army of 10,000 people doing regression testing against the story goes way down. You can test individual stories, and you can test a sequences of stories.

So one of the vehicles to do this it's called FIT created by Ward Cunningham and there's a wiki version called FitNesse created by the Object Mentor guys. And both of those are starting to combine testers and developers; in automating. Maybe the testers are working on behalf of the customers or the product owners to say: let's automate that. In the book written by Rick Mugridge and Ward Cunningham, it talks about story tests as "automating business value".

And I think that's a really nice way to talk about the story test, telling the story of the product, the same way the unit test tells the story of the code. That's one of the things I'm most excited about. Probably along with that would be the fact that at the Agile conferences, for the last couple of years, people that have been showing up that are coming from the organizational development camp, and talking about the human aspects of doing software.

And I think there's many people that have been writing about that for years: Jerry Weinberg, Alistair Cockburn... but it's starting to become something that's part of the process that actually is quantified and adding value, or is being quantified in the form of value. And I think that's a pretty exciting space, because for me I don't see a lot of projects failing because smart developers are working their hearts out.

I mean those same developers might be jamming a bunch of needless complexity in, but they also might be failing because no one is helping them to find their way through things, or building this larger community. I'm pretty excited that those people that have been thinking about that for years and years, people like Christopher Avery who has been part of the Agile conference for the last couple of years, are now part of the community.

So what's next for Agile? What's the next evolution?

I think evolution is a good word. When I talk with my business partners and with other people in the community, the people that I'm kind of drawn towards are the ones that view it as a means to an end and not an end unto itself. I don't know if we zoom ahead five years, what's going to happen. Using "yesterday's weather" probably a lot of change is going to happen in the Agile space.

I hope we continuously move towards using that communal consensus view of what's good and bad, to pick better and more appropriate solutions, I hope that's what Agile becomes. I think we're finding that some of the brands in the Agile space are starting to fall down or become less important. So we have what was/is "Extreme Programming" - a named way to do things, a core set of practices - and people came out of the box and said "you're either doing XP or you're not".

Whereas even one of the co-authors ... Kent's second book is so different from his first book. So different that I heard people say "if you've only read the second book it might be hard to do XP,"which is an interesting concept. But admittedly, I think the name was chosen as a lightning rod. "Extreme programming," it's like in the late '90s, early 2000, when all things were named Extreme, whether they were sodas or methodologies, Extreme something or other. That name maybe isn't as strong anymore, and the term Agile is a little bit of this, it's a little bit of this and a little bit of this; it's back to the thing we talked about before: it's a descriptive, "these things fit under into our company, these things help us deliver software of a certain quality in a predictable way."

And so I think that's what the term Agile is becoming. One of the things I hear in the Agile community is this: "Have we crossed the chasm from early adaptors?" I've heard actually Chris Avery say "I don't think that's an appropriate metaphor because I think we've created the chasm, and maybe the chasm doesn't exist" (I might be paraphrasing that). I do think we're on some kind of a climb, and I don't think we're too far up the hill.

I know that for a lot of people that do what I do, for coaching, there's more work than we know what to do with, and it's really to try and not let people get ahead of themselves, to say let's adopt the things we can do in your space instead of running to do all of it. You know, it's good to follow your passion, but maybe dangerous sometimes. So, that's what I see in the evolution of Agile. Certainly tons of things have happened in the evolution and the tool space but we need to evolve as people and we need to evolve the customer and the manager aspects of it, as well as possibly some tools for them that are like the umpteen tools the developers get.

So what inspires you to be an Agile coach?

I like that question, because for me it's like: what inspires me? I think that all I did any more was write code. I love to write code, that's where I started, but more importantly, what I like is seeing a group of people succeed. So back to my former life as a producer, an engineer or a musician, there's a great feeling of playing a song with some other people, jamming away, or bringing a group of people in the recording studio and making a CD, and they come out and they hold it up and they say "listen to this!" and they're really excited. I think the same thing happens in software: people live their software experience and they keep referencing it. specially times that are good or bad, like "One time we did this!" What inspires me is seeing the Agile stuff recreate that experience more than once, more than accidentally, with a core set of things that are like: "You know if we bring these in and we push them around..." we're probably likely to set up that environment where someone can say "On the project bla bla bla we had so much fun," and I think that's what inspires me.