 And so I've got a little bit of experience with the Dynamics Center, and I serve as Chief Scientist for a company called Valtech, and we have an office here with around 600 people, and we do agile offshore development, and I've helped evolve and create that, and I've lived here, and I've worked on the other side of the fence as well, working with clients who are working with offshore service providers and so forth. So I've kind of worked several sides of this fence. If you want to go deeper into this, we have a whole chapter in our book that describes many of the experiments that apply in this domain and you want to get more concrete. And there's often an intersection between multi-site and offshore as well, and so we find the tips in that chapter useful as well. These have been based upon our experiences with respect to mission. Let's start. Now, some people have questions in their hands, and some of those people were born in the month of January. And please hold up your hand if you were born in the month of January. And you have questions. All right. Let's take your question, please. What are the best practices for collaboration between offshore and on-site teams? I'm going to branch for a moment and make a comment that Mary Popendick has also mentioned and I think is a theme in lean thinking. There's no such thing as best practices in domains like R&B. It frames the whole idea incorrectly. At least in English, best means best, which means that there's nothing better. And so if you set up a culture with the best practices group and the list of best practices, that immediately freezes you from the idea of continuous improvement and challenging the status quo, right? Or thinking that in this context, and vinyl writer's has talked about this for many years as well, that in different contexts different practices are appropriate. So I urge you to expunge from your vocabulary and mindset the idea of best practices. I'm quite sure that in repeatable domains like flying an airplane or a heart surgery, there are currently best practices which are relatively context-independent. But in younger domains like ours and domains with lots of variability that are highly context-dependent, there's no such thing as a best practice. Now what was your question again? Please ask your question again. For collaboration between on-site and offshore teams. Okay, so possibly useful in some contexts, practices for collaboration between on-shore teams and offshore teams. But really a multi-site question more than anything else, right? So there's so much I could say, and I'm not really quite sure how to prioritize it, but here's one comment. When I was here in living here, I used to live in Koromongala in 2006, I was coaching a team at Valtech whose client was in France. And the way that they had regular meetings was with a telephone, with a speakerphone. And there was very little trust between the two parties, or at least low, I'm not sure, very little isn't quite the right word. And there was little sense of human rapport or connection in any sort of real human way. It was just a disembodied voice and a phone. And humans are humans, and the human capital of forming human relationships in which you have a sense of trust and rapport with other people is not to be underestimated, first agile value, individuals and interactions over processes and tools. Sixth agile principle, face-to-face communication is the most effective. So what I suggested was that they put in place the use of Skype video, or these days Google Hangouts, which supports multiple sites for free, with video and just a simple computer projectors on each site and webcams. So that then the two sites in France and in Bengaluru could have a meeting sitting around here looking at the computer projector and vice versa, but then have a multi-site meeting with video. And this is a very important thing where you can start to see regularly frequently the people and their faces on the other side of the fence in order to start to build up the sense of human connection to the people. And it's not like it's video magic and it's suddenly going to make everyone have a big hug fest and be in love. And it's not going to make the inherent systemic variability go away, but it's these kinds of little things I think are quite important, especially in an offshore context where the mentality is often very much they're just resources that are kind of replaceable. And we want to move them to a culture of respect for people and this really long-term human connection. Consider the Toyota model, which I don't know well, but which I know emphasizes long-term relationships of trust and mutual support for the whole supply chain. They're really trying to build up human connections. Secondly, a little bit subtly, when you're people with English as a second language, France to India, it's English as a second language for both parties, then when you can see a person's lips through video it helps to disambiguate things related to accent and so forth, which reduces a bit of friction as well. Also what we don't always do, but sometimes try to do with our velvet projects here, is always have a person, always is a strong word, sometimes have a person in the project who knows the language, German, French or whatever, so that when they're having this conversation and something's not quite clear, they can actually help smooth that out by actually being able to translate. Surprisingly you can find an Indian person in Bengaluru who's got a degree in French or German or you name it, and they can also help with translating different documents. Other experiments to consider is, and we try to do this at Veltec, is to help build up this connection, is for the onsite customer to physically come to us and spend one or two sprints actually with the team, ideally in the team room, to help build up this connection, reduce all of this hand-off waste related to the tacit information, and also to build the trust relationship so that when they go away, the trust is a little bit better. And then these days in 2013, I just recommend more broadly a lot of the Google collaboration tools, Google Hangouts where you get free multi-site video conferencing, Google Docs where it's easy to share things real-time, and I should also mention here something that I'm applying, is free. It's really important I've noticed, especially with multi-site and even more so with low-cost countries to make sure that you eliminate any friction related to commercial tools. And every year that passes, I have less and less pastings for any form of commercial tools because of all of the friction that I see that they introduce. And so if you've just got ubiquitous free video with things like Google Hangouts and computer projectors, it makes it easy to reduce this kind of friction. Another suggestion is to, and this is a very common anti-pattern, yet ubiquitous in the Indian service providers. The Indian service providers, outsourcers, usually have this concept called single point of contact. I can't think about worse idea. There's such a thing as worst practices, that's one of them. Because you saw the keynote and you saw the contract game and the obfuscation that happens. And so this person in the middle will act as an obfuscator and even if they're not intending to be an obfuscator, just because of information scatter and transformation, things get lost. And so I like to encourage a model that, to maybe show a picture for it now, where in English there's this concept called a matchmaker. We're trying to help other people fall in love. And so I encourage if someone for example from India is going to go to the customer site in France, that they do not act as a single point of contact, but they act as a connector or a matchmaker to try to get the customers talking directly face to face with the real team with no project managers and other people in between. This of course is, basically I could boil everything I'm going to say for the next 60 minutes down to a very short idea. Take every established best practice in the Indian outsourcers and do the exact opposite. It's really that simple. That's like you had my intention. Yeah. February. February. That's interesting. Let's subtract nine months from that and figure out what's happening in India. Do you have the national cricket? Yes, February. With some locations, the time difference is too high and if you want to continue developing, how do we collaborate? So you're talking about for example, Chicago to Bengaluru which is like 13 hour time zone. That's a wicked problem as we say in English which means it doesn't have any process or practice solution which has a significant impact on it. However, you're familiar with relativity theory. You know that time is actually relative to the relative velocity of the two observance. So if you can just speed one of the parties up closer to the speed of light, the actual 13 hour time zone difference will sort of disappear. And I can give you some references to potential work to ride those solutions with a simple edge. What else could I say? I think Chicago is where people have precipitated. Yeah, it's even worse. So I mean, there are things that I can say. I'm just trying to drag stuff out of my memory now. Well, this is because it's a wicked problem, both parties are going to have to pay some pain. For example, okay, let's have a meeting at 6 o'clock in the morning, which is 6 o'clock at night for somebody. So you have to pay some of that pain. That's about the best that I can say is that both parties are going to have to make some pain. And I guess another obvious thing is because the communication is going to be more asynchronous rather than synchronous, it's kind of inevitable by that way, then make the asynchronous tools for communication as rich and easy as possible. You know, Twitter, Free Open Source, Wiki pages that support good good conversation streams that you keep track of conversations. Try to stay away from email. If you're familiar with things like confluence or on Wiki pages, you can have like threaded discussions. In other words, asynchronous tools that keep track of the discussions and organized ways. That's one suggestion. Another suggestion, which we make in the multi-site chapter of our book is a proxy product owner. I normally don't recommend proxy product owners because first of all, I like to call them fake product owners because it signals the fact that you haven't solved the contract game usually, unless you have a real product owner. But one valid reason for a proxy product owner on-site in India is that then the team is not so starved for often subject matter questions or product management type questions. So is it possible to find someone in Bengaluru who can act as a proxy product owner? But this is again a bit of a wicked problem because often the context of your question is that maybe the domain experts are in Los Angeles and there's just nobody here who knows the answer and so then we're back to kind of wicked problems. Other variations which I've seen in a couple of companies is that they, let's take for example investment money. All the traders are really busy and they're not going to talk to us. But there's a retired trader who that we can actually hire for three months to join our group and they don't really know about that product and that domain but they know about investment banking and trading in general and sometimes we can get some insight from them. But none of those are really satisfying answers. What is the best you have seen over that time? The best? 0. Next question? I don't know what to say. I have a question, sir. Are you going in January? Yes, I am. Is it that question or a different question? I just, continuation to that. I might not take it. I want to hear what it is. I don't want out of order questions. I just want to say, I mean in your experience have you seen Scrum models in a situation where there is such a big time difference or generally there? Oh yes, oh yes, absolutely. And you know, my company, VELTAC has done development with big time zone apps. For example, VELTAC also has an office in Dallas which is close to 12 time zones. And we've done travel like systems or Saber and so forth where our customers were in Dallas and we were here in Vancouver. And it's just tough. It's a big problem. So proxies, both people paying some pain in terms of meeting times stuff like that. And naturally perhaps to state the obvious you're going to have to move to more documentation. Handoff. Because synchronous communication and stories stories by the way are not a format. Stories are a behavior. Let me branch slightly. So many people misunderstand the idea of stories and incorrectly think that if you write stories as a I want blah blah blah. The complete nonsense. The guy who created the idea stories Kent Beck. If you want to understand an idea often just consider the word and ask the originators and why would they use that name. Like why was Agile called Agile? I wonder if it's because it's an efficient system. No, Agile means Agile. It's for flexibility. Scrum, why is it called Scrum? Because it's the whole team together down the field together and so on. Story. Why did Kent Beck call this idea story? Because it involves people having face-to-face conversations and doing requirements by conversation. Telling stories to each other rather than handoff. And so I know I'm branching completely but I just want to make this point. So the idea of stories is the 3C's card conversation confirmation and that so what doing stories normally means the face-to-face conversation but we're going to have to move more to a handoff in this like 13 hour time zone difference. Which actually kind of reminds me of another idea which is since there was going to be more handoff you want the written requirements to be clearer or effective more simple with the least amount of overhead. And one of the best techniques that I've found for this in my career is a technique called specification by example. And I'm not going to go into the details but in the testing chapter of one of our scanning books and there's two books on the subject bridging the communication gap and specification by example and I'm going to use expect by example as the way to achieve confirmation and clarity around the requirements whether they must be written down. I should also mention by the way that scrum is completely neutral on the requirements model you can consider the terminology there's no such thing as stories in scrum that's an XP idea. In scrum the elements of the product backlog are called items on purpose to emphasize the fact that it's neutral on many practices and so you can apply what's appropriate in different contexts. Kent Schwabber often talks about use the appropriate requirements model. So for example for some of these are ways in which people think oh use cases must be bad because they existed before XP was and it's still really good use cases bad. Of course this is a silly naive false dichotomy. Use cases are a very skillful way to help understand requirements, promoted and often refined and well understood by the person who wrote the first book with Agile in the title, Alistair Coburn also the author of the excellent book writing effective use cases. It's a really skillful insightful book of how when you have to write things down how to do so skillfully and you can do use cases in scrum and in this context where you're going to have to do more handoff than face-to-face communication. Skillful use of use cases with a writing effective book. Specification by example help might reduce that pain a little bit. Did that merge? Yes. Question for my colleague. There is resistance at none of the cases towards author. How do you overcome that resistance? First of all I remember a book says the sub-title I'm not trying to promote the book or I don't make any money from these anyways I'm just making a point. The sub-title is large multi-site offshore product development and if you read the first page of the first chapter it says don't, don't, don't because most of the motivations around offshore are based upon very flawed assumptions. Now don't misunderstand me I'm an old file and I've been living here since 1978 and I'm really interested you know like for example in branching slightly but my girls are growing up now and they're adults but I remember years and years ago I was somewhere in India and I saw a little girl like three years old obviously from a very poor family just sitting on the side of the road in a real spun real grinding poverty and I have children and if you're a parent and you see this at least for me my feeling is I want to do something practical in this situation and one of the reasons I spend time here and I promote these kinds of ideas is to help raise the economies of the world to a more equal playing field so that everyone can get a bigger slice of the pie and that the pie grows as well I know I'm branching slightly but there's a connection here so I'm not trying to suggest by saying don't, don't, don't I'm not trying to demote the Indian offshore development model that's not what I'm saying but I'm saying something different which is that most organizations that want to do offshore have the right reasons and it could be coming back to your original question but the group that's saying we're resisting this actually is doing it for the right reasons because it's a low optimization thinking that oh we're going to save money if we offshore because the quality of programmers doesn't matter and if we just find the cheapest possible people and it's just like making chapattis on an assembly line everything's going to be better and the people who are here who are resisting that understand the fallacy of that thinking and instead are focusing on really great people who have had years of experience and stability and the productivity that comes from that they're right to resist the idea of offshoring so I'd really have to know more about the context of what the resistance is to know whether it was actually a good idea or a bad idea to resist and that's if you actually look at the research into cost savings when offshoring whether it's not to India but to any other place the frictions and the cost that are associated with that when you actually look at total cost of ownership at a very deep subtle level often in ways that are not easy to quantify on the balance sheet because they're often seen only subtly in the dynamics of the interactions and so forth that could be very very high and in fact the best thing they could be doing is resisting this sorry to put it that way April yes usually the best techniques are cocaine bribes things like that it's another you don't quote me on that am I on camera right now I have many years ago I was at Hewlett Packard Labs giving an introduction to design patterns and object oriented development and I said to the group the way to think about object oriented design it's like all of your objects are alive and they're independent actors and it's like you're on LSD and everything's come to life and somebody turned that into a quote that Craig Glarman says building software is like being on LSD so back to your question it's a wicked problem I put it in that category and so it's hard for me to give any kind of like sort of obvious answer because it is a wicked problem is it possible for some of the members of your team to spend time physically in the other site in order to build more social networks, strong social networks is that kind of thing possible but again when it comes to design your work package the team size will then become surrender if there is a collective work package which can be handled by four teams as we have two teams it won't be given to us which are which are like four teams USA or four teams that work package won't come to us so in this scenario the obvious solution is there should be more teams here which of course is a local optimization but it will certainly be the first that you can predict what would happen in the organization I'm sorry I don't have a better answer that's so context specific I can't say I've ever had any experience with that situation it just strikes me as highly wicked were you April I can't remember, were you March or April we're on to April I'll take an April in the very far back there ladies you know she's got balls so to speak so let's take her question and then I'll take yours too talking about offshore definitely there's a lot of cultural difference so whenever we have teams working across different geographical areas there is definitely the mindset so I want you to give us few suggestions because no amount of training on cultural aspect is really giving that breakthrough wicked problem not a wicked problem it's actually non-trivial but it's not like the world's biggest problem so a couple of comments because I have worked a lot with this dynamic both here and in China and in other places the first is that and I know of particular order the first is that there is research in the area of cultural differences in different areas and its influence on work and expectations I'm not going to go into the citations but the bottom line is for example I've worked with customers like Siemens which have worked hard at this level and you can get cultural training courses where some are worse and some are better which actually help people from different cultures to increasingly understand the assumptions of how the other groups work for example in India no doesn't mean no and yes doesn't mean yes and you need to understand that if you read my offshore chapter I give tips for example don't ask yes no questions ask open questions but that's a very specific tip I'll just go to that more general level which is the whole world cultural courses and consultants and teachers who can teach people about sensitivity to the different cultures and being aware of that when they talk another aspect which you know well is that there's a concept of in different languages languages are more high context or low context so for example in Canada where I come from you spell it out and in India that would almost be considered stupid is too strong a word but it would just be considered unnecessary to spell it out because of course we assume certain things but the problem is is that assumptions after working for 35 years in R&D assumptions not spelled out and tested are the root of a whole lot of problems and so understanding in different cultures the amount of high low language context and this is often again through training so a lot of this through cultural training courses regularly is one piece of the puzzle another piece of the puzzle which has a stronger intersection with scrum is the following so question what's the only if you're a member of a team what's your only job title team member and so there's no architect there's no senior architect now I know in India what your mother in law is thinking and that's not good enough so instead of a false dichotomy so many problems that I hear about I hear basically false dichotomy thinking well either your job title is team member or your job title is senior architect but there's a third approach which is both which is that internally in your company let's imagine at Valtech internally job title is team member but you have an external title for example if you're going to quit and go somewhere else the HR group will give you an external title which somehow reflects what would make sense project manager senior architect and so you can say that to your mother in law and you can maybe even have it on your business card and you can have a different view so there's little things like that that you can do in scrum as well another aspect is the influence of hierarchy and deference to seniority in different cultures and how this plays out in self-organizing teams this is actually even stronger is Kenji here in the room no this is even stronger in countries like Japan and so forth and somewhat in China people say it's very strong in India places where it's stronger than here and one of the things that I've seen in order to ameliorate or reduce the impact of the deference to seniority and authority that's somewhat baked into the end of culture is that you just definitely have to get the managers off the floor you know you have to like in I work in some organizations where managers are great and they're really adding value their systems thinkers their teachers they really understand their job is to improve the organizational design and they're helping rather than doing command and control and I've seen great managers but that's actually a minority of the people in management positions that I've seen I would say the vast majority aren't like that and they're more getting in the way than actually adding value and especially for those kinds of folks you have to get them off the floor so branching slightly to create a self-managing team that's actually self-actualized and actually gels and works effectively the self-organizing team step one is that you have to create space you have to eliminate the obvious things which kind of inhibit the potential for self-organizing like they're not co-located like there's formal authority in the room and it yells out implicitly I'm the line of authority and if you create the space for self-organization it's not like the freshers are suddenly going to speak up and start being really active but it takes the edge off a little bit and then with a good scrum master to help coach it out it can come up a little bit so those are a few thoughts not yet because there was a gentleman on the back also from April who I promised that I would take his question yes now I just wanted to make a terminology definition so that people understand some few issues distributed team is an overloaded term and in one world it means there are two teams one in one site and one in the other and it is also overloaded to mean there's one team of seven people three of which are in one city and one is the other I prefer some other terminology that exists in the literature dispersed team which is one team which is dispersed unambiguous multi site teams where the teams are in different sites and I believe you're asking about a dispersed team just to test my understanding so usually and often I won't answer the question at the level that you ask it I'll often cut through it to a different level so usually when there's a dispersed team there's a local optimization at play which actually is not necessary for example we must have a dispersed team because a choke knows X and a choke is in deli and we're not and therefore we must have a dispersed team but in fact it is possible to focus on skills transfer and eliminate the need for a choke in deli if you would just pay the price the learning debt of the team let's say let's suppose there's five people in deli and two people in munich well it is possible for example for the five people in did I say deli the five people in deli add two more people or take the existing five and just get them to start learning the skill that the two people in munich know really well it is not an impossible task for them eventually to learn that or as a variation they go to munich and they spend time with the super experts there and learn and then come back or as another variation the two experts in munich come here for a couple of months and you identify some people, two people on the team who will have a secondary specialty in that and the two experts from munich focus on teaching them because in scrum one of the key ideas is multi learning so that people have more than just one skill they might have a second or even a tertiary skill and so we can generate all kinds of learning techniques to deal with the root cause problem and my first recommendation is don't live with the dispersion because of this local optimization or the belief that the learning would cost too much but instead and this is a theme of scrum if you read to kuchi and nanaka's original 1986 paper the roots of scrum and the harvard business review the new product development game is this emphasis on an organizational transfer of learning to quote from the paper so these organizations are always focusing on learning and teaching to reduce the debt rather than living with it and just accepting the price that you pay so that's one comment okay but let's say for some reason they're nuclear physicists and the knowledge transfer is going to be wicked hard and you have to live with the disperse team for some period of time let's just assume that is a constraint so and by the way some of the tips that I'm suggesting here are covered in the very questions that you're asking are covered in the multi-site chapter of this book so a couple of suggestions is increase synchronous communication as much as possible to reduce the friction between the teams if there's some time zone overlap so an open chat line or a google hangouts video connection so you reduce the friction as much as possible there's that you asked about pair programming now just to be clear my focus is scrum rather than extreme programming scrum is more of an organizational design framework which touches on slightly larger issues than xp and also key points scrum is silent on virtually every practice there's no such thing as pair programming in scrum there's no such thing as stories or continuous integration in scrum scrum is silent on everything it's just an empty box and it emphasizes empirical process control and appropriate techniques in different contexts so there's no concept of pair programming in scrum but that doesn't mean you can't do it it just means scrum is silent on the subject in contrast to xp now if a scrum team chooses to do pair programming in fact if you wanted to focus on the knowledge transfer then indeed pair programming from someone in munich to someone in delhi is a really good idea and branching very briefly there are free open source tools available for eclipse for distributed pair programming i can't remember the names but i know that they exist does anyone know what the names are oh myelin's more like a originally well originally myelin was more like keeping track of tasks rather than distributed desktop is now mutated into a distributed desktop tool no no no no there's an actual free open source tool specifically for eclipse which is for pair programming distributed and so that would be one tool that you can use the name of it i can't remember right now let's move on oh you had a real burning issue okay marching or moving forward sorry we've just done april and we're on to may let's take may micromanagement when it comes to a customer having a scrum master alone sitting on site with one developer and six or seven offshore developers in the cave right and it becomes like a state of meeting and it starts getting into the pitfalls and all of that so how do you handle that scenario because coaching does not seem to work so effectively and many a times people have bought into this whole idea because so first of all i'll make a sort of couple statements you'll see which is relevant here for your case all of these slides are available to you by the way if you haven't picked them up already see if i can find the one more specific to your question and actually this is the onshore management offshore development and so the quick answer is don't and you might think that's very hard but i'll leave in branch further and open it up a little further people are saying to me at lunchtime oh craig it's so hard to change a large organization to a real scrum no it takes about two hours if you've met leadership and the cio and they've made the agreement and they really understand it tearing up the org chart and reorganizing to real cross functional teams eliminating unnecessary project management roles eliminating the contract game is a policy change it's actually like that if the senior leadership agrees similarly how hard is it to stop this it's a one second to stop it if you're at this level and the senior leadership says no we're not going to do fake scrum right so if you had a senior leader who understood all of this stuff and said no we're not going to allow that we want real scrum then the problem goes away like that and the only kind of answers to these kinds of questions is that i'm not interested in enabling fake scrum what i'm interested in doing is addressing the root causes and having the courage to say what real scrum is and not enabling fake scrum to repeat myself so if you're an agile coach or consultant or a scrum master i recommend you try to come in at a much higher level and to fix the problem at the organizational policy level otherwise it'll never be fixed you're just going to be rearranging the dynamic and that's not what i'm trying to suggest a local issue that happens with that fake scenarios usually it's like you have a co-located agile team working on site you transition to offshore there's always a four month final inspector that happens with a new environment where things get boring before that you start measuring and saying productivity measurements and bringing it down if we want to open up that box in two hours coming back to the Toyota model and i recommend this so the Toyota model is the supplier is not the enemy it's a long term win relationship the Toyota people and i haven't seen this directly this is only from book knowledge the Toyota people go into the supplier and basically saying we're going to help you we're going to go on a journey together to improve and it's not about creating a stick to beat people with it's just to help understand where we are and improve and so you're suggesting a paradigm or a context or a mindset which is very much not what customer collaboration over contract negotiation is about and the solution is you have to go to a higher level people who really will take the time at a senior level to understand this and put in place an organizational design set of values that understand it it doesn't have to happen in the morning session you were mentioning the importance but in reality today there's a buzzword and everybody wants to move there then i challenge your statement that the senior people really understand it or i'll make a few more comments something i've learned over the years and it took me a long time to understand this this is like one of the secrets of change i've learned is that real mindset change and culture change does not happen without structural change i've learned about many different systems of thought over the years the organizational learning movement and very concrete systems of organizational design and along the spectrum sort of from like more soft to very concrete and prescriptive and what i've come to see is that the very very soft principle-only systems very hard to actually make sticky and really adopt because they're a little bit too squishy and soft and there's this natural tendency in organizations that the existing management structures shall not change and there will be resistance to all the names will change without them changing and so systems which are very just soft and principle-based don't really usually make a deep impact there are exceptions and on the other hand there are systems of thought and organizational design and R&D which are highly prescriptive they're too brittle and so forth and we need to find a goldilocks zone of things that are in the middle i believe scrum is one of those things there's enough structure but the organizational design message that people can get their hands around it and point to back what i just said then actually change the organizational structure in order to reflect that and it's my observation that systems that demand a change in structure roles, responsibilities group interactions and so forth is critical to actually make a meaningful change and so i'm going to suggest that what's going on in your organization is that structure and policies have not changed that somehow they just believe it'll it's a practice rather than an organizational framework change and so without changing structure nothing is ever really going to happen there's something else i wanted to say about your question it's just drifted below my short term memory let me just see if it'll come back no, you'll see if it pops up again later and what month are you? May, so we're on to April let's take April it's May, June yeah, i haven't had enough chai today June let me make a couple of comments i can flip pages here so you'll find in the handouts the agile contracts handout and you should know that in this chapter of our book we have a whole chapter on the subject of contracts and we have a website called agile contracts where that whole chapter is available for free and i recommend that you get it and read it also Mary and Tom Poppendike have done work and published in this area and i recommend you read this so at an abstract level i recommend you read this to get some ideas that's the first suggestion now, at a deeper level it's important to understand that contract does not automatically imply fixed price, fixed scope, fixed date there's myriad contracts progressive contracts in which you can have variable scope and so forth like in our company we've gone through variations and the chapter describes many of the variations and the variations also often reflect the amount of trust that the customer has with the supplier so for example, in our case in Daltec's case it's not uncommon that the first project will the customer reflecting their lack of trust will be more fixed scope, fixed date by the way though fixed scope contracts will almost always introduce what's called the principle of replaceability so that customers are free to remove something if they can put something else that we both agree on is about the same effort size so we get more flexibility in there and in the agile contracts paper that you can read we talk more about that and then it's not uncommon that if you do potentially shippable product increment every two weeks sprint and build up some trust with the customer that they're a little bit less concerned about the original contract language not always but it smooths off the rough edges a little bit so that you even in this so-called very rigid contract things are a little bit better I should also mention by the way that this whole chapter starts with a key theme which is that you have to educate the contract writers the first half of this paper we wrote this with a lawyer who has experience in all of this stuff is that you have to educate the people who are writing the contract in systems thinking instead of silo mentality and really understanding the goal is project success not a contract output starts there coming back to the Veltec story then if we do the first contract successfully we may then propose a subsequent contract for a new release project in which we move to more of a progressive evolutionary kind of contract more for example it might just be fixed price per sprint and then every sprint they can introduce different stuff and pay for sprint and the ability to end on any boundary notice that the whole context changes in scrum because you can do potentially shipable product increment every sprint so the whole fear around it's not done until it's done and there's a lot of stuff that's not done in the middle and so we need all kinds of management around that that goes away because the risk is low for the customer in scrum they don't like the supplier they can kind of kill it in any too big boundary and they can have something with value and this really changes the nature of the game so I think there's so much I could say on the subject but I think I'll summarize it to that by saying read the chapter and you'll get more ideas and focus on connecting with your writers of your contracts let's move on to July yes so first to repeat there's a whole section in the agile contracts primer that talks about how to do fixed scope fixed bid fixed date contracts more flexibility the first thing that we suggest is to introduce the principle of replaceability as I said before so that so that if so you introduce some agility to the customer by being able to take something out and replace it with something else but I'm wondering if your question is deeper is your question how do you estimate for a fixed bid contract is that your question yeah so there's the principle of replaceability which right well that's why the rule in replaceability is that it has to we have to agree that it's the same size which by the way also then means that you have to educate both parties on the estimation technique and it needs to be transparent so that when you do a replaceability there's not friction around that yeah yeah those of course those questions or concerns are independent of the contract that's just about the relationship a few comments on that question though it's related to lack of transparency or visibility and in traditional offshoring models with a single point of contact and the customer never seeing the faces of the India team and a long time before they have potentially shipable product all of this reduces the sense of trust from the customer's perspective and so if you can do all of the opposites get rid of single point of failure have face to face communications have well done PSPI every sprint all of that starts to build up more transparency starts to build some basis for trust no I don't think so let's move on to August yes you are talking about a lot of structural design yes organizational design don't you think it is like tail wagging the dog in terms of technology guys trying to make the whole business you could frame it like that however simply go into classic management research about how to effectively organize people and this management research not coming from technical people but just people who are looking at evidence based management or understanding things at a very deep level in terms of queuing theory and industrial psychology what you will discover is that what we're suggesting in scrum is simply aligned with evidence based management and the fact that the messenger of this is coming from people from the R&D or technology world naturally would lead one to think that this is just a technology idea but if you want send me an email and I'll send you pointers to 200 books in classic management principles and org design from writers and researchers who don't know anything about technology you read those books and you will come to the conclusion of things that are similar to things like scrum and lean and so forth then don't you think it is better to sell the management the idea through those absolutely in fact I could bring up a presentation I'm about to go to JP Morgan in London soon and I'll be with very senior management team and if I were to show you my presentation that I start with, it starts with evidence based management and I spend the first hour looking at publications from like 1960 and 1955 classics, well known classics like the human side of the enterprise by McGregor, Theory X, Theory Y and so on and so forth to actually make the point that this is just classic evidence based management and I do recommend that and I'll go a little bit deeper now if I gave the keynote speech at the Agile conference 2002 or 2003 in Calgary if I recall and I gave a keynote speech there where I started off by talking about what I call the bloodletting story and so it used to be the case that if you were, this was a European medical theory so in the dark ages and middle ages that if you were sick the obvious problem was that the four humors of the body were not properly balanced and so we're going to cut you open and pour most of your blood out onto the floor well, of course lots of people died and it didn't do much good but this was actually absolutely standard practice and if you were to say, you know I'm not sure that's such a good idea have you considered washing your hands before cutting somebody open oh, fool, what do you know you obviously haven't studied astrological diagnosis of medical problems and so on and so forth so what happened in medicine was a paradigm shift to evidence-based, science-based medicine I'd like to suggest that in management we are largely in the dark ages and that most of the things that people do in management are based upon common sense which has got very little alignment about how things really are and we haven't actually made the paradigm shift to real evidence-based management yet it's mostly just very ad hoc and to branch slightly deeper humans naturally locally optimize it's kind of built into our mindset we're not used to the nature of us building software systems here with delayed feedback loops where you push here and it takes six months for it to poke you in the eye and furthermore the non-linearities when I push with force four it pushes in the eye with force nine these kinds of very subtle dynamics and you know I'm speaking in an abstract level about how organizations and human work systems work and not to mention human psychology and social dynamics and so forth humans don't have a good grasp of this by common sense it is understandable that it requires real education and it takes education out of our common sense into something which is a little bit simpler and there's a movement coming out of Stanford University from Pfeffer and Sutton at others called the evidence-based management movement you can find a website on it there's a book called hard facts whose subtitle is evidence-based management and broadly I encourage people to connect with this and this is not new information it's often referring to information that's been around for decades so I like to say please don't believe anything that I say and that shouldn't be surprising because if we were in a medical conference and we were doctors it would be natural for me to say please don't believe anything I say because we have a framework where we think in terms of evidence-based medicine and statistically significant peer reviewed meaningful quality research and theories which actually really align with how things work and theories about human behavior at work and work systems with cues where the predictions really correspond to what happens and very broadly I'm interested in promoting that kind of a mindset which does exist in pockets here and there but I'd say it's the small fraction of companies of leaders in company kind of insight and because it's a one hour talk and for people who have burning questions all remain around here for a little while and take them Thank you very much