 What's the topic of the panel before we introduce the panelists? It's a panel discussion. What's the topic for the panel? Predictability and predictability and productivity. Does agile help? So we have four people who are extremely qualified to be on this panel and notice there's one chair that's left open. Which means that any one of you is equally qualified to come up here and if you want to continue, come and show them and then you can go back so we can leave that empty for someone else. So kind of mixing a little bit of fish ball style of the panel where we want to involve you guys to come up as well but we have these guys whose seats are viewed and they can't move but there's one seat open for anyone to come in, give you answers and then go back so that gives opportunity for someone else. Let me quickly introduce our panel and we'll get started. So you heard Josh lying in the morning. So thanks Josh for joining the panel. Limbelle is the keynote speaker. You'll hear her tomorrow. She also did a retrospective workshop today so thanks later. We have Goro here. I think Goro is someone you might have not met during the conference. He just came from the panel. Let me give a quick introduction about Goro. I met Goro about three weeks ago, two weeks ago. I always mix up time. Goro is the co-founder of a company called Sabah. He is also the main champion, one of the main champions here who is helping the Pune startup ecosystem, doing a lot of work bringing all the different organizations which help the startup. So when I first sent him an email, he replied back, we got on the phone and wow, I think he was extremely encouraging so I can see how he's been supporting all the startup, the entire Pune ecosystem here. So thanks for joining us, Goro Meira. And Julian, you just heard Julian give us keynote about how he's changing the world with experiments about education. So we have these four panelists. I'm going to kick off the panel with one question because I chose the topic. So I'm going to kick off the panel with one question. You guys have one mic, so one person gets a chance and then everyone could chip in. And once I'm done with the question, they've answered it. Then I'll pass this mic around and whoever has a question can ask the question. Clear so far? Fantastic. So the reason we put this topic together was often when we talk to a lot of companies, they say, oh, yes, we're going to go agile. And you say, that's fantastic, but what are your expectations? What do you want out of that? Why are you making this transition? Guess what's the answer? Faster, better productivity. Because of those? Everyone is doing it. Yes? Predictability is another common thing. We want our software delivery to be more predictable. We want it to be more higher quality. All of these things people talk about. But the things that most people struggle with in my opinion, I could be wrong, is predictability and productivity. The reason is because I believe there are a lot of misconceptions around that and we thought it would be good to get a panel and have a discussion around that. So that's the idea behind the panel. So can each of you define in your own terms what do you mean by productivity and what do you mean by predictability? What does these terms mean to you? I was working for a medium-sized telecom company when I started doing agile. And then we had a struggle with a particular customer who came in one day and said, I don't know what I want. I want my June. And of course this is a company in the U.S. So what did we say? Yeah. Yeah, we can do that. Now we knew that if we were going to follow our regular process, that would be impossible because the regular process involved a requirements document, spending a very long time up front really understanding what the customer wanted before we ever began any sort of move toward development. So that's when we discovered Scrum. This was in the mid-90s. And we realized that this would help us because we could begin with the knowledge of what we could start with, a little tiny piece of that. And that by the time we delivered that little piece, well then the customer would know a little bit, the market would know a little bit, and we could add on to that first little piece. And that's how we proceeded. It wasn't that the customer was trying to be difficult. The customer really didn't know. And in fact no one knew. That deadline was not artificial. The customer knew that the market was about to change and that things were going to happen in June and that they were going to stay in game. They would have to be ready for that. So the end of the story is we were able to deliver, and I will never forget that retrospective. It said we grew this together. So if we want to talk about increase in productivity, there's no way we could have done that using our old process. And that's what agile brings to the table. It's not a comparison of old and new or more productive or not. It's that we're able to do things we would not have been able to do before in a way that we didn't really understand about how to interact with customers before. It's a whole new way of working. So I answered the question by not answering the question. Did you notice that? Position being the end of the line. So there might not sound like I think I'm supposed to answer. Right, definitions. So productivity and productivity. Productivity implies that the product, something's of value to some person. So we're trying to get to that point. Productivity is giving us an idea of the time that's involved in whatever we're doing. So going back to the early questions about agile, does it make any difference to this? I can't predict on the project using agile techniques, what are they doing with it? I can't have someone through that I'm not going to be years late doing something to consider other than that. So it gives me a great chance of delivering whatever it is that we will agree we're going to deliver without being too late doing so. There's a lot of unique story points. I keep pointing people to it. I do. And it's basically us looking back at what we sort of put out there in the world. And story points are one of those things. And we as group, we're all our customers for 70 years and then look back and say, no, is this really helping? Are these things helping us produce great software? Are they helping us produce the outcomes we want for our customers? Ultimately it's not outcomes, right? I said this one day that I was bragging. I was like, I'm really good at backing up my photos and videos. In fact, my daughters are great. My wife's great. We're all great at it. We're so good. It's the drop-offs that's good. We're just good because we use drop-offs. And stuff gets backed up perfectly, right? And I'm not worried about losing these memories. That's an outcome that drop-offs may be possible. Right? That is what we really go after. And if we look at burn-downs and if we look at story points and things like that and try to think of ourselves as being natural because we're doing that kind of new way of escalating, we're kind of often missing what we're really going after, which is the productivity, is the outcomes that we care about out there. And we also have to remember, there's a lot of legacy code. There's a lot of hazardous code bases. And it's hard to just snap your fingers and go, we took a strong class and now we're at it. And we can just be predictable. Well, no. You actually are sitting on a hazardous waste zone and you make really bad decisions in the past. And if you really want to start getting somewhere, you're going to have to face those decisions. You're going to have to do something real to deal with those problems. I don't see a lot of that in the modern and what has become Agile. To me, Agile now is a sprints, stand-ups, and story points. That's what the mainstream has become and I think of Agile. And I want nothing to do with that. I want to paint down technical that. I want to create great outcomes and I want really happy teams. And I don't find that that has got a lot of naive adoptions about what we're producing. So, I'm going to cheat. I'm going to assume they said everything that needed to be said about predictability and productivity. Can I get a quick census in the room since I haven't been here all morning? How many of you are working with Agile now? Is everybody else through enterprise behind the firewall on premise stuff? On premise, we are doing services, software services. Interesting mix. I think, I'll take my personal perspective. We started our company in good old times and moved over to Java, JTBE and started delivering of the web years ago and finally transformed it into true optical application. And it's been part of the journey. But I think the whole conversation of Agile delivery when I look at delivering software in the cloud, it's pretty straightforward. You have to do it. It's the only way to do it. We moved from one major release to monthly packs and a full quarterly release delivered to all of my customers immediately around the globe. Certainly connect to the kind of a piece of planning and we've gone as far as completely changing our whole enterprise roll-up process because you can't do it the same way anymore. So the classic ERP roll-out that will gather big requirements that will make it through six months, nine months, 12 months roll-outs you just can't do it anymore. And because those who've been through the days that went with the enterprise software you put the stuff up, you roll up the software, then you get back three years later for the big upgrade. It doesn't happen that way anymore. You see it arriving every quarter. New stuff's available in the software. How do you get it out? How do you get it rolled out? How do people take it on? How do you get them that stuff? How do you make them use that stuff? How do they get value out of that stuff? So they're remunerated. The business is completely different. It's real time. The stuff's happening continuously. They're responding continuously. You can't do it the same way. It's over and done with. So I don't know any other way to do it at this point. So I think it goes back to the essence. It's about being able to do things that implements, recognize that you want to respond very rapidly because the market and the competition is performing at that same rate. And what you need now, next quarter, what are you going to need to compete when somebody buys somebody's and integrates somewhere else and sells something else? Thank you. So I'm going to cheat before we turn back to people for asking questions. A great story about something to do with estimation, something to do with predictability, something to do with productivity. One of your favorite stories where you feel like, oh my God, this is just gone crazy. Florida, a great big company. They're monopoly. Thoroughly assess them. We thoroughly train them. One particular group is about 30 people. We have a perfect environment for working training in open space. We have main framework for working in America's job corporators to work with people all working together with product managers and project managers. Everyone about training. They ended up winning the chairmen's award for process improvement from the parent company and had this giant statue of all the managers from around the world becoming a tour of their particular area. It was incredible. We were really proud of it. And eventually I started working with other groups and these folks were using story points and velocity calculations and taught them all these things. In fact, one of the fellows on that project, he thought of the term nuts instead of calling them story points, he called them nuts. Nebulous units of time. And we had fun with that. But the thing was, they had a consistent velocity that was relatively consistent in the 50s. Low 50s. And their manager was an amazing guy. He was the first person to grace into this company. So he knew this stuff. He knew it after a while. But at some point he must have gotten some real pressure from above and he said to his team we need to go faster. We need to sprint. We didn't really know what's strong and what's bad. So he used this language. And they started the velocity started really increasing a lot all of a sudden. After a lot of consistency. And we were working with other teams at this point so we weren't really working with them. But we thought that they were very mature. Really, this was one of the most mature teams we've ever worked with. In fact, well, whatever. So I come over and I see that their velocity is up in the 80s. But they haven't gotten any of the people but nothing's really changed. And so I said to this one woman, how did you from the 50s just a few months ago up to the 80s? And she said, well, Josh, these days when you sneeze you get a story point. So this was one of the early sort of cracks in the armor for us of what story points are. And it just, it was just ridiculous. It was a total point inflation just to sort of show the manager that they're going fast now. Really nothing had changed at all. That's a good story. Anyone else have any story to share? Running around. I didn't really have a question. So the question is that do you have any story of estimation of predictability about productivity where people did something and we were like Oh my God, what a thing. Sure. We started last fiscal year with my son. We do enterprise class learning management system. So it's almost like a year to do a lot of things. And we've been competing with the company that puppet states on selling on the cloud premium model that sort of grew up in the SMB sector growing up. And a competitive story against us was that I saw a moment of big movement in the software. That's it. They would blunt that line and lock out the door. And the problem was the customer would do exactly that and of course they would say let me get the services people involved and the services guy business consultant, technical consultant one more guy or somebody else in the line would show up and we would say well we can't get the hardware out and by then we lost the video. And it would be like that for 6-9 months. It was all true, right? We would take that moment. But what we finally realized is that just like in classic waterfall development engineering our services were also the same way. Customers would start with us with these big requirements that she described. They would not really know what they want but just to get a project done and to define requirements so they could get it done. And it would take whatever time it would take. We actually went back and completed the overhaul. Our engineering team had already done 4 years of shifting from good old waterfall to just 4 years to make the full transition. About 4 years? Just about. Because it's about 4 full years to really transform the organization. And so we already had good risk to do that. So we worked with the engineering teams and we really said we are delivering on the cloud. Let's recognize something. It's no longer the same world anymore. Because you don't have to build in times of installation or performance tuning all that stuff goes away. And we overhauled that entire process so that we started doing rollouts and sprints. And we really just said you know what? Because it's the cloud you don't have to worry about what your eventual end game is. Just look for your first few roles now. So we started moving the customer culturally to say stop thinking about just what you mean now. We'll work with you to get the next one done. The next one done because we can stay in the industry. It's the cloud. We can keep changing this stuff as it goes. Because we could do that even in initial rollouts we do a 2-week sprint. Software comes up we have to use the stuff, load the data they can try the stuff out what they don't like. It's changing the next sprint. So the whole configuration process has shifted. And about 6 months into having implemented this, begun to roll this out and done the first few customers the productivity number for us was amazing. We used to have huge conversation with customers saying that big services bill is a mess. How will we ever get this done, discount this, cut it down. To the point we had customers saying that's your bill. Are you giving us a full implementation? Do you guys want to go back and rework this? And that was the difference for us. Our rollouts are most successful because the customer can see exactly everything coming along as opposed to trying to get all these big project meetings to assess where the hell they were. The rollouts are predictable. Everybody knows what's happening. It's simple. It's obvious the software is coming together and rising up in front of them. It just makes a massive difference. So I was working with a team that wrote tools for compilers and debuggers and embedded systems. And every time the project manager came in the team would say well we've done this before for a particular environment and we know exactly how long it took us for that one so we should be able to estimate this one. It should really be the same. We're really doing the same thing over and over again. It's just a different environment. And what they found over time was that their estimates were always wrong. Even though they had done it before that they were not repeatable and that's what they thought they should do would be repeatable. So when we switched to scrubs and we started being more agile I don't know what the difference was I don't know what the magic dust was but somehow not only were they able to deliver faster and they could measure that because they had done the same thing before but they were surprised themselves at how much easier it was not spending all that time up front. And so for that team it was a great sales departure for me to continue to work with the rest of the organization because this particular team had such a bad history of estimation. So I don't know exactly how to explain that. So to open the floor for questions anyone has questions to the panel if not I can continue asking questions. Going once it doesn't have to be productively or predictably specific if you have other questions for the panel feel free. Now look you had two days of me yesterday and all you did all day was ask questions so I know you can do it. Generally with Indian firms we tend to adopt the methodology or the kind of work we do is it mostly comes from the client. What kind of culture or what kind of work does the client want us to do and we'll do it. Now that's one of the reasons I mean I'm not saying of innovation or something new coming out in Nigeria or otherwise as well from the Indian companies. Now do you really think there's a difference when the capability of agile goes in the West and in the East and how does it culturally differ? Is that question clear or you want me to elaborate on that? No I know exactly what you're talking about. You're saying here in India let me just make sure I understand because I think I do. It's that here in India you're going to do it in the arts in whatever North America or Europe or something like that and play that style of game even if it's right or wrong even if you don't think it's what they need. Is that correct? So I've had people that have worked for me coaches that have worked for me who have actually flown here some of them were Indian and I worked with teams to teach them how to push back how to say no how to work towards a better solution rather than just doing what they're told. Because it's not something I think that is expected and so you just want to please the customer so you do what they say instead of trying to really help the customer figure out what they really need and that's a better way to work and ultimately you're trying to help your customer so just a lot of times as Linda said the customer doesn't know what they want the customer doesn't really know what they need so they'll say something and if you just listen to it you could be wrong you're trying to explore the space with them and figure out what they really need so I think that there's a great opportunity here to change the way we interact with these companies in North America and Europe to be even more valuable by really engaging with them to discover the really important things rather than just what they ask for. Since I go to conferences and I talk to people in companies all over the world there is a difference there's a difference between the way Agile is done in the US and the way Agile is done I'm not going to use India as an example I'm going to use Eastern Europe so Eastern Europe is the target of a lot of outsourcing efforts as well in Eastern Europe there's also an attitude of acceptance that we do what we're told if the customer wants X we deliver X but what I'm seeing over time is that that's how we all begin the beginning stages of Agile are sort of moving on the process we know what the steps are we go through the motions and that if we've gotten a hold of the real message of Agile then we learn over time I talked today about retrospectives and what I think the real purpose should be is experiments and that that should extend into your own lives you should always be trying something new and I think that if there's a real deep understanding of what Agile is all about by doing what somebody else tells you what to do but that over time you're going to get better and I have seen that happen I have seen changes in teams that I've worked with and I've seen them learn and I've seen them grow and I've seen them get to the point where all of a sudden now they're demanding more input more learning they want their voices to be heard and I've seen that everywhere in India as well as Eastern Europe unfortunately I'm going to be moving for a long time how many of you are from multinationalists? ok that's the problem I take that question and say it's ridiculous because we just had a conversation that's about 10 years old Bob Maddox started down the street they're talking the line I do every gap of technology you can they're in the cloud they're going at asset speed they're agile from the ground that wasn't even a conversation the problem is we're sitting in multinational back offices where we don't really do some innovation we just can't get any of what we do then somebody sends somebody else to train us and say well let's go do that then we spend days in conferences talking about how we can go agile outside on the street based on India for startups none of them are having this conversation they're already agile, they're lean they're moving at high speed they're contributing to GitHub they're building software that's going on very rapid pace there's a few right there I don't understand that question anymore let's ask in the context of all those guys sitting in the big multinational where they're comfortably confined to the big software services operations yeah you're having trouble yeah it's happening in our room I'll add to that an encouragement which is ultimately irresponsible for your own careers and you probably know this and sometimes it would be really hard work to do something at work but there are little things like the code of threes which happen in the international code of street tables last weekend you can go there for a day you can hack, you can pair programming and a couple doesn't even need to know about it that's a big deal, don't tell on the other hand you go back with new skills new perspectives and if you can't convince people at work that this might help them best if I do with a bit of an afternoon micro-experiment some work if you've got a three-week project spend a day on it see if you can do something that's useful then show me an example then really it's time to move and then maybe it's time for somebody to move on I don't know if I can do it but I certainly wasn't treated as a back-end what's other work to do it was much more an egalitarian relationship and that's what we need to have and I'd certainly see much more of that and have you been to the industry if I could just respond to that I think what's required is an openness of either side both from the client side as well as your organization to be able to speak up and say that this is something differently I could not say that you have clients and say this is how you do it and that's the end of the road because there are clients who are learning as well as much as we are learning how to do things the clients are learning as well so if you can have that collaboration and as Josh was saying in the morning you have to have that safety net you have to have that safety net where you can go back and tell your client what you are doing or the kind of background that you are saying you want to have or the kind of prioritization that you have done since we know about the technology we know how dependencies are happening we know that you cannot do it in this way so if you have that kind of a conversation and collaboration it is not going to be a situation where you say ok I just do what I do and I think it takes a lot of conviction to be able to stand up and make those kinds of I am just going to build on what you said there I well know the company but it is an international company with thousands of people here in India and it was simply your office in California and they were complaining that they couldn't get the support everything was going wrong the teams in India weren't doing these properly and they used to fly people out from India to the states all the time so have you ever thought of taking the development team from the US flying them to India for a while and then working there the teams will be there they will be available to you and you will be less impressed now that was hard to convince people to do but I encourage you to go to Suthya Nationals encourage them to do that bring them here get them to pair with you collaborate, treat you as equals because you are equals and if you are not then do something about your own skills so really find ways to work and collaborate with your own faith I want to slightly add a different perspective to this based on my experience if you look at the Indians of our industry we can broadly classify into four types of companies we have the startups very small percentage but rapidly growing and I'm sure no one would debate that no innovation is happening over there because I think there is hell lot of innovation happening there some of them more some of them less then we have the product companies which could be either like the Googles of the world with having offices over here or home grown product companies like the direct eyes of the world or the sabas of the world any of those which are home grown product companies and then we have two other things which is what we think the software industry is all about is the captives which is large, gigantic companies there are a lot of centers over here and then the services companies which basically are we do whatever you guys want so if you look at and there was a bunch of research done around not research but surveys done around how many of these last two categories of companies are actually doing agile pretty much everybody is it any good you and I would say oh that's horrible because these guys are manipulating this whole thing they don't even understand what agile is this is manipulating the whole thing doing whatever bullshit they are doing and calling it agile and I was of the opinion until I visited a bunch of them and I started seeing from their perspective you have to understand how their business models work they can't just be agile and basically fire all the people their business models operate quite differently the more bodies you can throw on the project the more money they make is that necessarily bad? I don't know maybe I would disagree I would say it's a bad way to do but they have put us on the roadmap of the software highway in the world companies come to India because they see the big giant companies building software and what was surprising to me was what I sort of good services companies small niche boutique shops they don't have repeating customers while these large gigantic companies have repeating customers they must be doing something right they must be innovating in some way for them to have continuous business it can't just be all crap and still making a lot of money so I think innovation is happening in a lot of interesting ways and there's a lot of juggard happening I think they're doing very interesting stuff they're taking agile, they're mish-mashing it with whatever they want and they're coming up with their own new flavors of things I think that's innovation innovation at a process level they're finding ways to make it work for them given their business model and constraints so I think that's what I think of it yes sorry you have a question or you want to add into this? I don't know yes we have here a question and then we'll come to you so my question is very much related to the same topic but slightly different twist when you work with an Indian client as a services company then a lot of times India is a big client base growing client base but what happens is that the customer is not as well educated as you would encounter when you're dealing with a US based or UK based customer so immediately what happens is that the first talk is how much it's going to cost we are also a very cost conscious market and you expect to give a fixed bid code so given the requirements whether they are very clearly defined or they are not very clearly defined they would say just look at this particular site and I want to build something like this how much do you think it is going to cost so the first thing comes to the cost the fixed bid model and then when the project starts that's when you are supposed to build it so from the customer side he's probably talking to 5-10 different vendors asking him to cost and then going with one that they feel most comfortable and with a less cost so as a services company you are once the project starts and now you go to agile you have you're always wanting to do a superb job versus the bid being fixed you may not have a lot of leeway so how would you get on to that because this hits the predictability that we are talking about so fixed bid versus agile what do you think I don't think they are mutually exclusive at all I think we all sit in India we sit abroad, we sit in India by the way, I think that Indian customers are not unsolicited at all we actually put them up with the American and Australian customers at least my market and the exposure we see but they are cost conscious people let's face it so we ask price up front and then we go from there but look, if you and I have a fixed bid what are we getting managing at that point we are making a risk to ourselves of exceeding that number and I can approach that problem two ways, I can try to get all these requirements sit down and then try to build it and discover it and you know what you are looking at as we heard or I build an increment and try to engage into the maximum degree possible to try to convert to an outcome sooner why wouldn't I go agile I'd want to do things in increments and say you like this okay let's go to the next bit you like this as opposed to go here for three months and then have it blow up on my face it's about risk mitigation that's the best way to do it okay we'll go there are you happy with the answer okay question to the panel in a manufacturing world it's very easy to measure the productivity because of the repeatability and all these things in the agile world and in the software world how do you measure the productivity and what kind of challenges you see what do you like to throw some light on that what was the question was how do you measure productivity and agile context yes software world manufacturing versus software manufacturing would be straightforward software is not that straightforward how do you deal with that in manufacturing because you have tangible products that you're building and it's essentially some kind of an assembly line so you could measure the productivity by number of units generated per time and that would be a measure of productivity but in software and especially agile how do you measure productivity I'd say it's it's a much more it's a much different game you could think that you have fantastic productivity but you have horrible knowledge of both silos and if one of those persons leaves your company your productivity is going to fall away completely so it's very difficult you have to look at a bunch of different dimensions you need to look at do you have really high quality requirements coming in so you know that your building is actually going to be needed do you have competent people building trained to be building good software and high quality software are you looking at the quality all the time and seeing that you have to be building high quality because if you're not, productivity is going to go down and we look at test code for example and the automated test to make that go faster that's the safety map without it we go slower and afraid to change code so you're looking at that many different dimensions this is the silos I guess Chris mentioned around that are you working in small batches you're actually producing tangible things that work versus taking on all the risk of hoping it all fits together even in the hardware space you've seen places where the mechanical engineer and the electrical engineer both integrate or don't integrate early and then they find there's a problem so early integrations continues to happen one of the biggest problems I find is the teams aren't even organized for success from the very beginning they aren't cross functional teams they don't work well together they don't even work together I was just talking to a gentleman before this he said we have our mainframe programmers and then we have our job of programmers for each good but when they have to integrate it's a mess and I was like well why don't you actually get them in the same room working together every single day when they evolve that's going to be continuous integration so are you doing something like that the bottom line is you have to look at all of the various risks of software development and take them head on this is what extreme programming did and this is what's something like lead start-up does these things they look at the risks and they really manage those risks that leads to higher productivity like that so when I first started talking about agile development a manager said Linda well we'd be better and I said well how good are you now on a scale of 1 to 10 are you a 5 are you a 7 are you a 10 and he didn't know because he had no way of measuring where he was let alone he was really looking for some serious answers for me let alone what I was going to be able to bring to the table if we started introducing some agile process so I have a PhD in computer science and if you kind of shake out exactly what my research was all about it had to do with metrics I was measuring design quality but in order to do that I had to do a lot of research around metrics and how I've been using software and what if you do that research what you'll find is horrifying because we do a terrible job of measuring just about anything in software in fact that's my top tomorrow is how poor we are at doing anything scientific that is looking at a measurable result for anything we make our decisions based on a lot of stories gossip we had no idea of what we're doing but one is to have a good productivity and a good latency so if someone wants something how soon will they satisfy that need so that might be a very pragmatic way of measuring it whether it's physical or software and I just said a house built and still 9 months off, 10 months off some bits aren't finished and some bits have just gone wrong so how do I measure and build this productivity and I've always backed out but in England it's colder now so my wife who's sitting there at home with no water is reminding me that it's not done the other part of this I'll feed into the business topic tomorrow is to look at a book called How to Measure Anything and the author is called as a surname and one of the comments he makes is that if you don't know how to measure anything at all but even a couple of rough measurements they probably give you a lot more information than you otherwise have and that's sometimes the most valuable measurement you'll ever get from going from no clue to some of them and it looks at 90% confidence margins so I'm 90% confident that it's between these two backwards so very productively like no clue had ever written out could I say with some level of confidence that it's at least this and most that once it gets to that point it needs to be refined and that's why we've got close to the answer to say okay we'll move on I'll just chip in here one of my biggest concerns with the word productivity is I think we've taken it out of the context in many cases right so we look at you were talking about hardware or anything that's manufacturing centric so we say okay number of units produced per time and that's productivity but notice that the units produced are exactly the same that's a problem we solved 30-40 years ago we have superb productivity if you talk about compiling code and deploying it it happens within minutes or sometimes within seconds so that's a solved problem for us the rest of it is a design process so we have to go back and look at how long they take to design cars is that predictable how do they measure things like that how do they take to design a new chip today we can do on wifi let's say you know 100 nbps can we go from there to 1 gigabyte and how long will that design process take we don't measure that in terms of productivity we measure that when we talk about assembly line and I think we're kind of fitting a wrong measurement or wrong thought process into something that it doesn't fit the other thing is I think we can all agree here that measuring output is wasteful but we should be focusing on outcomes so you could be producing a lot of software how does it matter what's the outcome that you're able to get out of it for all I care I could produce a one little thing and that could have a massive outcome am I more productive I think so so sometimes we need to go back and educate people in terms of how to think about this thing so stop focusing on output start focusing on outcomes and I think we would have a better discussion to have at that point I think there were two three people had a question so I'll go there she's been waiting and then I'll come to you sorry she has a long list wow in agile we always talk about teams collaboration teams growth teams success in my practical experience in an average team of five or six I have two let's say champions or masters and the other I have Irish performers is that a good or bad thing for a giant teams so I'll just rephrase the question so she's saying she is a team in which two people are champions are really good and then the rest of them are average performers is that combination a good thing for agile there's a lot of misconceptions that you need a team of all champions to be agile it also touches upon the evaluation the presence of agile teams because this is I think the question she's asking really is that on the one hand we say it's a team reward but then people are a military team I'm guessing you're challenged right now but it's an interesting pay for performance and compensation design problem so how do you keep a team resource yet you want the stars used to be how cricket teams manage to do it so I'm sure you could find a way as well for that everybody cannot be such an American there's just one such but I don't think this is an agile conference I'll be here for a moment I'll be happy to send you a product for you I would say mediocre players are and so it's the job of the team and the leadership to bring them up this is why we pair program this is why there's a group in San Diego that does mob program every day all five or six of them work together in front of a projector switching every 15 minutes who is at the keyboard and mouse do they have a need to be overclimbed right no everyone really comes up together and they are enormously productive unbelievable this is actually in these experiments right maybe experiment for some time doing a mob program with that team and see what happens you really are going to be better served if you can bring those people up training with collaboration and if it comes down to it what are the rewards there if there's a reward system in place to bring those people up that's wonderful it can be solved so I'm going to talk about the agile mindset which basically he says that we hold either one or two mindsets what people are whether you can label somebody and say that they have this set of attributes and they were born with it and that's all you can do about it the agile mindset on the other hand believes that well of course we all have limitations no matter how hard I work I'm never going to be Einstein I know that there's probably a ceiling on my accomplishments but we know that however good I am today I believe that if I work hard and I try some experiments I'm going to be better tomorrow so I think that we should not go around labeling people say who's mediocre and who isn't that we want to believe that everybody could be better tomorrow than they are today if we believe that they can because there are studies that show what you believe about the potential of the people that you work with creates an expectation that they strive to meet so if we believe they can't do it then that's the kind of performance that we get if we believe that they aren't able to grow and that they're able to learn then they do that so I think if we adopt the agile mindset not only for others but for ourselves that's the best way to serve our teams and I don't think there's any magic formula for how many experts or how many analysis as long as everybody's learning and that we all treat each other as though we can all learn that's going to get us the best performance I'll go through two different paths Sal Khan, the guy who's a good kind of captain has a nice little three minute video on YouTube and he points out that over the time Einstein couldn't count ten and he could just say well, he's gone there we go there's quite a bit of time maybe but nonetheless, look what happened with him the second is that when I code I code really badly and I have a degree in computer science and all the other good stuff I've written code at Google, it's in the main code base but nonetheless, when you stack it down today there's a program exam in whatever languages that I claim that that they could write in and I would probably fail your tests and I'll name two people one is Simon Stewart and one is Deb Narrison both happen to work with me at Google and both of them, when I code with them make me feel I can do it and they just remind me a little bit and ask a couple of questions and guess what, the code I write is significantly better than it was ten minutes ago because they had a nice little nurturing map so perhaps the challenge is not to look at the average whatever the heck that means but to say, how can we nurture these skills and maybe you're the average what we can find to you and say, maybe you're the average and maybe there's ways you'll find the nurture and the encouragement and that's what I think needs a lot of course I'm kind of backing up on those terms I'll again chip in here quickly sorry, not on the panel but chipping in all the time one of the things I notice is it's reality that you will not get a team of all eight players let's just accept that in fact I would say that it's better that way because if you had a team of all eight players you probably would be stuck with a lot of egos rubbing you'd be stuck with a lot of people arguing a lot of thinkers very few doers so that is also a problem in many sense so having this diversity let's rephrase this, let's put a positive spin on it let's say it's diversity one way of diversity is some people are pretty skilled some people have more to do and so you have these mix of things back to what the panel was talking about is now when you have this diverse group how can you engage them with each other so they can help each other to all improve all get better someone might be good at something someone might be good at something else can we find that nurture bonding and I think that's quite possible we've done that in a lot of places decouple that from appraisals to stuck with because if appraisals is what is on the mind all the time then it drives bad behavior I mean there's Daniel Pink's studies which talk about how when you motivate people by giving them financial rewards it actually reduces their performance it makes them behave badly it makes them do bad things so in my opinion I wish the diversity decouple the appraisals for it and if possible let people decide how they want to do like a 360 degree review or other kinds of things in terms of how they want to reward but what's important is to talk about these things openly so I've seen that help a lot of companies and that's what I believe we'll go over there that gentleman is waiting for a long time can you please pass the mic over to him and then there's one person in the back waiting so we'll come to that person there okay we'll come there yes so suppose you have two champs in a team and four are average so better to just pair these guys with the champs so fortunately the six champs will be there in future so in future suppose two champs leaves the company anyway she will have four champs so pairing will help in that way if not work then only we have to go that way I wish pairing did all the magic unfortunately it doesn't because you know so what I'm trying to get at is yes pairing is good I'm not disagreeing but I don't think it will turn everyone into champs you have to look at multiple strategies in terms of how you will convert people but you know sometimes letting the champs pair also is important so you know there's a good amount of research done in terms of how you want to pair people up and it's not necessary that you always pair a champ with a mediocre programmer or an average programmer you just let themselves select and it's good that way because they're going to build that and that's going to be more anti-fragile if I can use that term rather than trying to have this you know very dictated style of how people will pair but pairing will certainly help no debate on that and that's going to be the state forever in my opinion let's just accept that you will not have all champs one day all right back to the gentleman for the question I have a small concern over the medium velocity of the team especially in front I mean in one of your discussions Narish told you don't follow the results you actually try to adapt it so what I'm based on what I've seen is I mean calculate the velocity over the past springs I mean it's not it doesn't work out actually because every time you get new stuff to deal which though it sounds same it's actually not same right because there are a few aliens that are always new so my question is like how do we use velocity in terms of release coming we size up I mean the that's about a month release and then we divide that into iterations so my question is like theoretically we do use velocity team velocity over what we have done in the past but actually it doesn't measure up so what happens is like in case of iterations we give the freedom okay if this is not done we speed up put it in the next iteration what has happened generally what happens is the protocol based on what we have done in the release panel it's commuted to the customer and we have to do a release at the end of the day so that's a conflict actually because during iterations we do the stuff within a jive but at the end of the day it's like we are commuted to certain set of stories which we have we have to do in the span so there's a conflict and that's what I want to know you guys want me to repeat the question let me try and run my compression algorithm and see if I can bring it down right so if I were to summarize the iteration do your release planning based on your velocity so you said based on my velocity I can do in 6 months 400 nuts right and then when you get to your iterations you say well it's self-organizing all of that stuff so things can still lower and then you've committed to 400 nuts but you don't end up delivering so how do you deal with that problem is that fair? okay compression algorithm it just needs a lot I missed that sorry I see a lot people should see a lot velocity is killing agility right so if you google that velocity is killing agility it's put us on a completely wrong path in my opinion that people are just going crazy over velocity and trying to get you know the numbers up and as the panel here has talked about it's very easy to game that it's trivial to game that I mean kids my 5 year old 6 year old daughter can game that is just increase the estimates this question that you are committing something 6 month off so Sachin is asking is it a fundamental problem that you've committed to something for a big chunk and then you're trying to execute it in this manner Josh is ready I don't personally I don't think it's fundamentally wrong because if you think from a business point of view there are certain you know commitments you need to make I mean it's outside but what is in your hand is the sophistication of the features the sophistication of what you deliver and you can play around with that no one's going to come and catch you obviously you're not going to compromise on quality but you can compromise on sophistication that's a different way to look at it right so if your sufficient design I'm just using cars for now you're not going to work on heated leather seats in the first spring in the second spring you're not going to work on the room roof you're not going to work what you're going to do let me ask you what are you going to do what are you going to do if you want to deliver the car in this time period look for another job the framework the framework chassis okay but could you build me an entry on a car a car that actually moves but it's very primitive but it actually has wheels maybe I can't turn exactly but it has wheels I can kind of go under action I can you know what I'm saying it's up to us there we go it's up to us and then you're going to decide how to turn the thing that I see all around the industry with respect to the lease plan is that companies to dopping agile are not doing evolutionary design they're not building that embryonic thing first it works, it's very primitive and then evolving it they're just failing to do that so I mean that's the problem and you also can't commit to something and fix and stow what you're doing that's called the iron triangle everyone knows that the iron triangle is sculpt scheduled cost if you fix all three you are not agile there's no way that you're possibly agile what we need to do instead is to be able to so what Jim Heismann says in fact is sculpt scheduled cost is actually just one of the sides of the triangle the other side is value what value am I trying to do I'm going to do sculpt scheduled cost to optimize on value and then the other one is of course just quality because I can do all this but if I don't have quality then the company that makes the airbags for carts right now in North America is a big problem because people are getting injured by the airbags they're doing the opposite of what they're supposed to do they have good productivity there so the quality is not there so value quality and then the sculpt scheduled cost is a more agile way of looking at it so again you have to be on a literary side you have to adjust the lease plan I call it iterative lease plan every two weeks go update what you say you're going to deliver at the end of some large credit hours, three months, six months and by the way we like to do it if I have a six month release guess what I'm going to do I'm going to break it into two months two months, two months I'm going to have two internal releases of two months each followed by an external release out of six months and for the first two months I'm going to build the embryonic thing it's going to be tested it's going to have a good quality and it's going to be embryonic and then I'm going to evolve that and I'm going to evolve what I say I'm going to deliver in the full six months it's going to follow my experience in the first two months that is I'm going to manage the risks a little bit and again that's not going to be velocity there's no velocity in doubt with it we don't use velocity what we say is for every story let the team tell you how many weeks it's going to take one week, two weeks it's three weeks, break it up, make it small and that's I talk about that in my blog let's talk to some story books if you get to the very bottom row it's a very long piece I think the productivity is something I mean we cannot completely talk about productivity during this initial phase I mean I got the point we need to basically make it more elaborative over a period of time needs to be prototyping and that is possible when we have a stable platform and we are building on the top of that so what if we are trying to do a build-to-build product or you know something out of scratch in that case it's really important I mean having a constant velocity to me is a smell it tells you that people are gaming the system if it's not fluctuating then how are people so accurate in their estimates it just beats me whether it's a stable product whether it's some other product it's hard to believe that you can actually have a stable velocity unless people are gaming it the velocity is not a number you can't add subtract multiply and divide with it it's an estimate you got it by well God knows how you got it not only knows how most of us come up with some of these things that we use in estimates but they're not numbers they look like a number it's a 2 or a 3 or a 45 or whatever it is and we get carried away with that and we think we can do operations like add subtract multiply and divide those are estimates most of those are swag and we should start using something else instead of a number so that we wouldn't get carried away with them and think they really mean something they're conveyors of information that are no better than colors or t-shirt sizes but they're not numbers as soon as you have a number somebody's going to start doing things that are inappropriate with it like add subtract multiply and divide you hand that off to your manager and he says well how about can we cut it in half or can we double or can we that's totally inappropriate and we've been doing that all along just because the figure or the symbol we handle that thing looks like a digit of some kind and it really is not that's the person's thing and that is certainly not agile it's a slap that integer on a quantifiable thing that's just not it's meaningless so I mean we should spend a little time on mathematics here I was a mathematician before I came computer science it's inappropriate use it's like we put numbers on the backs of your sports teams I don't know what's the sport in India credit and people have numbers on the back 45 okay so it would be like saying what's the average on this team let's take all those numbers on the back of them it's that kind of operation it's meaningless so stop doing that is this building on that is why people talk about Fibonacci series for story for an estimate is so that you cannot apply mathematics on top of it it's a non-linear numbering system so you don't apply mathematics on it we just turn around and we say okay let's add all of these and take an average and that's our velocity estimation is considered harmful if you search for that you'll find a lot of people talking about how this is fundamentally flawed but before asking my original question I just have a follow up on this and I think somehow when we're actually scaling edge-eye this velocity concept gets pretty because as you're saying that and I agree with this because it's a physical term velocity if you want to gain acceleration you have to increase the velocity the point is when you do a relative sizing with the same point so if you're actually calculating velocity by adding all your points your velocity will be same but you're burning more stories by doing a relative sizing for example if you want to actually paint two walls to start with one wall you'll do a size of three but to again pay the second wall you might actually size a wall but in the same time frame you can actually paint three different walls so now you're actually painting four walls with the same story points so I think when you do calculation for velocity in terms of the story points that velocity will still be the same but now you're burning more stories so that's why when we're actually that's the town we're actually scaling a giant program level this is the concept I read about relative sizing when you do the relative sizing you still can't have the same velocity in terms of story points but you can burn more stories so what are your thoughts on this that's way too complicated who said that it's like in these savers they're talking about relative sizing scaling a giant that is programmable but when they're talking about when we are doing the relative sizing we're burning more stories so if you want to actually calculate velocity in terms of burning stories you are actually gaining velocity you're increasing your velocity in terms of burning more but if you're actually calculating velocity in terms of adding those story points you still have the same story points because now you have broken it down you should actually paint the ball quicker so you're actually sizing by doing a relative thinking what we've actually painted first at the first time I still don't get it guys it's late on Friday evening maybe we ask simple English questions in a short answer we're going to ask you a question my question was when Nareesh said that velocity and I agree with this velocity has to grow if you want to actually get acceleration out of it but then there's a relative sizing because I read it that's how it actually confused me relative sizing and here we are also talking about the relative velocity so you're back to the same question relativeity you know how do we develop velocity and having to accelerate guys it's a broken metaphor I think it's a totally broken metaphor broken we're as he said we're starting to dig ourselves into story points in velocity and acceleration when the issue is how do we produce software more reliably predictably by breaking it up into smaller pieces that mean something next thing that's it the rest is just methodologies to help you I agree with that I mean it's just the follow up because that's how it came to my mind my original question was a little different I think we need to pass the mic there are people very easy my question was actually related to ageing itself 30 years back this was an infant waterfall was a young guy where do you see ageing 20 years from now how do you see agile 20 years from now 10 years ago did you say 30 years ago it was an infant today it's a grown up adult while I think it's dead and buried but agile manifesto is 10 plus years old manifesto is just a little over 10 years old it's 11 and a half or something like that so there wasn't any although if you look at the roots of every single element in agile whatever the flavor is none of that is new it's all been around at that Craig Warman I think it was the only author I'm trying to remember if there was a second author wrote an article for either IEEE computer or IEEE software that took all those elements traced them back to some source decades earlier so what's new about agile is just the coalescing of all the ideas none of them are new the notion of let's do all these things together and call it something that's new but agile itself began or was instigated by a bunch of old white guys gathered in a ski resort and said hey isn't there a better way and that's not that old it was just a little over 10 years old so you're asking what would it be like in 20 years I think I hope it's going to be gone so I'm incredibly old and I've been in this business a long time and I've seen a lot of things come and go and I think agile will be one of those I can remember what the world was like before agile I'm sure I'll see what the world is like after agile and something new I'm going to talk about that tomorrow something new will come along I don't know what it will be so I can't you know Yogi Berra said boy it's really difficult to predict especially things about the future we're going to get smacked and put some caffeine so we have 15 more minutes I think there is okay there it is so I just had one comment about this velocity measuring I come from a manufacturing company a very large one in the United States and everybody is always asking this question how do you measure velocity really I think the question you should be asking yourselves is how do you become a software company that doesn't care about making that dollar meet every line of code you're trying to deliver value to your customer you look at an application like WhatsApp everyone in here has WhatsApp that's all on their phone I can almost guarantee they have like 23 developers and they've been at it for two years and they've made how much money and they have how many users per day deliver to your customer at the end of the day that's how you measure yourself that's what they keep saying up here how do you get your company to measure value in that way yep thank you pass there I think it's there one question other than velocity thank you okay we are talking about the azai but the transformation from waterfall to azai okay so we are passing a lot of you can say in the team a resistance from the team initial resistance and that might affect the productivity or I mean the team is it's very there is no role specific in the agile I mean there is no QA or a developer so that resistance is something we are observing initial resistance so what are the ways or how should initially we tackle that that belongs into I can't resist it fire and start over always the easiest way to go resistance to learning resistance to learning that's Linda's department I would say definitely fire them and get over I have a story about Kent Beck anybody know Kent Beck and there was a session where early on we were talking about XP and somebody said hey I've got a programmer on my team who won't pair program what should we do with him and Kent said fire him so I think that's a little severe I think you should be not asking the question is this guy worth keeping around because he pair programs are not that's really irrelevant we should be talking about value we keep coming back to that is he adding value and my story is of working with the 777 airplane where I was trying to teach people the aid of programming language and many of them were resistant that was the innovation at the time for that airplane and if we had fired all the people to using that programming language then that airplane would never have gotten off the ground because those individuals those resistors those laggards were the ones that had all the domain expertise if you had just kept the exciting innovators early adopters who said oh wow we get to try this new programming language there wouldn't have been a 777 that's the question you should always ask about anybody not just because agile is the latest buzzword and we want to move to some set of teams that have a certain set of practices that doesn't have anything to do with anything you're running a business or you're in a business and you're in a business to produce a product that has value for a customer if that person is enabling you to do that then you keep them around if they're not that doesn't have anything to do with pair programming I would just add the normal human tendency when faced with change is to associate it with loss so someone's coming in saying hey we're going to switch from waterfall to agile and people think gosh what am I going to lose and they're afraid of that they're afraid of that loss so really I find the job is to point out to them and help them understand what are they going to gain if anything and that means studying what they have today and then talking about what could be tomorrow one of the things we talk about a lot is stress there's a lot of stress in software development some people might think it's less stressful to do a whole bunch of analysis you know taking your time and that analysis and then that design but you could find ways to point out that that has its problems too stress to the company when they deliver the wrong product so if you can help people learn how the change is going to benefit them we find when we help companies adopt test driven development and refactoring and things like that the quality goes up the defects go down dramatically life is less stressful at work it's better, it's a better world why would they resist that and be enjoying yourself so I think part of it is education around how it could be better coming back to pair programming and that comment from Kent Back I've seen companies where they say it's okay don't pair and the rest of the team pairs and what they do say is one thing we're going to do though you don't have to pair but we're going to track defects with the code written and I know in one case there was a fellow who started to get pretty embarrassed the defects and most of them are coming from him and the rest of the team were pairing so eventually you know what happened he would walk up to people and say I want to pair they don't have to do anything to get on that so there are more generous and gentle ways to approach that let me add some serious comments I think like velocity and acceleration getting bogged down story points or like the conversation we were having earlier about having a team but compensation is a different topic in this context let's not get hung up on the fact that in agile we're talking about teams and a product owner and everybody is equal it has nothing to do with their titles and the hierarchy we have in the company don't mix the two which is the big problem you have when you begin to start having conversations everybody is equal it's all a cumulative effort there's no longer a lead and the lead goes what I got demoted so don't mix how you're structuring for a management structure for overall people management don't confuse it with how you're delivering product and I think that's the key I can't imagine that it's difficult I can't imagine that anybody works in this industry anymore today and says I don't want to be agile I want to stay waterfall which idiot could do that it's a factor of life the issue is not coming from that the issue is going to come from I was the lead I was running these guys now I'm not running these guys what does that mean if you take away my lead title so you've got to manage that bit of it and make sure that element of what I got demoted did I have a lesser goal now is taken away so don't mix that with how you organize the team diversity is very important one of the things I remember I used to be what I called so I would go into companies and say okay these guys don't want to prayer these guys don't want to come and sit at the dining tables with the rest of them they think they are like some uber big shots let's just fire them and that was me maybe 10 years ago and when I was in the US working for a company I had people who were much working many more years than how old I was so I said well these guys it's going to be extremely hard to change them so it's just better to get rid of them and get a bunch of young guys who are more adaptable more willing to change and will embrace everything I have to say but then obviously you can't get rid of these guys because each of these guys hold 50, 60 patents you go into their room there's a wall filled of patents and they look at a bug report or they look at something and they'll tell you exactly which line where it needs to be fixed in vendor products and stuff like that they've spent so many years they have such deep expertise but they think it's a waste of time pairing with someone else because it will slow them down it will get in their way and they've been used to certain ways of doing things so what we let them is just let them be themselves so that they can do what they are good at doing and then gradually find opportunities where you can spend a few minutes pairing with them or talking to them and then gradually pull them when I left two years later everyone was on the tables obviously the immediate first few three months was like no one wants to even sit there it was just me sitting on the table nobody else right so you have to give people time I think they will see the value but not have a knee jerk reaction and say well let's just get rid of them one last question I think she's been waiting for a long time so can we get a mic there I'm sorry to ask this question on a Friday late night because I think this may be a tough question how do you bring agile when you have to give algorithms like what I understand if you have to deliver a software we can do a smaller piece first with not much fancy things so we just give a smaller piece first to the client then start adding fancy things in it but if you have to deliver algorithms surprising solutions for I would like to take a small example suppose you are an insurance company I mean your client is an insurance company and you are giving a very fundu algorithm to them which would basically give them what at what rate or what premium you should take from the client so that you don't go for a loss but at the same time if someone some mishap happens with someone you are able to pay back the money so say today you come up with an algorithm you decide that your insurance premium will be 10 rupees per month can we paraphrase the question can I play it back to you you are asking how do I where you have reasonable features I can pick out the features where it is a fairly interconnected indivisible whole like a complex algorithm of architecture that are heavily interacting how do you really lay them out and how do you really partition the stories yeah I have worked with lots of companies that do algorithms that make algorithms and what we do is we get them to understand that they can work they can first create the generic the easier version of the algorithm because there is always going to be the corner cases there is always going to be all the complexity that you add there is always the easy insurance solution right what is the easy case this is a simple case there is nothing complicated you build that first you not be not ship that but in the first week of development you have got it up and running with tests now you say what is the next most important thing that I add and you add that in so you can start this way I had one company they literally said to me the algorithm guys in the company they love to sort of work on complex algorithms that can handle any situation and they will spend weeks and weeks and weeks building them in fact we don't even need all that fanciness we need to actually just solve a couple of problems first but they enjoy this because it is a challenge and so we had to work with them to get them to pull back and just focus on a simple thing first and then add to it over time so it really is the same thing as software development features start really simple, solve that and then add sophistication incrementally that is how I see it I mean it usually boils down to the same concept I want to mention one quick thing that I forgot to say we talk about productivity a lot in this discussion the biggest productivity gains I have ever had that come through practice you won't read about in the scroll I started calling it bargain hunting many years ago given a story on the backlog a lot of people do this they estimate it and they build it that's it what we do is we take the story and we say huh what are the variety of ways that we could potentially build this hey what if we gave you 80% of what you want because we could do that in 2 days instead of 2 weeks and we look at the quality of our bargain hunting by the number of ideas rejected how many ideas did we consider how many implementations we could consider and reject before choosing one right that can lead to enormous productivity gains by maximizing the work not done figuring out what not to do figuring out what could be sufficient as an early version that we could then extend later and do all that fancy hard stuff that adds enormous productivity gains and it's something you ought to be doing bargain hunting imagine any algo person telling me that they will build the whole algorithm one shot algorithm designed by nature is iterative and incremental I don't know any single hardcore algo guy who will say I build the whole thing one shot when they always do it in iteration they have test data they run it against it and they say whoa it's condition now I'm going to improve the algo so algo design I think by nature is iterative and incremental which fits very well with agile but you're not going to go ship it out but at least you can build it that way alright that killed the panel that's the last question thank you guys for saying and thanks to the panel for being such a wonderful sport on a Friday night