 So this is kind of an experiment, so this involves me. I'm going to start by asking a few questions and posing some hypothesis to see where it goes. And I'd like to thank everyone for being on this panel. I'm trying to be a kind of a representative of this person and experience. And I'm going to start with some introductions. Let's go down to the floor. Brian here is a young hero. My dear thing is that it feels like you're missing God. I'm doing it at the festival, especially in Joy. But I'll believe you each a minute to kind of introduce yourself. So anything you want to say about yourself, tell us around here. Hi. Perfect, classic, Brian here. And then we've got Jonathan House. He's a technology director at analysis. And he's been going to the Adam Grandtale for a sense of the day at the time of the week. And I'll just take a quick look at him and introduce myself. Perfect. And I'd like to know all about him, right? All right, I'll try to do better job with this one. That's how you want to play. So Kristen's also a regular at the Adam Grandtale. He has a background in development and testing. He's also done some training at the Agile Coaching. You want to say anything about yourself? No. And then we have Israel God. He's had a law that I love reading now. He's kind of been sworn by my aide and executive leadership. Israel God is an agile executor. I'll let him say hi. Hi. And then we have Zahra Marston. She's currently the chair of the Agile Alliance. She's focusing on helping people with the human psychosocial development. I'll let her say hi. I'll be your old white woman. That's what I was wanting to say. Yeah. And then we have Lee Cruz. She's also a regular at the Adam Grandtale. She's an Agile Coaching program manager. She was at Dance N.D. and she was part of the transformation there. And she's currently working at Water Roller helping them become more agile. Say hi. Hi. And then Mike Moore. He's got years of experience as a developer. He's sort of an instigator. He's had podcasts. He's organized a Mountainous Movie conference. He's always finding cheery. And he's a new manager trying to lead a team towards Agile at most times. All right, perfect. So we can have him mix up executives, developers, testers, car owners, consultants, various roles and perspectives. So also in the spirit of Agile, and especially this conference, I don't want to exclude people from the conversation. That's why the mics are on there. So there's plenty of people that serve with a lot of experience, a lot of perspective. So feel free to jump in either through Twitter or through the mics and inject your comments and questions. And we'll just kind of make this really organic. And the set. So everyone kind of has a good capability. If you saw a little bit of this in both of the talks you've seen so far. And this is one of my personal feelings is that when you have these breakdowns in communication between the different personas, the word that Sue kept using is an incredible amount of churn. And that weighs a lot of time and energy that you need. But can't be said basically making software. We're trying to make work in software. That's kind of our balance system. So in the worst cases, the executives seem disintermove. The developers seem arrogant and dismissive. The product owners inappropriately demand specific implementations on one feature. And they wish you watched it on the next. And of course, no matter what, everything is always QA spot. So on one hand, you've got individuals in your actions that are processing tools. In reality, we sometimes use processing tools as a shield. Tools don't have egos, and processors don't disagree with us. So we kind of stop talking to each other. So the first question for the discussion is, do you agree with this premise? Not necessarily in your organization, might you? But in general, in the hypothetical sense, have you experienced this sort of breakdown in communication between the different levels and personas? And anyone who wants to answer that question, do you have it? Or is this part? And part of the issue is in the framing of the question. Absolutely. Personas are very useful for us in creating these cases and thinking about customers who might buy our stockwares. But when we start thinking of each other as personas, we're falling into the trap of stereotype. And the biggest indicator of whether or not I trust you is whether I know you as an individual. People don't necessarily trust groups that they don't feel they're a part of. And so as long as we have this idea of, and the title of the panel captures it, as long as we have this title of where us and everybody else is them, we've automatically begun the trip down the road to no trust. I would suggest that journey cooperation has perhaps a deeper meaning than the usual in your life. When I journey cooperation, I do not necessarily sign up for life as a person in the next stoppiece, or in the next department, and so on and so forth. However, my signature of the employment contract, in many ways, is commitment to trust because their interests are mutual. So to me, the two are very, very distinct. There is one thing where I like certain persons or not, and I have a degree of freedom to associate with me more than the other. There is quite a difference in the use of being in the same corporation. The fundamental assumption is to actually trust each other because we are all working towards the same end of time. So trust can, of course, at the same time, the act of joining the corporation will be the neck of trust in one another. So I have a question in relation to that. How many of you out here, just a quick show of hands, actually trust the people you're working with, not in your immediate team, but across the organization as a larger whole? Oh, come on now. Really trust? How many of us compensate by the work that we do for other groups and other teams in some of our environment that we don't quite entirely trust? So trust is obviously important. It's listed in every time that you hear people talking about agile, you hear about trust, personal safety, things like that, it's an important part of the environment. But the truth of the matter is that most software development environments out there really don't have the sense of trust. They don't have the sense of self-actualization. They're not striving necessarily to be the best that they can possibly be. So yes, trust is important, you have to build it. But you also have to compensate for situations where the trust doesn't exist until sometimes you can build it or just deal with the fact that it's not going to be there. So I have a problem, which is that I don't want to give away anything from my keynote. Nevertheless, I want to be disagreeable in some way. So let me tell you a story. I was once talking to the CEO of a smallish software company, like 100 programmers or something. And this was in the 90s when I was a testing consultant. And he said to me, regarding testing, that testing is like taxes. He viewed the testing budget as like income taxes, in the sense that he didn't really know what the money was going for. He suspected that if he did know what the money was going for, he would be unhappy. But he had so much else on his plate that he simply paid his testing tax and let it go. And I realize that back in the days when I had a real job and I was a tester, I actually benefited from that situation in that testing was sufficiently a low status job that none of the executives cared enough about what I was doing to interfere. And as a result, I was able to do a lot of very interesting testing work simply because not because they trusted me so much, but because they didn't care. So what I'd like to propose is that some of the problems we have is that so many people are working so close to the edge that everybody is sticking their nose into other people's business, making sure that every dime is being spent well and that five levels of management have to sign off on a travel request, that if we simply would just leave people alone, we wouldn't have so much of this problem if it is indeed a problem that we're talking about. That's the question. We think it's a problem. Does anyone think it's a problem? Raise your hand if you think it's a problem. You guys all trust each other, right? Come on. By the way, you're being filmed. And this may come back to invite you later or view time. All right, keep your hands down. With facial recognition. I'll say that the key for me, in my career so far, to building trust is to actually produce and to have a track record of success. And so I think whenever I happen in a low trust situation, just keep your head down and try to actually deliver something. I think maybe you're wondering just a little bit about clean story. I think it's also, I don't know that we've had trust issues. I think respect. We trust each other, but we may not have as much respect for someone's work or opinion or influence as we have to compensate for that and work around that. So there is a question. How's the rest of the question? I was listening. Is the mic on? It's not turning on. You should go. It's not connecting to anything. It's not connecting to anything. OK. We'll see you after we're done. OK. So what I want to know is if any of you, and I know it's a loaded question because I know the answer's yes, by the way. Yes. If any of you have been in a situation where there's I'll let you trust. Everybody's really nice to each other. I trust you. And therefore, there's no criticism. And the part of trust is also being able to criticize or raise problems. What about the flip side of what you've been talking about? There's too much of a legend trust. And as a result, people don't criticize each other. Yeah, I've worked in large enterprises. Yeah. The be nice culture kind of comes along anytime you start growing into a bureaucracy. You get that kind of be nice part of the culture. And what happens is that everything is harmonious on the surface, and there's no trust underneath. Because since a friend of mine says, if you can never say no, your yes doesn't mean much. So if I'm always saying yes, yes, and keeping things harmonious, that means I'm not able to say no. I'm not able to say I don't agree. It's a mega form of group think. And it leads us down all kinds of paths we don't want to travel. This deli awaits whether for internal reason or external reason. So that's the lead. The mic's broken. We can't hear him at all. I can't hear you. No. No. Thank you. Allow me to start again due to the fact that our device didn't work for me. My contention is that every culture has some strengths, and every culture has some weaknesses. They are different from one to another. But the situation that I described certainly happens. And it usually happens at a time that a culture, like the collaboration culture, it deliways. So the thing, the business of the class and the business of art. You know, artificial trust of the surface, no real trust underneath can indeed happen. However, a whole bunch of other pathologies happen as a function of other cultures. For example, in a very spontaneous world culture, people oftentimes are afraid to come with bad news because the reaction is so furious. So you need to look at the situation when you have what you consider to be trust on the surface, no real trust underneath, in terms of how it falls in the context of the culture that the cooperation has. So this book is written by a certain entrepreneur soliciting this Patrick Lencioni. He filled this model of the five dysfunctional team. It starts at the bottom. And this is sort of resonating when you're talking about an emptiness in the second level. So the bottom layer is this absence of trust. The second dysfunction is a fear of conflict. The third dysfunction, because there's no conflict, there's no real resolution like this, there's a lack of commitment. People won't commit unless they've actually developed a good end goal. Then the fourth layer is there's no accountability. And his argument is that psychologically, you feel that people haven't committed and you won't hold them accountable. And then the final dysfunction, in my mind, to the first of this, not focusing on results. And I feel like focusing on results and actually delivering is about a constant change in that. I think that's kind of a nice framework. And I just wanted to kind of throw it out there and you guys can comment on that. It seems like the direction you're going to go. Well, I'm not actually going in that direction. That's because you're Brian Merrick. Either way, everyone's swimming and you're going down. Yeah, so to say something against trust for a moment, many years ago, a whole ton of people went into Tiananmen Square to protest for democracy. They are going to resell rights to China, by the way. And right now, there are conflicting accounts of lots of people going into the streets of Tehran to do the same thing. The Iranian resale rights. I don't think it's right to characterize what they're doing. And remember that people right this instant are getting beaten up pretty severely in Tehran. And a lot of people died in Tiananmen Square. And I don't believe that they were out there together because they trusted each other so much as that they believed in something that really mattered. So they were willing to go out there without trust. So it's foolish to say, you shouldn't have trusted teams, blah, blah, blah, blah. But I wonder to what extent we are using trust to substitute for the fact that our work doesn't matter to us. The thing we're producing doesn't matter to us. It doesn't seem real. It doesn't seem valid. It doesn't seem important. So we're sublimating our desire to telegraph the message, our citizenship, by retreating to interpersonal communications, interpersonal reactions that are supposed to substitute for the fact that we don't feel a sense of accomplishment. I would agree with that. I think that if you're using trust to isolate yourself from change, and that's probably a bad thing, like you said, you need to stand on some principles. So I feel weird being here because I don't really come from an agile background, and I haven't really had any success in agile for a long time. I've been the guy at the very bottom. That's why you're here. Kind of yelling up and saying, let's do this, let's try this, let's pair. Let's get a CI server. Let's start testing all these other things, and I've had zero success in my career. And then I got a manager like two months ago, and it's been so easy to continue this integration server and to implement pairing and to start testing more. You got smarter. Yeah, I suddenly just got smarter with the title. And so I think to your point, though, I said, well, the entire team and really company works this way, and I'm going to trust that they know what they're doing. And I said, no, I mean, this is my one opportunity, and I should take advantage of it, and I should be in the ass and start making change. So yeah, to the extent that it allows me to do that, I would agree with you. Jim Heist made a beautiful slide that I would like to do justice to even verbally. It shows a caveman with a spare bagel or both sitting in front of a PC and joyfully putting it through. And the quips that go with it, and Jim literally asks it in various occasions to the audience, how many of you come on Monday morning to the office desiring to do poor quality work? The fact of the matter, I have never, in any of the times that I have seen this question asked, I have never seen a person raise his or her hand and say, hey, I do. So the issue to me is about the way or, and I would say, executives like myself and others, set the system. Namely, if the mindset is that those idiots down the aisle will never be able to crawl out of a big brown bag with a hole in the middle of it, then there is no way to make any progress in terms of agile or any other software method. If, on the other side, the person in charge has the humility, the strength and the introspection to say, I set up things in some false manner, I made this error, I made that error. Those people who come on Monday morning to do high quality work are not getting there because of something that I heard in setting, then you can start knocking one thing after another and improving. But in terms of the base materiality, please, that we all work with, I am very, very heart-pressed to think about any person that I had known during my career who did not come with best intentions about quality or whatever he or she would do. Which reminds me, Alistair referred this morning to some of the lean principles and how that's becoming part of agile. And when I think of lean, I think of sort of my favorite part of lean, which other than the definition of perfection, is the good fortune I had to take some trainings from Edward Stemming. And his assertion always was that it's not about the individuals, it's about how the system is created and that there is enough... I won't go so far as to say drive, but I will say influence, that systems influence behavior to such an extent that if there is something going wrong, look to the system, not to the people. What is it in the system that is causing that, inducing that behavior? And in his 14 points, he also talks about driving fear out of the workplace and a bunch of other really good advice. So if you haven't read Deming's 14 Points for Managers, do that and take them to heart because that in itself is setting up the conditions for success. And I think there's a lot of tension right now, frankly, in agile between those who would like to see it stay really focused on the people who are getting the software out the door, which is the development team. And rightly so, that needs a focus because without putting the software out the door, none of us have work. And those who are saying, but wait a minute, we have to create the conditions for success. And that's the job of other people in the organization than just the dev team. And so we are dealing with a paradox where we can't focus one place or the other. We have to focus on both simultaneously and that takes us to the system. So getting better at thinking in terms of our systems and in what our systems are doing also has an influence on some of these other things that we're talking about here. That would suggest that we should draw individuals from individuals and interactions over processes and tools. It should just be interactions over processes and tools. I suggest that a couple years ago. You know, I think this is pointing to one of the fundamental issues that doesn't get addressed often about Agile. That is that it's kind of self-selecting. If you're doing Agile right, you have certain qualities and personality and certain aspects of the culture that you've accepted. One of the things that you just mentioned is the fact that you are willing to drive fear out of your workplace. How many of you that work for a large corporation are willing to tilt against that big of a windmill in your workplace? The fear of going to your boss reporting to them that you're going to be late or something along those lines. I would propose that we're a self-selecting community. The people that are capable of doing this, the people that care about software beyond the point where they're collecting their paycheck, we're the ones that are going to do these things. We're willing to walk in, we're willing to tilt to the windmills, we're willing to fight these battles, even though we know that it's going to be hard at the best of times. It's going to be impossible at the worst of times. But what happens to us? In a large organization, in your groups, how many people really care about software? They care about it beyond when they're at their desk 8 to 5. They care about it beyond the time that they're at their desk 8 to 5. They care about it beyond the fact that it gets out of their department. How many of you really see that in the larger software development community? Or do you see it in this room in a smaller community of people that care? That's the fundamental assumption I think is missing. People say, oh, we're going to do Agile, but what they don't understand is that there's a cultural adoption that sits underneath this that requires certain things, that you have to care, you have to have courage, you have to be willing to make mistakes, you have to be willing to change. And I would say that the larger community, a lot of these skills are not present, and they're going to be awfully hard to teach. So are you suggesting that Agile hasn't crossed the chasm? I am suggesting that Agile will never cross the chasm. So I'm going to go back and ask a question. In the experiences you've had at whatever level, you've experienced the kind of lane game hot potato, and at that point your teams are going to stop focusing on what I call kicking donkey, and they instead focus on covering donkey. And once that cycle starts, have you ever seen anyone get out of it? I'll leave it to your imagination, Brian. I don't understand what kicking donkey would mean. What's another word for donkey? Oh, I get it. Not from the Midwest, we're slow. Let me pick on Mickey. Have that experience. I think we were successful, and it just built trust. We started slow and gained ground, but I don't think we ever pointed fingers at anyone. I think that the more successful we got, the more buying we got, the more trust we got, and it just kind of grew throughout. So I was at an organization a while ago, and at the time I would classify it as very little responsibility on the dev side. There was one tester in the org, and probably 50 or 60 developers. And what would happen is, and this wasn't an agile, so one of the things that happened was management shows to go down the witch hunt road to try to get that responsibility. And there was a time when I would actually say that I felt like the developers felt more responsibility, but then there was a time where that crossed the line and nobody was productive anymore because they were too worried about getting fired. And that's the environment that it was, by the way. It was very much a, if you, we will let somebody go every so many months. And, you know, everyone on it, one person from every team, depending on how big the team is, certain percentage will be let go. And what started, what happened is people stopped helping each other. It did turn into a spiral, and I ended up leaving, and went on the greener pastures. But I will say that I felt that at the time there was actually a point where I think that they might have been able to turn it around, where doing such a thing, contrary to what I would like to believe, doing such a thing did make a difference, but they kept doing it, they surpassed that line. So just to reiterate a point, the dynamite, do you feel like that is kind of reinforcing this idea of the system? Yeah, possibly. I have the fortune that my 15-year-old son is for one year in Japan as an exchange student this year. So I am learning and experiencing Japan through his fresh eyes. And problems, of course, come up in school or in some of the clubs that he goes to or with the host family. It does not make things that are not different than in the Midwest or on the east coast or the west coast here. What I am immensely impressed time and time again is the ability to fix the things without putting a blame on a certain person. There is a business of resolving a situation without making an individual, a teacher, a counselor, a host mom or the like, feeling completely guilty and helpless in terms of everyone turning on help is most impressive. He takes a lot of time and sometimes my wife or myself lose a little bit of patience until something gets resolved. So I have seen time and time again things get resolved without placing a blame and this makes a tremendous difference in the way things move forward there. I still want to get somebody here mad at me. So let me continue to attack trust in some sense. My wife, the veterinarian, has access to what they call euthanasia fluid. However, I have never before this moment said that I trust her not to use it on me. There is another thing that I have never told 200 some odd people before. One time I came back from a trip and we were unpacking my suitcase and we discovered a pair of women's black underwear in my suitcase and this did not lead to a conversation. I trust you husband that there's a legitimate explanation for this underwear in your suitcase because there isn't. I have no idea to this day how it arrived in my suitcase. It turned immediately into a joke. So I want to posit that the more we talk about trust the more it's a sign that we don't actually have any of it. It was the follow-up part. Brian, as you were talking that's what I was going to say. It's funny how we have to say I trust you but . . . and I agree that it seems like we are using trust to go back to your previous thing possibly as an excuse but I think it's also something that's very important to build. I don't know that you . . . to a certain point if you have a team of people that say it's a self-organizing team and everybody has different opinions and everybody goes off and does their own thing to the same exact work at what point do you have to get together and say, hey guys, let's build this concept of a team and I am able to handle this component and you're able to handle that component and H-U-A, you know, you are hired because of this. You can test this. I'm with Mike to . . . I think Mike said that trust is essentially delivery on your commitments. I'd like to make one small addition to that which is trust or whatever thing it is that we're trying to talk about under the rubric of trust is evidenced by someone on your team or someone on . . . someone whose work affects you doing something for you that inconveniences them. So Lisa Crispin, co-author of the book Agile Testing, which is a really good book, talks often about the way that the people on her team will do jobs that aren't really their job just because other people in the team need help and I think these activities, these visible activities are the most important thing and the words behind them are not. The one thing we have to keep in mind is that the word trust is a very loaded concept and trust itself isn't that interesting. It is what you trust. I can trust a co-worker to do his job. I can trust a co-worker to go beyond the call of duty and do everything that is necessary to deliver. I can trust another co-worker to lie to me every time I tell him or every time he tells me when something's supposed to be delivered. It's what we trust in each other that's important to the team, not the fact that we just trust each other in general. Let's hear from Jeff real quick. I'm Matty, Brian, just for throwing that out there. As a long term match, Lisa, I found a self-proclaimed wedway. I found the last few discussions somewhat disturbing because I'm thinking like we're going kind of on an orthogonal path to what I see as the strength of agile. I see the strength of agile being the engagement that happens between the members of the team and the people outside the team between the customer. And the trust, it either is going to be there, it's going to grow, it's going to decline. I don't really care. But if we're engaged, we're going to find out and we're going to work with that. So I think this should be a discussion more about engagement than about trust. What do you mean by engagement? Engagement means, well I think, okay so for example management I believe is very good at engaging with their employees because that's their job, right? However, I think those developers and especially perhaps because of their personality traits have a hard time engaging with those outside they become very insular and have a hard time engaging with those outside the team, outside the company at conferences like this. That kind of engagement is what I'm talking about. It's that interpersonal engagement that either leads to trust or leads to distrust. And frankly distrust can be just as useful as trust. Depending on who is, okay sometimes people on my development team I can't trust them to do something and that's okay because that means I just get another guy to do it who I do trust that it's mission critical. Is it fair to say that Jeff, is it fair to say that engagement shows trust? I think it makes it, it brings it to light whether you trust or not if you engage, if you disengage your only options are to not to trust until you know more information. Because I don't know maybe this is extreme but I don't know if I engage with somebody I don't trust. So the act of engagement is showing trust. Someone has to take the first step. I just want to interject one thing because I think that you guys might be arguing with semantics a little bit. This is obviously taken on a life of its own but kind of my original concept is the fidelity of the bandwidth or the communication between those roles is what determines a high functioning agility from a dysfunctional agility. That's sort of my starting premise and we kind of got onto trust but I think on some level with Jeff it's all about what he's calling engagement I think of this kind of high bandwidth communication between the different roles. Let me recount an episode from a company which definitely at the time was not agile because this is Microsoft. I was working for them at the time that the antitrust was going on and the ruling was to break the company. And productivity across the corporation went down the drain for the simple reason that everyone in his grandmother were spending all the time speculating about will the lawyers manage to turn things around or will they not manage to turn things around. Bill Gates, who always was extremely involved got together a bunch of us and basically tell us guys you have got to trust the lawyers to turn the jurisdiction around just they need to trust you to produce the code. And in one short meeting with this motif he really changed things around a big time. What would have happened if the decision was not turned around? I don't know. But in terms of the productivity across the corporation in 30 minutes possibly even lessens the change drastically by pointing out what trust really means in the context of the corporation. One of the things that we kind of do kind of skirt around is the human element of producing software. That's one of the things that I really liked about agile when I was first learning about it was it seemed like it focused on the individuals over the process it focused on more than just writing the code on the process of writing code and how you deal with other people to get to the end goal. I do think that agile is definitely missing that. I have ran a couple of podcasts and one of the things I like to talk about was talk about agile was talk about the practices how you adopted everything else and I got lots of email and communication coming back from that saying that people were just really sick and tired and these are really your target audience these are the developers who are going to be the ones who write the code and they're sick to death of hearing about agile. So I think to take on Brian's thing to get you guys mad I kind of think agile is broken so let's throw it out there I think that agile is not what it was intended to be and that's one of the reasons I was so excited for the agile route so let's go back to where it started and so I'll throw that out there is agile broken? I was in a conversation with some people in Portland about a year ago and I asked that question and I said I've been hearing a lot that agile is across the chasm and I don't know what I'd look forward to know that and what do you all think has agile crossed the chasm and a very wise person in the group looked at me and said well the word has crossed the chasm the actual doing of it is still somewhere on the other side and so I think that it has become a buzzword and people react to buzzwords and there was a time when empowerment was the big bad buzzword and these things run in cycles so what I'd like to do is go to an example of what you said was the title of this talk there's only us so an example of a time when there was only us is this a wonderful story that I heard recently about an organization that was embarking on quite a large project and they had a lot of sub parts and they knew they were going to have to to field about probably six or seven teams they weren't exactly sure so they got everybody in the room the whole development organization all the managers everybody in the room and they described the nature of the project and what they were trying to produce and they asked the people in the room how do you think we should organize this what's the best way how should we put the teams together and stuff they had some conversation they figured out what teams they were going to need in order to roll up into this larger project and then the manager said okay we're leaving the room now and when we come back we expect that all of you will have organized yourselves into the teams you want to work on and that you're best suited for and they left and they came back 20 minutes later or half an hour later and they had their teams and everybody started work now that to me that's the example of engagement, trust, no fear I mean all these things we've been talking about that's that's how that works is when you can see that kind of thing in action in an organization we can take another minute or two before lunch if you guys have anything to say I know you came up so let's hear from the audience but if you have a last word or something you want to get in so my question is hold on a second so Paris Hilton wants her under so my question is and maybe this flies in the face of there's only us it seems that over the course of perhaps the past decade a lot of development teams and a lot of development organizations have undergone a lot of improvement organizations and the large organizations that we live in were built around the assumption that the development group is in fact the bottleneck constraint I'd like to ask the panel are you seeing situations where that was the case the development group was the bottleneck constraint it no longer is the case and how is the organization that was structured around that basic assumption because now something else must be the bottleneck constraint alright my work here is done normal to sentence to give us a better understanding of the question yeah so in an organization whose main business is producing software for example there are all these other activities that go around the guys who are coding right there are people figuring out well what's the market there are people going out and finding customers there are people shepherding the production of the software into the environment and the customers all of these other things that happen that are not the guys with the fingers on the keyboards and the product owner working with them and all that sort of thing and it used to be the case I think in a lot of situations that all of those other functions could operate under the assumption that what is going to take the most time what is going to restrict our ability to bring product to market to bring value to market the speed at which the development group can actually build the thing and I think in some cases in many cases where you have teams that are delivering releaseable software every week or two weeks it's a very different situation than when well our next release is 24 months from now what sort of pain points have you been finding outside of the development trying to adjust to the fact that wait we've got another release it's only been two weeks since the last one or for instance we don't have time to do proper market research are you seeing things like this and how are successful groups adapting I think that the presupposition of that statement is that there are successful groups that are adapting and that implies what Alistair mentioned in his keynote the fact that you are looking for the bottlenecks and you're solving them you're moving the bottlenecks around the company ideally trying to get rid of them but how often does that actually happen but there's the other side of it too and this is the unsuccessful companies and I think that rather than a removal of bottlenecks it's just simply an acceptance of the fact that the bottleneck is always there and it will never go away and that's the other side of the coin so in a successful company yes but how many companies are really successful in delivering software on a frequent basis I certainly see such instances and my sense is that the most painful point is around a contract a contract to produce software the terms and the progression of the law simply is used behind these of the agile methodology or other methodologies I will give you an example from a recent bid that I was involved in I got the LFB and while reading it there were two clauses there that really struck me now and one was that they expect the vendor to be a child if the vendor is not a child he or she can provide an explanation how they would do about it but basically the clause is clear if you are not doing a child don't bother there was another clause there that said working software it dropped every week into the data center so I was impressed and came to the meeting for the organizations that issued the bid with extremely high expectations only to find out that there was a total disconnect between the state of their state of mind at least of their attorneys and the state of mind of the people who were running IT for them so we run into those things within the corporation and no doubt about it I was in a situation where I was told by marketing Israel you guys are shipping software faster than we can market it so the level is relatively easy to deal with the painful one is when it comes to two legal entities who needs to agree on what needs to be done so an agile contract and actually in this very city a lot of work has been done by Alistair and some of his colleagues about the various ways in which you structure agile contracts so if there is one endpoint which I would say can make a decisive difference in agile crossing the cousin is contract law catching up with agile concepts here's what I propose I have a lot of threads rolling around in my head and I want this guy that's got up in the middle to ask his question but there's only us and I think we're getting hungry so what I want to do is have him introduce kind of a new thread and then we'll take this discussion hopefully from here to lunch and everyone can talk about it with everyone on the panel and also there's a social tonight that everyone can talk about it even more so I've had the pleasure before we're another and sometimes we do it well often times we don't do it well for one reason or another and when we're not doing it well sometimes you might even accuse us of cargo culting where we're kind of going through the motions we're putting on the earphones waiting for the plane to land and nothing's happening I have conflicting feelings about that and I was curious about yours and that we introduce agile to these organizations there's nothing to happen and sometimes I think yeah, that's the right start at least they're waiting at least we've given them the tools but other times I'm thinking this isn't ever going to go anywhere so you're trying to say agile isn't having stand-ups and stop running documentation that you've done and tomorrow preview the laptop and have it set up to code and test enjoy your lunch