 Okay great to see a lot of familiar faces. I think we're getting more and more familiar faces every time we have this. Just a quick show of hands. Who's new at Product Tank? Who's like coming up for the first time? Okay still about 50% of the guys. Alright awesome. So I'm going to quickly just tell you guys a little bit about Product Tank. So we started in 2010 in London and as all the great ideas start, they were started over drinks where a bunch of product managers have said we need to do something for the community. So that's basically how Product Tank started. In six years it's now in over 100 cities with over 30,000 members and we'll tell you how you can take these involved in the community. So the community basically has meetups. We have Slack channel where a lot of people will help you out with any product management issues that you do have or if you want to get introduced to people so you can join that. There's a Mind the Product blog and we do have conferences as well. So if you want to join this Slack channel that's it. If you want to write for the blog, write up to the editor and we also do have a weekly newsletter which is pretty cool. You can sign up for that and we do have jobs available on the site as well and we have a community so if you guys are hiring you can post up your jobs out there. Finally, once in a while we do have product conferences. The last one was in London a few months ago and we will know about the next one shortly. If you guys want to join us for Singapore, that's your link, bit.ly, Slack Product Tank. It takes you to the Facebook page which is where we have a community and we announce fallout events. That brings us on to tonight. We're actually going to be having a panel discussion. This is the first time we're trying out this new format. Hopefully it should be very interesting and it actually started off because there was a conversation going on about Agile a couple of months ago which ended up having a lot of very diverse views and that's me saying it at my diplomatic best. There was no blood on the floor. Yeah, there was no blood on the floor. We have a pretty good panel today. We're going to be talking about Agile software development because there are a lot of different companies in Singapore which either use it, don't use it, they just dismiss it because it's too complicated or they just don't know how. So we're going to be speaking about that and the panelists are going to be Jordan, he's right here and do you want to take a spot, Jordan? We're going to be sitting right up front. Jordan's the VP of Engineering at Trade Gecko and Jordan's been working in tech since before most of us in this room were born actually. Lay down my first line of code in 1981. He's worked in Apple, he's worked at Yahoo, he's currently at Trade Gecko and he's got some great stories so you guys can catch up with him after that. We also have Nuno who is a veteran, he's in the FinTech field and I used to work with Standard Chartered Bank and he was telling me earlier on about how they rolled out Dash together when it was still awesome, when Dash was awesome. So presently Nuno is at PocketMap and finally we've got Varun. Varun is with Lazada right now and Varun is also partially the reason why we had to reduce everyone's pictures because his designation was very long. Jokes aside, Varun has actually worked with Lockheed Martin in the past which I thought was incredibly cool. No, Nuno is with Lockheed Martin. Sorry, okay. I didn't know you did that too. You should have flown a plane. Nuno has worked with Lockheed Martin and Varun actually has done a lot of payment systems and he's presently at Lazada, alright? So on that panel, I'm Utham from Yahoo and I'm going to be the panellist where we're going to ask questions. So the way we're going to go about this is we have a few questions that we're going to be asking the panellists about after which we'll open it up to a lot of Q&A from you guys which we certainly hope there will be a lot of. Okay, so... They're wrong. They're just muted. Oh, sorry. Dude, there's a less number of people. Do we need a mic today? Can the last one hear it now? Let's just keep a mic. I think he wants to record it. They want to record it. Anyway, Jordan doesn't need a mic, it's fine. Yeah, Jordan doesn't need a mic. Okay, so I'm going to start off with Varun, okay? Because once it gets to Jordan, it normally... Stays with him. No, no, no, because once it gets to Jordan then people will be slightly quieter. So we're going to end with Jordan, alright? So Varun, in your view, how would you describe the state of Agile in Singapore? What do you think is going on overall out here? And especially focusing on Singaporean startups. Not like the MNC companies out here which pretty much all of them will practice Agile. What are your thoughts on that? In my experience, I personally feel in Singaporean startup they hear a lot about what Agile is and they're building blocks required for actually running a real Agile organization. So you need developers with certain skills that you need a level of motivation, this specific requirement. So the traditional developers like these are developers, these are Java developers, this is QA. That was the old structure in Singapore. So a lot of talent hasn't matured to the level that they can handle the way Agile works. And just because it's cool, it's funky, it's fashionable, every startup wants to deploy it. And that delta causes a scenario where neither can they get the best of either world. Neither can they do Agile properly. Neither can they do Waterfall properly and it's stuck in the middle of the world. And that's a challenge. So that was the whole way where the conversation started, that challenge which we have. Okay, I don't know how about you. Well, I don't know if I can speak so much to how I see the situation in startups in Singapore because my experience is fairly limited. I've worked in two, including the one that I'm working on now. And when you hear of our own talk and I was thinking about what I was going to say, I'm probably going to say something very similar to that because the experience I've had with startups is being that most people don't know how to kickstart the process of implementing any kind of agility. And so they follow the cargo cult, they drink the Kool-Aid, but they don't really know what's behind it. And that's being typically the problem that I've seen. I've seen it once at Fusion Garage, which was one of the startups I worked with. And at PocketMath, we're still sort of trying to figure it out as we grow from an early stage startup to a larger startup. Things get complicated very quickly. Now, what I have seen, though, is in larger companies, so I know this was to be focused maybe on startups, but for MNCs, ironically, I've seen better response. And I believe that part of that was because those companies with the right environment, which is a big if, actually have the necessary discipline and let's call it management overhead at the beginning, at least, to get things going and implement the processes the right way and then start learning from them. What I do know, though, as an agile proponent in the country, ever since I started, so I started around 2008, it's been growing fast, really, really, really fast. It went from you can't find a person to teach you scrum to you can't kick a rock and not hit somebody who wants to teach you scrum. So, yeah, well, some of them are really, really good. I'm not sure I haven't tried them all, but I've tried a couple, and at least those were really, really good. So I guess what that means is that this is getting a lot of traction and people are at least observing some value of it, even if it is just from the fad of it. And if at the end of all of this, and it's all said and done, if at least some of it has caught on and has become mainstream and, you know, talked people a better way to work, I think then it would have been worth it. So I'm going to talk on kind of three levels here. One is actually I'm going to speak globally and then I'm going to speak in Singapore and then I'm going to talk about the startups. So first off, I'm going to make a very strong statement here. I don't think less than 10% of people who say they do agile worldwide actually do agile. I think one of the big issues is that people don't understand why to do agile. I'm a big proponent of first principles and understanding first principles. And one of the things that agile is rooted in is an understanding about the nature of software development. That software development is an empirical process. But what does that really mean? Do people really understand what that means in their gut? And you mentioned cargo cult. You know, if you haven't read Richard Feynman's cargo cult science paper, you should read it. It was a graduation address at Caltech a number of years ago. And what we see is a lot of people who are taking on the forms. And they say, oh, well, we do... I go to the places that say, oh, we do agile. And I walk in and I go and I watch them and they get up and do a 20-minute stand-up with five people in the group. And there's no board. There's tracking of issues. There's all these things that just aren't there. And so I think less than 10% worldwide are doing it. I think that your balance on the MNCs is correct. I think that the trouble is is most of the startups in Singapore don't have experienced staff. They don't have people who've done this before. By and large. They get a statement there. They don't understand why they... They just know that waterfalls bad and they shouldn't do waterfall, but they've never experienced the pain of waterfall. They've never been in a project that went 25 months over schedule. That was on a six-month schedule. They've never been in something that was supposed to take six months and took 30 months. So they don't know the pain. They don't understand why they should do this. They understand that all the cool kids do agile. And so they do this thing called a stand-up. So we'll do a stand-up. And that's the problem. Go back to first principles. Understand why you're doing it. Okay. So I'm just going to get to the audience right here. Just out of curiosity, how many people in this room actually practice agile? So 10% of you practice agile. Wow. 10% or 10% of you. So one of you. I think there's lines. There's lines. Just a few people here. But other teams in this room who are thinking about agile, like overall, or not even considering it. Wow. Okay. Are we in the right place? So going back. Sorry. Can I just ask Jordan? You made a rather assertive statement there by first principles. The question then I'm asking would be, what do you think agile is there for him? What do I think? As a software engineering practice because all... Well, I think, well, first off, I think agile is an appropriate methodology for any empirical process. Okay. Which might include pharmaceutical discovery as an empirical process. So I would say, first off, you know, I think it's understand the nature of processes, understand what defined process is, define what empirical process is. And then understand, and then that gets you down into kind of operations research things. And that gets you down to the fact of an empirical process lives and dies on feedback loops. And how fast and how quick those feedback loops work. And you know, so that, you know, this kind of just gets you, you know, you just, you walk through it and then you start understanding why this makes sense and why you would do it. And then you understand how that maps into the practices. Okay. And you know, that's what you're going to be doing there. So does that answer your question? I know, I know. So, you know, coming back to, coming back to what Nuno and Bernadette earlier said, you said that one of the issues is that people that start up don't know how to do our job. So what do you think are somewhat like the biggest blockers out there? Is it knowledge? Is it because they don't have the people in there? Is it just, they don't have a need for it? Convincing that it needs investment to the CFO. Okay. Because you pay peanuts, you get monkeys. And with monkeys, you run circuses, you don't win battles with monkeys. Okay. And unfortunately, the fact is, if the people who actually do understand how to do it, they would command a price premium. And that's a bottom line. It's a fact. It will command a price premium. And to explain to the finance guy or the CEO who has to sign the check. And if, unfortunately, that guy does not, has not come from a technology background or who hasn't seen that pain of waterfall before, to explain him why this person should be paid 40% extra or 30%. Because that person will be commanding that number. Because he has that skill set. And to get a buy-in from your own team to do that investment. And to accept that it will slightly take longer to set up the team. And this is a different approach. To get that buy-in is tough. Okay. Your thoughts? Similar? No, not quite. Well, if I try to put myself into our own shoes and maybe with some of the exposure to UVAT, I can see how that's an issue. Maybe I've been lucky and I've worked very deeply with technology companies. And so the not understanding of the investment doesn't tend to be a problem. But I think even when the investment is there you still have a lot of issues. I've worked in more than one place where the investment is there. But there's a mismatch of expectations. Unfortunately, when people start trying to practice any kind of agile methodology they think it's going to be easy. They think it's all just going to be fine. You know, we'll just get together, stand up once a day and put some post-it cards and move them around. That's all going to be okay. Send guys to a two-day workshop and the magic will happen. Yeah, no. It's actually the day that I suggested my company to embark on a scrum transition was the worst day of my life. Because I went from being a product manager that does one PRD a year to a guy who has to be churning out user stories every day. And it was a nightmare for me at first. I couldn't believe that I got myself into it. But that's just for the product guy. For the engineers it's a little bit different. And then they don't believe that they have to actually consider things like continuous delivery or continuous integration at least or automated tests. There's all these things that people just take for granted and don't appreciate. So I think a big part of the problem in any company not just starts with any company starts maybe a little bit handicap because of lack of experienced people. I don't know maybe investment could be an issue. But it's mostly because they don't understand the level of discipline that it's going to take. And I have to say when you see a discipline startup invest in them because they will be a very good company. But most startups I know of are by definition undisciplined. You guys set it perfect. Okay, so I'm just going to add on one last question on my own before we go to the next one is is there a particular size of operation that you think would require agile like so if a company is at a certain particular stage or the product that they're building really isn't that complicated maybe it just doesn't need it. So I'm talking more in terms of the benefits of it. So here's the reality. When you have three guys and a dog in a garage they're practicing agile they just don't know it. Okay? They're constantly talking they're talking to the customer they're working out the issues you know the dog's giving its input you know. But that's the reality. What happens is there's this transition that happens where you cross into oh we have 16 engineers and but that's overhead we didn't used to do it that way I just talked to him and he'd tell me and we made it happen. It's that point it's that inflection point when you're three people you know yeah you're doing it it's when you make that inflection you still need to do it you need to do it but now you have to become thoughtful about it you have to be intentional you have to be deliberate you have to have discipline I mean to say when people say well you know could we just do a stand up twice a week? You know does he really have to give us detailed stories with acceptance criteria? You know or conversely do I really have to give you that? Can't you guys just kind of figure out what you're supposed to do? And the thing was because you went from this this working relationship you know I was talking to a CEO of a company the other day and she says yeah I just can't understand we were so much productive when we only had six engineers and I'm like at one level yes at one level you know but that was you know kind of the thing awesome thank you so if you guys are tweeting the hashtag is product tank sg you can tweet about the three engineers of the dog he's at the service alright just keep the tweet sweet it's alright okay and the dog's responsible for continuous delivery I thought it was described could be alright so moving on to the next question and this is more about waterfall driven industries and companies what is the biggest argument to change the minds of the people and persuade them that agile minimizes risk so if you're alright and by the way guys if you guys were here a couple of months ago this is where things get really interesting so Barron you have talked about waterfall and if a guy loves alcohol all the cigarettes you buy they have this cigarette smoking is injurious to health that never dissuaded anyone from smoking so I personally don't think it's the job I mean we need to worry about trying to explain and like trying to evangelize and the problem is the evangelism also creates problems because the thing is there are enough people who want to do it but they don't know how to do it well let's focus on them let's get them right first there would always be some non-believers let the non-believers be there there are more bigger problems to solve and because see if for some companies order is more important so they have a structure and they say we get it it's not as productive but we earn money that lack of productivity is our source of revenue if you are an IT outsourcing company and your revenue comes by billing hours you care about the number of hours every time there is a scope creep you are happy every time there is a CR you are happy and you want to ensure that stays so try explaining that to Infosys or TCS that's their bread and butter so just to add on to make sure this clearly for everyone out here are you just saying that waterfall is for inefficient companies no waterfall works in the scenario so the question is what are the incentives if the incentives are billing hours so they are different right who is the one executing it if the execution person is an outsourcing firm who is going to be paid by number of billing hours not by the product delivery so there is consignment delivery and billing hour delivery if it's this is their product and we agree that it's 1 million and you guys develop it if that's the case then that guy has the developing arm has an interest to be productive but if it is this is the scope and let's see and you can raise a CR and all that and it's billing hour then that guy doesn't care he wants to maximize the billing hours his KPI is to maximize the billing hours it's in his interest to not optimize it okay so just to be to say the question again it's basically for companies and organizations that are focused on waterfall how can you persuade them on to Agile and what we hear from Byron is for all companies it might not even be necessary for them to be on Agile because for some business models waterfall just works better you know I I think you know so the business model is an interesting one I was thinking of the situation where I started embarking on becoming an Agile fanboy which was one where we were working on waterfall and this was with Lockheed by the way so we did we did enterprise software for logistics and we were in this habit of releasing software every 12 to 18 months and there was more than one occasion where we actually released software before the PRD was actually signed off anybody that never happens right I mean of course unfortunately happens more often and we'd like to admit but basically what would happen in that company was people would be fighting amongst themselves you know the business units would be fighting amongst themselves about who gets what requirements into the next release to the extent that the engineers feel held the product and engineering team was held hostage okay well we're not going to have people just twiddling their thumbs and you know being the cost center so we'll just keep on doing what we know needs to get done and you know there was more than one occasion where this happened and it was just untenable so I came up and I said hey you know we should try this agile stuff that particularly scrum I hear a lot of good stuff about it there's here's this paper from Pete Deemer and this Yahoo person who said that this works out really well and everybody loves it and that was actually what it took to convince people that get moving to a smaller iterations something a lot more iterative and you know smaller commitments faster delivery that is probably going to get us further along the way and we went from 12 to 18 months to a delivery consistently every three months and we went from sales team saying we put up requirements and we don't get them until 18 months later to guys slow down you're delivering too much I can't keep up and I can't tell my customers there's all this new stuff coming up so I think companies that have these kinds of environments where things happen relatively quickly around them and there's you know maybe there's a lot of infighting and you need to be flexible in how you approach the production pipeline then agile works really well because that's what it's designed to do it's designed to be adaptable and be dynamic and so you can swap some things around and in the long term the cost will be more or less the same you know last time we had this argument about in the short term how does that work out and of course you can't you can't walk away from things that you've already committed if you're going to throw that away that's wasted there's no way around that but so that's one area where I think agile will definitely help out even in very large companies however the type of business is important in the counter argument to what I just said is companies like NASA you don't hear NASA doing too much of agile development in fact probably NASA is only the only company that actually does waterfall right because they spend months and years doing requirements studies and figuring stuff out so that people don't get killed while it's doing the space well the difference is you know space doesn't change very often right the laws of physics don't change very often so they just have to figure it out in simulations as before they actually build the product and then try to put that poor guy in orbit so places where there isn't a lot of change in the environment whether internal or external don't necessarily do the agile but everywhere else I've seen tends to benefit from an agile approach so well first thing I would do is I always tell people actually go find the original waterfall paper that was funded by ARPA the advanced research projects administration and read the last paragraph of the paper about where waterfall is suitable it's eye opening I'm not going to tell you go find it read it homework it's an exercise for the for the reader can you repeat the paper please so it's the original paper in 1968 funded by the advanced research projects administration of the United States government what was before DARPA the thing that funded the internet actually and it's it was a research paper software engineering on where the term waterfall methodology was coined and talked about the methodology and where it is suitable it's not related to Fred Brooks Fred Brooks quotes it in there only that you can find the quote in there so first off go read that and also take a contention here actually NASA does do agile they do it in their simulators no which is the best thing for them write it down but they're actually doing it so hardware people with their hardware simulators do agile do you think they just design this thing and throw it in silicon and ship it no I almost used a word they don't they simulate it that's iterative that is iterations and it's why do we build faster and faster hardware simulators so we can iterate faster and faster you know so that's the other thing is I will ask someone who says oh well you know too much risk and I'm going to say okay when's the last time you put a stake in the ground and said you would be doing something in 24 months and you were actually doing it in the business world can you name me you know I mean companies that have rolling forecasts that change every quarter well but they actually change in the middle of the quarter because we do a mid-quarter rework and you know everything I mean come on none of these people I beg you find me someone who's puts a stake in the ground and says 24 months we'll be doing this who's actually doing it and then ask them okay well in that case do you really want what's going to be delivered in 24 months to be baked and decided now that's the bottom line I remember you raised an example I think in a previous time speaking about Microsoft when Microsoft had actually gone and said that they're going to do this 24 months later they did deliver that 24 months later but the rest of the world had moved on you know I remember that example coming up so coming back to random the question right here and just to make sure that we got everyone's views properly out here so what do you guys firstly does everyone here believe that agile minimizes risk as opposed to just building it anyway like waterfall all the way any yeah I do think it minimizes risk for sure okay as well see again depends on the scenarios where it creates more risk because for example again when you have when you have your in-house development teams is very different versus when you have a mixed hybrid or a fully outsourced development team because the outsourced development team guy needs to hire people he needs to maintain all of it so he will ask you for a retainer up front that I need because we need to agree that my guys are going to be in job for next two years because I'm going to train them you want them to do Android programming on blah blah blah skill set I'm going to invest this much so I want a two year retainer contract what these guys will do can be negotiated but you need to accept that you are not going to change the frame because you are not going to so he will define some pieces some pieces have to be fixed and probably for 24 months or 36 months because for those longer maintenance contracts for example a bank mainframe contract is given when IBM gets a mainframe contract from any telco or bank it's a five year contract in one shot as a few million dollars and there they commit that we are going to commit X resources with X hours and this cannot change however they define that these things can change a fully agile version doesn't work in a lot of scenarios so there is I would say like a hybrid version where you accept these things we accept will be fixed we commit up front and these things we are okay to change I mean maybe you can count it that this is agile but I think you can actually approach that the outsourcing model in a different way which is I want to hire five developers which is actually better because how many times have you you know dug behind the curtain of your outsize firm and finally they've been shifting people around behind the other scenes and you're wondering why the code quality varies so much from week to week absolutely but there are times when you cannot do that and then the company would say I'm taking an accountability and if the person leaves does it mean you're not gonna pay me I'm replacing the person and you say oh the next developer you hire I will interview no no no you can just say I want five developers of this caliber and they're dedicated to us these bodies are dedicated to you I mean it's saying I'm gonna give you what you're saying here is I'm giving you a short term employment agreement a fixed employment agreement but you have to look at it differently I think one of the things that happens in agile like acknowledged uncertainty climbs dramatically and I underline acknowledged uncertainty because the fact is the question I just posed earlier it's completely uncertain we don't know what we're gonna be doing in 24 months you know we don't even know if we're gonna have a job in 24 months that's the reality but we tend not to acknowledge that we tend to like pretend that's not true and we don't talk about that elephant in the room but when you go to an agile and you really embrace it your acknowledge your level of uncertainty you know telling me well how many tier one features is that team gonna deliver in the next six months and I said define a tier one feature for me you know I started pushing them back on an incredible level of uncertainty because that's the reality the challenge comes is there are times when a partner will say why should I commit X amount of resources for you if you're gonna just decide to shut down the project notice and this is the problem and you have to give me at least a minimum X amount of commitment most outsourcing contracts have a minimum commitment which is at least 12 to 24 months minimum and I have no problem with that I'm just saying let's do it up front let's be honest about what we're doing you know which is I'm giving you you know it's basically what you're saying I'm giving you a short term employment contract of up to 24 months with a notice periods of six months I mean you know you know I think what we need to do is say how do we change the business agreements I also think that when you outsource work when you outsource work I've really come to the conclusion that what I want to always see is an RFC you know IATF level RFC type document that talks about what is expected in terms of the outward behaviors but I don't care well you know if you want to have chipmunks running on treadmills doing it I don't care you know just make sure you know you actually support you know thoughts in people's names so they are effectively a couple of different ways in which you can outsource one of them could be that you say that this is the project this is the end outcome I want go ahead and build it out to these specs so alternatively you can say this is the caliber of team I want and I want these many people with me for this long so if you guys are thinking about outsourcing you know it's expensive in Singapore it's scarce it's scarce it's expensive and if you are trying to build a south east pan south east Asia product it's I mean these guys can speak better because we accepted the fact that we cannot maintain a development team in Singapore we cannot find and we cannot find enough we outsourced 90% of our development to Vietnam 90% we are like only two guys left and that's like it keeps on leaving in Singapore to them so these are the two left when they leave then it would be zero and everyone else is in Vietnam don't tweet this about Lazada alright so a couple comments there first off we're not talking about expensive headcams we'll talk about expensive headcams and silicon valve expensive but the other comment when you outsource you need to look at the total cost okay I I will I when I'm asked to do Tech2Diligence for a startup company and I see that the engineering team is essentially completely outsourced I raise a red flag I just raise a major red flag I say this is a major risk and I'll go into why it is a major risk because it is because the fact of the matter is there was one I did a Tech2Diligence recently and the the development team had never met the product people face to face okay you know you know it's just ridiculous I mean that even if they are practicing agile they're not because of the level of interaction that's not happening that's not happening and that's just a horrible risk you know guys go out we've got the number 9 CS program in the world here we've got the number 14th in the world here we have two fine programs at SMU and SUTV go out and reach out to those students start working with them now start bringing them in give them real internships okay trust me a lot of these people are not going to want to go to the US this coming summer okay no I'm serious I'm serious friend of mine family Asian-American their windows were etched with swastikas oh my gosh okay it's it is scary I can tell you a lot of stories that I'm hearing from my friends that are just I'm terrified I'm terrified okay so moving on to the next agile question we'll see it later Nuno this one's for you alright you've been quiet for a while moving these guys he's here as the buffer between for two minutes alright teacher placement thank you it was thought of when okay let's talk about the cons of agile alright so Nuno in your view followed by you guys is are there any functioned organization industries other than the one that you already mentioned that should refrain from using agile and opt for alternative methods you know that feels like a trick question but I'm going to say no I honestly don't think so so if it's not obvious by now my preferred agile methodology is scrum and if you know anything about scrum you know that the the founders of that movement have been trying to prove that scrunk is applicable to just about anything you want to do in the world right from hospitals to architecture to I think the only thing they've been staying out of is civil construction but everything else is fair game so but so I haven't found yet a very good example of place where agile wouldn't be a positive outcome even the ones where the environment is fairly static like I was speaking of earlier they don't necessarily get injured as much by using waterfall but they wouldn't lose anything from from using agile and especially you know there's there's more value to agile methodologies than just you know speak to market or things like that there's also and this often gets sort of lost in the in the morassive terms between lean and whatnot but there's this whole concept of waste and one thing that I learned from my first scrum trainer which was super eye-opening is that these these methodologies actually are supposed to reveal dysfunction and it's not dysfunction just in how you develop software or what it's dysfunction in the company at large because if your software engineering is doing really well and they're following whatever process blindly and it's going well and they deliver on time but then the sales team doesn't get training or the marketing isn't ready or the finance team doesn't know what's next going on so all of these rhythms and all of these approaches to try and reduce wastage and create more visibility across end up bubbling up in the company and so I think just on that alone the usage or application of agile methods in any company would be positive Byron your thoughts on the same do you think there are any companies that would benefit from not using agile other than the outsourcing example or anything else? Government tenders the company because in those scenarios it's a long-term contracts and so for the research grant contracts those government tender contracts because the government will give you a contract upfront for those and the challenges the tender processes are created in a way that the RFPs will go out and the submission would actually need you to define all the BRDs in those up front for example let's say the government of Singapore for example is going to launch a satellite system to do $400 million project to do automatic ERP tracking something like that and then they do an ERP they have to give a contract to some company to do it and at that time the company cannot say you give me this 100 million contract and we'll figure it out so they have to put a stake in the ground that when we deliver in 2020 no actually comfortable I have a seat good so when some whosoever company pitches for that contract you have to tell upfront what are you going to deliver in 2020 you cannot say yeah don't worry trust us we got it don't worry can I add on another example just for everyone else out here would be let's take for example ship building right when you talk about building up engineering things like that everything needs to be specified down to the team right and that's what you're specific on how you're going to do it and unless you do that and unless you commit to what are you going to do in the next four years you're not going to get the contract and yes how do you implement in while implementing you can do smaller cycles you can do all of that sure but you have to put a stake in the ground upfront four years in advance that this is exactly what I'm going to deliver these are the exact features these are exact sets and it's a 200 million contract you cannot walk up two years later oops sorry we didn't think about it another 100 million you cannot go and go to the government of Singapore so I would argue that we're really talking about two very different things here first off if a process is defined process then don't apply agile to it don't apply scrum it's for empirical processes building a ship is a fairly well understood repetitive process one ship I mean that's why they have classes of ships they knock out one after the other after the other on the same plan you know it's an Eisenhower class cruiser aircraft carrier you know that's you know that even with the minor differences between them they're pretty much the same so what I would say is what you're talking about on the tender is you're really talking about a frozen story backlog what you're saying is we're doing the complete backlog for the system for what we're doing on day one and we freeze it and we're saying and you know what we can do that you know why we can do that because our customers are not changing the requirements the market is not changing now underneath us you know now if they come to us then we negotiate and basically what you're saying is oh well you're asking us to break the sprint you know so we're going to we're going to terminate the sprint because it was a 24 month you know a big long sprint and we'll terminate it and we'll take in those requirements and we'll re-forecast everything and we'll boom we'll pick it up from there so Jordan I'm not sure if I heard this right because maybe I'm just surprised you think in this case it's all right if they don't use Agile if everything's defined no no I just said so first off I said if so first off what is it why do we do Agile because software is an empirical process if you're talking about a defined process which building a ship is yeah okay I'm talking about a software system no no yeah I mean like a defined end output with DCB built in a particular way it can be with software system so when they want to manage to track if they want a software system to track every vehicle moving everywhere so it's a software system it's not a hardware system it's a software system and the software system has to visualize it generate reports and they have to define it fully and it's a four hundred million dollar project so they cannot tell a company to figure it out later no but what I'm going to argue is what you're really saying is you've just built a backlog you've just built a backlog that is frozen at the beginning of the project the course of the project you're I mean I don't care how well you designed you're not going to know how you implement the telemetry handoff in that until you're in there you know and you probably go down three or four allies okay which is why a government contract with a anything that has a fixed backlog you know where you say you've got to deliver all these stories these epics and these stories to make it work it's going to be more expensive because it's going to cost more over the course of the project to do that now I would not say that is not a true waterfall it's a true waterfall says that you've nailed down every requirement every very every requirement and everything you're talking at this point you're saying you know what it would say in a document like this it would say because it would say something like telemetry will be handed off from cell towers in a way such that the interruption in signal is no more than 100 milliseconds that's just a story that's just a story how you do that that's a whole different thing you know now you know if you ask me to try to bid on that and do it all up front it's having to go okay god yeah five that'll be a billion dollars that's the thing right you have to bid on it you have to bid yes otherwise you won't get to the business okay so you know and I'm not done yet oh yeah sorry yeah yeah yeah well just just for just to help out and sort of moving away from the software mindset here just to explain a little bit more what I was trying to say earlier on I believe that the world at large all of the economy all of all of the consumer perspectives are going to start expecting just in time immediate delivery okay so the amount of time that people will have for waiting 24 months four years for whatever and your example is actually really good for I'm not saying this to you know detract from that it's just that we haven't we're still in transition we're still transitioning from the old industrial approach of doing things where everything must be defined up front and paid up front or at least budgeted up front and then you know we'll amortize it over years and you know it's not in Marina Bay that I swear to God three months ago was not there alright and just on that the Chinese are now building skyscrapers faster than anybody in about three months by the way because they've apparently mastered technology for prefabricated buildings so they prefab every floor up to every floor and then just sort of layer them on top of it now is it not conceivable that in that sense you can start with the idea that the building is going to be 110 stories high but the other thing people are like you know what the markets change the requirements are different now we need more you know people apartments instead of offices you know we need more houses than offices and they actually are still in time to adjust the configuration change the assembly line order to say hey let's do this differently and similar example to Bishop all the ships a little bit more complicated because they build it in the but anyway so just think a little bit wider than just software although most of us probably are here because of the software that's why I think that the agile approach to this has got a lot of future to it and just to sort of add a little bit of you guys if you haven't seen it go look for this video on YouTube which is about the story of a product manager in the military who is trying to build a tank actually sorry he's trying to build Bradley and the story goes on for about 30 years it's the Bradley fighting vehicle FCM there's a movie on this there's a whole movie on this and it's hilarious and it touches on the exact same points that both Varun and Jordan have been talking about and how there's a fixed contract and how it's supposed to be a reasonably defined process but just because of the human intervention it is everything but a defined process and it's a very funny movie I recommend it or if you want to see the case that's playing out how about the F-35 oh god I have a hand in that sorry that's okay so it's an interesting thing so the interesting thing is is that the A-10 Warhawk yeah which is the preeminent ground support aircraft in the world the one that you can basically blow the wings off and it keeps flying literally yeah it's true there are pictures of them coming back from the field where there are holes a meter wide in the wings and the thing kept flying so that came out of Lockheed Skunk Works Lockheed Skunk Works was an agile workshop before we knew what agile was okay the F-35 is a classic government waterfall project and I think the cost per plane is now up to 120 million you're forgetting the part you're forgetting the part where the F-35 used to be called the F-22 which they stopped producing because even before it reached their initial production run like ten times over budget right exactly yeah sorry anyway back to where were we but you know I mean the the fact of the matter is you can see the difference and now there's other factors that play here other factors that you know that he talked about you know hey it shows you the dysfunction of organizations well if there's something that has a dysfunction it's the U.S. military procurement process I get to say that I am still a U.S. citizen alright we're going to get back to Agile now you know my good segue from the Lockheed Modern piece John let's start with you which is an Agile company that you really admire can you tell us why I'm going to tell you a part of a company that I really admire and it's the my former group at Yahoo developer developer platforms and services DPS they James Collins and Santa feeds a fantastic organization that over the course of gosh James has probably been driving that for about five years went through from a dysfunctional organization that literally could not deliver anything anyhow to the point where more and more responsibility is given to the group because it can deliver and managing individual scrum teams and scrums of scrums and doing that in an effective way just a fantastic organization the impact that it had on how people do performance reviews and management uses a horizontal management model just many, many really great things can you just share with everyone here like perhaps the the functionality or whatever you guys created like the complicated piece that you guys created well I'll tell you what I did is I deployed Chef which you may or may not know a technology over the entire Yahoo fleet I can't say how many nodes that is because I'm still under NDA but you know how many it is it's the biggest Chef deployment in the world it's more than 10 it's more than 10 it's more than 10 it's more than 10 even bigger than Facebook's Chef deployment and so huge deployment and we had to basically build a hosted service using their technology we had to work with somebody external the vendor we were getting it from and do all of that they built they built the the continuous delivery pipelines that are used at Yahoo built the both did a lot of work on pass you know platform as service for Yahoo as well as infrastructure as service for Yahoo to improve utilization such I mean just it got to the point where James was like saying no we're not going to do that because we're not yes I know you want us to take it on yes you want us to do this project but we're not going to do it okay enough okay that actually turns out to be a harder question than I expected so you know from a company that I've worked with and that I really still admire and think of fondly the first agile transition that we did the one that was actually at Lockheed Martin because it had all the right elements so the motivation the support basically it we went we already told you that story so it went really really well we still had some issues like we had like a one one of the sprints was a hardening sprint believe it or not full of testing but anyway those guys I mean I was very impressed with what we were able to achieve there the other company that I can think of that still baffles me to this day is a company that I've worked with that you know they have scrum they do scrum training scrum coaching odd E and the company is extremely interesting because they have no structure whatsoever there is some ownership there is some directorship but it's mostly from administrative purposes everything else that they do is essentially based on agile principles not necessarily scrum and to this day I still don't understand how they do it but they keep on you know they seem to be very happy they keep on expanding they keep on ringing on people and I think every member of the team is free to do literally whatever they want as long as it you know they believe that it furthers the business and I just thought that was a beautiful thing because you know not every company lets you work that way there will always be some sort of issue with that for me I would say one product which I see like every month there is something new coming out is WhatsApp because if I look at what all they have achieved in the last one year from a basic messenger app they have built something which Skype hasn't been able to build in 10 years I mean something as I mean video calling in such a simple easy way and they started as just a messenger and then from that on that's a real approach to each other every month they are shipping something which is like in a way planet changing with hundreds of millions of users and at that scale launching something at that scale is incredible that's a great example actually I want to something that is even more interesting in app or pro so the people who found it WhatsApp were the first former management of DPS at Yahoo and James Collins actually consulted with them part-time on setting up how they were going to do things so that what was achieved in that group was influenced there nice all right so we're gonna like if you guys have any short questions we can take one now before I get on to my next one but questions need to be short all right 10 seconds or less yeah okay thank you no I find it fascinating this indicated your your tactical about undertaking which is common because you know when you ask questions for your family in terms of contactability whereas you know Jordan is positive and looking at it from a tier one yeah yeah my question is that Jordan could you assist us in the context in the context of design thinking and system design in the undertaking engineering firstly engineering because subsequently go to marketing okay so design thinking and engineering yeah I'm trying to figure how to wrap my head around this question real quick I mean so again designing is it's an empirical process it's an iterative process it's guided by feedback so to me this is a natural fit unless I'm missing something am I missing something no you'll tell me if I am I would if I no no I I think it it basically design thinking is an expression of agility because you're doing exactly what Agile proposes which is okay figure out what you think people want design an experiment that tries to test that hypothesis and then build upon that either you've made it or you haven't and you have to do another iteration perhaps we share with them the Samsung example where different components are created separately just giving an example from a Samsung time so every time a Samsung device has to be shipped they're two versions one is a black version and one is a real version so black version is everything which goes inside the phone the software side when they don't know what how the bezel is going to look like how rest of the stuff is going to look like waterproof they don't know the software team doesn't care about all this is that the same build that they create for the phone at first it's slightly advanced on the breadboard so it will have the screen and everything but it will not know the physical attribute it will not know the features it will not know the thickness of thickness shape it will not know it will know the software layer and that device is already at least eight months sometimes even one year before the software team focuses just on that and the industrial design team focuses just on the outside of it they just focus on the box of it they don't care and they agree beforehand that these are the broader dimensions at which we need to converge so it's it cannot be that one team designs for a five and a half and other team works on four and a half these are the high level stuff we will agree and then both sides have to converge at this point and from this point like six months before the launch both sides need to converge and then we need to iterate there would be different versions one with bezel one with thicker one with smaller pocket and sit for a bend gate do all that stuff so that's again you can call it design thinking I mean the way I look at it design thinking is another agile everyone says they won't do they are doing it doing it ten percent no agile even like maybe three percent know what design thinking is yeah okay so sorry go on so let's put the term agile away let's just put it away and let's talk about define versus empirical okay okay does do you have do you step forward off the line with complete knowledge of where you're going if you do then that's define process if you don't then it's an empirical process then we need to come up with a set of practices they talk about it sometimes ceremony in the in the in the world rituals that guide us through that and you want those be as lightweight as possible because you don't want them to be painful to you so I think that's the thing is you know that's why agile has this you know kind of family of practices scrum I think probably one of the best and well formed and most mature but it's they're all trying to deal with this fact dealing with an with an empirical process so put agile aside ask yourself are you empirical or not and the reality is the people in this room 99 percent of us have uncertainty when we when we come out of the blocks and then find the set of methodologies techniques ceremony practices that will let you cope with that that means you need to understand what an empirical process is and what it functions on and that's you know it's about feedback loops so you made a statement right now like everyone about design thinking and agile which is a lot of people think they're doing agile but they're really not but have you noticed any difference and Asia so I think that these are very general statements okay so it's very very okay it crosses with my next question in case all right so which is about how local culture and local culture norms actually can they actually have an impact on that oh god yes so let me let's just use the difference between I'm going to use three zones here hardest looking valley okay okay so Mountain View, California which is where I live Chicago, Illinois and Singapore okay the amount of direction that people in Silicon Valley Mountain View will accept I underline accept is you know is you know asymptotically close to you know zero okay you go to Chicago those guys want a lot more direction they want a lot more direction they want a lot more guidance and everything you come to you come to Singapore and that level just took another jump things that I would just you know kind of historically you know when I talk to people I've done some conversations I won't call it consulting but just you know conversations with people it's like well yeah just let them decide then like oh no we can why because they don't want to they want you to make that decision really okay the other thing is I mean I think that some of the best things you can have in kind of an agile form you know when you're doing empirical are people really putting it out there you know and that that level of passion can be perceived as trying to force things and I'm like no I'm just trying to try the idea out I'm going to it's destructive testing I'm trying to take it to the breaking point and the way it's perceived as I've gotten feedback from some people is oh well you're just trying to push people around and I'm like I mean add a Chengdu inside it and you will find another flavor to it oh yeah yeah yeah yeah yeah because in that scenario the brainstorming discussion opinion those words do not exist exactly and in that scenario imagine if you have a development team based out of Chengdu and working with product managers based out of valley that would be the perfect I mean I would love to see perfect storm I'd love to see you being the product manager with the team based out of Chengdu you know what about you we worked in teams all over the world I'm sure I have seen a bit of everything actually so I have to say that you know in Singapore specifically I don't know I guess people in Asia in general but Singapore specifically they tend to not be very outspoken right don't don't ask many questions just do as you're told kind of thing I mean sorry but general statements yeah very general very very general don't take away my PR and but I've seen that changing though so I've been in Singapore for gosh longer than that 15 years so I've seen things change so much that nowadays I see people wanting to take a lot more ownership of the issues you know and say I don't want to just do as I'm told I want to contribute I want to be creative I want to do stuff I want to be an architect to come in and tell me how to do stuff I want to do stuff myself or I want to try my hand at being an architect but then you know you end up having a lot of ego clashes and that's unfortunate and maybe that's what you're talking about I don't know Jordan but I think it's there's a lot of I think ego clashes when people have a lot of experience and have a lot of know-how are perfectly normal and natural and expected and usually are very healthy ego clashes with people who think they know a lot and you know what's called prima donnas are very wasteful and you just go around and around and around in circles and eventually somebody is going to get upset and leave so I think my experience directly has been the things I've been getting better engineers are starting to take a lot more ownership and not just engineers but there is still a vacuum when it comes to who makes the final final decision everything's fine until people start getting upset at each other and say I don't agree with you and then don't move forward there has to be somebody who makes the final decision and that I think is actually a bit of a problem when you're trying to institute this environment of you know we're all going to pitch into this and figure it out and ultimately there still is a bit of that well we need somebody to come in here and make the decision because we can't agree so yeah that's that's where I see things right now going to open it up again for any more questions otherwise we have one last one yeah go ahead sure so my question is regarding the gel ceremonies so to what extent should you follow for example for some of the settings of a startup complex to what extent should you follow the ceremonies closely and for example because some companies might not want to follow all the rituals and stand-ups very closely because it might not fit what is happening and for example what is the matrix or indicators that you need to use to know that whether you're on the right track or whether you need to include some okay so I'm just going to repeat the question do you actually follow all the ceremonies given that you're a startup and you're a lean team and what matrix indicators that you're doing it right versus not really doing it well at all I'm curious personally I feel that sometimes a lot of them are management overhead and excuse me that's where the whole argument started a lot of times it's more of a lot of people are double-hitting a lot of roles so the product manager is not only the product manager he's also in charge of marketing and he's also in charge of meeting the customers and he's like dude it's so straightforward can't you just go and do it and do I need to still write all these I mean do you want me to be a clerk to write all of this everything I've explained to you can't you just do it and again yes in theory and in stuff but the fact is you are running towards a line and you have limited funding and you need to ship the product out and again it goes probably I guess three people garage team it works and when it's slightly bigger so the question probably is at what time does that overhead becomes more valuable than hassle feedback loops you know what do it in a damn slack channel okay post the post you know post the three the three you know just do it in a slack channel you don't have to get together physically now you know perhaps you know you want to follow up questions things like that but that's what it's about it's about the feedback loops are you are you having those conversations are you demonstrating like for the what is the sprint review the sprint demo it's like I want to really touch that thing I want to feel that does it really exist that's what you're doing there okay now again if you're a small team you know three if you're under the one pizza rule you know and that's the entire company you know you could you could feed the whole company on a pizza then you know the level of formalized overhead you need is look you have alternatives so what is what is what's getting that short loop what's getting that one day loop what's getting that that slightly larger loop you know how are you deciding what you're going to do you know the reality is is a really really small team in a startup that is you know like pre seed even okay is probably going to be doing a lot of combat because what's going to happen is you know that product manager who business development who head of marketing is going to walk in and say you know I had this meeting with someone today and my God they could give us an incredible deal and the market opportunity is fantastic do you know that there are 5,000 of these in southeast Asia and each of them would be willing to pay us $5,000 each do you know how much that is you know and he's like and what we want to show him is how we do this it's like you know don't abnormally terminate a sprint it's the formal term you know to deal with this use a different methodology that is empirical okay like I would never put a support team on scrum I would never this way is madness okay I put them on combat anything that is running a service I would not put on you know on scrum I'd use combat things that acknowledge the empirical nature of the work that they work on do you know anything to add just to reiterate what Jordan was saying I was thinking what I was going to answer is essentially a startup's objective is to as quickly as possible figure out if their concept is going to have any kind of market traction so you want the least amount of overhead possible for you to do that and I agree with Jordan if you're all sitting in the same room and if everybody's there you don't need ceremonies and whatnot they will happen organically you don't have to worry about that what you do need though is to know what are we going to get at first and with combat what helps a lot is knowing how long it takes to get to the point where it's done and ready to be shipped so then you don't have to worry about sprints and you know planning and whatnot you're too small for that you just you know keep working until you've got something ready to deliver and ship it and test it test the market that's all I have to say so one thing to catch on methodology miss and forget and is managing your whip your work in progress limit you know that you know it's critical it's critical it's critical especially for a startup because really you can be you can be running in 12 different directions and you know you want to maintain that and also the last comments always trust the dog and don't use scrum because a lot of people are talking about it as Jordan said our team actually may not need scrum so agile is fine but even in agile and if you're not sure talk to someone who's been doing it for a while on advice of what exact which exact methodology is right at your stage of company one of them may not be right okay so we're going to move on to we're going to look at XP actually because that was a precursor to a lot of these things it was just extreme programming if you're a developing if you're a development house if you follow the tenants of XP it won't be far off I mean with customers you can sit in their laps like yeah well no if you remember it was the Ford payroll system I mean they literally they moved all the payroll people into the room with them they did their jobs day in day out in that room with the developers so we're going to move on to our last question but after that you can get free consultancy from them and now they're all back they're all you told us we could charge but I heard pizza there was pizza mention in here somewhere later on okay okay so the last question for you guys is in your view what are the first few things that a company should do to embark on an agile journey and at least limited to a maximum of three so it could just be one it could be two or three holy crap understand what is the nature of an empirical process one oh that's all to me that's the most important thing wow okay well things that have worked in the past is to get management by it because getting things going from the ground up is great but if you don't have the management convinced it's going to be very very difficult and that was very helpful another thing that was helpful although painful was that burn your bridges you don't have a choice commit to it seriously the situation that we were very successful and was kind of like you know if we don't change what we're doing we're all going to get sacked and that was a very good motivator you cannot be a little bit agile or a little bit scrum or a little bit empirical I'd say get a buy-in from the team because you don't want your engineers to feel that suddenly there is a guy who they have to report what did they did in last eight hours every morning so you need to explain to your team why what it is why it is respect their feedback answer their concerns and you will have an insane amount of backlash if it's because there's a new cool dude who came from outside and he thinks this is a cool process and now it's imposed and the developers now start to hate that this outsider has come to police us and it has become a police state so respect your guys on that point actually show them show them the benefit so the first time you hear an impediment through everything you have to clear that before lunch I mean it may not be possible but God makes sure they know about it you know and it's like oh I'm going off to talk to purchasing right now about those servers I'll be back you know in two hours awesome Bo you know let's hear it up the difference in the field they're going to be here later so you can this and this is also our last product tank for the year we're going to have one more we're going to start again in January there's a bunch of stickers lying out there from product tank please take one don't take them all and that's about it thank you thank you thank you can we have two