 If you have any questions, please do ask. The best time to ask a question is when you have the question, so please do stop us and ask the question when you have it. So this conference was coming up, and we both felt that we should do a presentation here on the Heathrow workshop, which is why being the agile experts that we are, we said, let's start off with actually building a backlog, which is what most agile guys do. Yeah, so you can read this story. The first one I'll explain, and then onward, we'll just run through this. The first story we said is, so if you have to present at this conference, as agile presenters, we have the experts here, we want to create a backlog so that we can actually get it done. And we have five minutes, which is basically our way of participation, which is called Nabilis Units of Time. So we have five Nabilis Units of Time. And on that side, you actually see 100 PV, which means 100 business value. So 100 is a hypothetical number, which is relative number that we try to say this. If we complete this story, we can achieve 100 business value. So that was the first story we wrote, which was about creating our backlog. Now let's have a look at actually what our backlog was. So this is about a list of stories that we tried to put in our backlog. So the first story there was the fact that we needed titles for the talk. We had to submit our proposal. So we said, let's see how, as a presenter, we actually get a title that will actually attract you guys here. And hopefully, that sort of did what it had to. There, again, that's one nut. We thought it was a simple task for us to do. And this is, again, a 500. So that was our first story. Next story was about actually, we have a title now. What do we do with the title? If I have to propose a topic, then I also need an abstract so that the conference program committee will actually look at the abstract and select the topic. So we said the next story we actually have to complete is to actually, as presenters, come up with an abstract that is interesting for our people and is in line with the conference team. So we came up with an abstract for this. And this is just, we're talking about the backlog that we created. The next story we had, right, so once it would get accepted, you know, we would have to start building an outline. We would actually have to start breaking down our tasks and start working on them. So we said, you know, as presenters, we'll actually need an outline so that we can start working on the content for the workshop. Anyone familiar with ASA? ASA, I want to show that format. How's the rewriting? Yeah? So we're experts and we actually make sure we follow the template so we don't miss any of that stuff. It's important. Right, so, you know, we're actually fed up of the accusations by all the non-believers, the agile non-believers, that they said the agile community is not user-centric. So we said, you know, we need to give a lot of high priority to usability, which is why one of our stories is actually about usability. We said that we need our slides to be usable. So it's clear for the conference again and you know, the message is conveyed to them again. Yeah, we care a lot about our users. Customer delight, you know, this is kind of what, I guess, you guys come to the conference to get delighted. You want to learn something new, you want to go back satisfied saying, you know, we actually learned something new at this conference. So we said that's a fairly important story for us if you see 2,500 business value. And it's fairly complex task to actually satisfy the people who come to attend a talk, right? So this is a fairly complex task and it's estimated at 35 knots. And obviously the most obvious of the stories is that we need the content for the workshop so we can actually conduct and do what we're doing right now. It's also pretty complicated to work 30 knots because it's a lot of work to come up with all the content and very high business value again, 2,100 there. I mean, we are of course the agile experts out here and we know that, you know, sometimes people get stuck in just writing a lot of stories and not doing anything. So we said enough of, you know, writing stories. We have a pair, what we want to do and we can actually get started. We can start our planning and we can, you know, start working on the thing so we can actually start delivering something and not get caught up in the whole analysis, analysis. This is where we experts get our then like agile intuition and we know that we have to start working on this. So let me talk about stories and backlog. Let's talk about adaptive planning. How did we go about planning our session, right? So we are strong believers in scrum and we started off with sprint planning and I guess most of you would have heard of sprint zero or sprint one, so we started with sprint one and that's kind of how we started planning the first sprint. Sandeep and I have delivered similar talks at previous conferences. So we had some sense of what our velocity is which kind of roughly boiled out about 12 knots was our velocity. We had about five hours before we realized that tomorrow morning is the deadline for submission of the workshops. So we kind of sat one evening for five hours because what our capacity was and we planned, we picked up two stories for the goal of this sprint was to actually put in a proposal, right? So we played the, the title story and we played the workshop abstract story. So keep in mind that we're not doing this full time. We obviously have jobs so, you know, which is why we pay attention to capacity because, you know, we're talking about the number of hours that we can give to this as well. So that's our first sprint plan roughly and this is our burn down when we started. We totally, whatever we had collected about 900 odd story points we had. So that's where we, sorry, we got 94. 900. Sorry, 94, sorry, I keep very confused. So we have about 94 story points and that's where our burn down, that's how our burn down chat looked when we started off. It was just a sight of me and Arish actually pair on a lot of things and then I was one example of the advantage of betting. You could see, you know, each one can mess the other up and just, you know, make a mistake or something. Yeah, we love betting, yeah. Ah, so the first story, right? It was quite exciting because we wanted to come up with a title for the workshop. So we talked about what should be the title. We brainstormed a few ideas about what we want to talk about, right? So all this stuff that we discussed was in terms of, you know, let's keep it a little bit away. So that, you know, we can find when we get the time to work on the actual content, we could sort of play around with it, we have that space around which we can do that. So you already keep it a little away, but at the same time, you want it to be interesting as well. Yeah, the whole Lean software movement, if you guys have heard about the Lean philosophy where they talk about last responsible moment, we kind of embrace that full time, you know? It's like last responsible moment less. Let's push things as far as we can. Which is funny because we'll talk about that later but let's see what the title is. Notice how we did use the word procrastination there. All right, so the first title we came up was for that shit was the title of our topic. It was kind of fairly abstract and we said, you know, this is kind of what's running through our mind and what is happening in the agile community. So this is what we want to talk about. This is also inspired by a comic strip by a very famous artist called, this comic is called XKC, anyone know of it? Any XKC we can, yeah. So this is basically picked up from there in terms of the title. We said this kind of resonates with the word to speak and that's where the title. And it was very easy, we got this story done. I mean it was one that took some time but once we got the title, we were rolling with it. Let's move on. Next story we had was about writing workshop abstract. Here again, we don't want to spend a lot of time doing this, however, we wanted it to be interesting. Like we said, it had to be along the themes of the theme of the conference as well so that we can select it. And again, we used the fact that we were inspired by the XKC the comic, so we sort of borrowed some of the text from there and we came up with our abstract. So in case you've not seen our abstract, this was an abstract. I'll give you a millisecond to read this. Don't try and read the comic because that's too long. Yeah, but that's a fun part. You want to read it later on on the website if you haven't already. And this is that basically, we don't have all the answers. We don't know what's the best way, what's the right way to do stuff but certainly over the years, we've had experience about what is not working and what we believe does not actually make sense. So instead of just blindly following, mindlessly following the experts because they're doing the practices that they say, we wanted to do something different. So that's the abstract that we came up with. And that was easy. We submitted it, the conference committee really liked it. They selected it and our first print was done. That breakout chart is the perfect picture of a sprint going well. Yeah, they need a high five for that. That was awesome. That's an example of how you do it right. We selected two stories, we burned it five hours, we've got everything done and it was absolutely smooth. And so that was our burnout of the first print. Then once the program was announced, we collected customer feedback, right? Everyone does that. You put something out there, you want customer feedback so as soon as the program was announced. Whether you want it or not, the customers do give you feedback once it's out there and the feedbacks are going in for us. This slide is a reference to a mail in the mailing list. How many of you are there on the mailing list and following it? As I'm telling you, a servant referred to our talk as the elephant in the room. I asked the others if anyone's seen it so that's what this is a reference to. So yeah, there were also some really good feedback about people saying that your title is very offensive, we can't send it around in our company, people will get offended and things like that. So we recognized that, we appreciated the feedback and we basically said, all right, time to write a new story. That's what we allow you to write a story. It's all about stories, man. We came up with a new story, which was change offensive title and we wanted to change the offensive title so that we don't offend our prospective conference attendees, right? So we are the paying customers, that's you guys. Yeah. We spent quite a bit but when we introduced this story, you will notice that our Burndown chart actually had a little bump up there. We went up from 82 points to back up to 85 points so now we have to burn down the extra three points and 35 points. Now we started planning a second sprint which is this time we had a little more time and we had about 10 hours capacity that we could spend and we took on 20 story points after the successful completion of the first sprint. We were pretty confident that we'll complete these three stories, change offensive title, slide usability, we wanted to get usability in upfront that else it would be too late and then basically get a workshop outline so we can start finalizing work and start working on it. So far you guys with us? Yeah? Yes? Sorry, you mentioned three points one of the things that value nuts and story points. Nuts is, nuts is story points. It's a way of doing. Nuts is a way of, so nuts is like more of a generic term that people use nebulous units of time. Story points is one of them. Ideal developer days is another one. So there are all these different notations. T-shirt sizes, T-shirt sizes in some sense, yeah. As you were saying, it's relative, so we have. So we look at some stories, we say you know this seems like really high business value. So let's put it on one extreme. Let's say 2,500 story points. This is fairly low business value. So let's say this is 100 business value. And then where does this stand? So we relatively basically it's like the stories themselves. It's not objective in that sense. So when you're looking at 2006 in relation to the other story. It's not an absolute, it's a relative figure. So it's more like the time estimation we do. It's similar to the story point estimate for business value, right? So the time estimate tells you how long it's gonna take it some, but the business value is telling you whether you wanna do that first or not or when do you wanna do it. Both are relative, yes. That's right. It's not very, it's not very good. It's the beginning of the whole decision. What is so offensive about the title we'll take it offline. It's the four letter F word that that's what we're getting from here. I got monkeys and monkeys also. No, no. I got monkeys and monkeys too. We actually had a different idea. That would be a welcome. Even the last four letter word was not very pleasant. Right, yeah. Yeah, so thank you. So if you don't like four letter words we realize that we adapted, we inspected and adapted and evolved from there. Right, that's what we're doing. That's what we're doing, inspect and adapt. So let's talk about the first story. How did we go about actually building the first story? We said, you know, we came up with the title. People didn't like it. The chances are us coming up with another title that people will like is relatively less. So let's crowd source. And everyone's familiar with crowd sourcing. So we basically asked on the mailing list, what do you guys think the title of this talk should be? And we got some really wonderful suggestions. I mean, I asked on Twitter, I got a lot of feedback on Twitter. Some people on the mailing list replied back to us. We got some really good suggestions. And we picked up one winner. I mean, actually, because I really liked this one. This was almost our second. Janta ki aadale khe aaj ajal practices. Was a pretty neat title for this. So we finally settled for monkey see monkey do because it kind of, yeah, it still kept it quite abstract. And this was our suggestion. All of these are suggested. The monkey see monkey do was also suggested roughly in some sense, but we kind of, you know, it's like you take customer feedback and then you figure out, you do analysis and then you figure out what would be the best for them. So we came up with this. A lot of times customers will tell you what they want or what they need. So, you know, we got an idea that this is, you know, sort of what they wanted. Then we came up with this. So, we got this one for this one. We completed this story. That's fairly simple. We asked people, we got feedback, we picked up story, we did some study and we came up with the title. So we changed the title and that's a story completed. It's done. Now you guys even know the title. The next one we wanted to work was on slide usability. We wanted our slides to be extremely usable. We wanted to make sure that people can get this stuff right. So, yeah, here again, you know, we did the same, we asked the people what they think should be, how the slides should look and we got some suggestions from people. We got a couple of links from them so we had to research these as well. We got some good links, we researched about them. We did some analysis and basically we came up with this template for our slides, which is what you've been seeing so far, this was the template that we came up with. Oh, man, it looks like there was a bug over there. Sorry about that. I'll just check them. It's going to run the build. You want to go to waitingforbuild.com and just check it out. One of the guys is subject to waiting for the build. All right. The guys who have it, you guys should check it out. Pretty cool thing, when you check in code and you're waiting for the build to finish, this is the place you should go, waitingforthebuild.com. All right, I think the build is green. I can see it going fine. There you go. Hey! All right, all right. Continuous integration thing is amazing. You just make mistakes, check in, and stuff just comes out on the other end. Pretty neat. So there we get. We got the usability, we asked people, we sent them, on the mailing list, we even sent out a slide and we asked people how did they feel about this slide. People gave us some feedback, we did some research and we figured out that for video recording and stuff like that, that background, that background is better and things like that. So based on all of that we did and we came up with this. So far, so good. Let's talk about this. Workshop Outline, this kind of was quite critical for us to actually have an outline for the workshop. We started working on this. But as you can see, we didn't get anything done here. Right? We did, we did our storyboard estimates, we did our stories, we did our planning based on them. We knew our velocity, but yet we didn't finish. Right? This is what we had. Why do you think we didn't finish this part of the story? What went wrong in this print? Why couldn't we finish this? Everything seemed to be going fine. Any guesses? We had some other work to do. We had some other work to do. Maybe something came up, maybe, yeah. Nothing to add. There's nothing to add. We didn't have any outlines. We actually had lots of ideas. We were like writer's block. Right, that's what we were supposed to do. We were supposed to sit and think about it. But we were supposed to come up with an outline. That was the point of this story. But what happened was this dude went out working one night and just felt sick. Yeah. And I'm known for that, having a weak immune system. I keep falling sick. So we couldn't complete this story and the story went into a hangover, which means we're going to play the story the next iteration. This happens. I mean, this is what all agile is about. Inspect and adapt. Adaptive planning, we plan for some stuff and it doesn't finish, so that's okay. We move it to the next print and we work on it in the next print. So obviously, when you look at a business strategy, this is the most important. Like you used to having a title because of the content. So without the title, we couldn't even, what's the point working on the outline when we don't have a title? No, just to clarify, the title was necessary because we had to submit it to the content. There were some constraints in the business. It was automatically important from that sense. Okay. From the product owner, business value is low. But for it to get accepted, that drove, you know, like you have some kind of dependency. We had a dependency on this story, which we had to play. In the same sense, changing the title, we could have done that later as well, so it appears on the program. So therefore it was automatically important. We were constantly taking feedback, adapting to what our customers need, and you know, we were working that out. So this is our burn down after the next print. We kind of had 77 points. We were hoping to burn a lot more down, but because this guy felt safe, we couldn't do that. Now let's talk about the sprint three. Sprint three, we wanted to work on, say, the workshop outline like the most important story was the customer delight story. Yeah, this time we know that, you know, we don't have much time, so we decided to give it four times, because we were putting 20 hours there. Customer delight. What is the customer delight story? The idea was that, you know, our product owner said we want to make sure that the users learn stuff from this workshop and they feel delighted at the end of it. So obviously, you know, this was still vague for us. We couldn't understand what this actually means. So we looked at what could be the acceptance criteria for this story. What does it mean to actually complete this story? How do we know we're actually done with this story? How will we know we've actually delighted the customer? So that's the question that we came up with, the answer for which we had to find so that we could complete this story. What is it that we need to do that will delight the customer? And how will we know what we do then? So we actually looked up about a lot of conferences close to about a thousand conferences. We looked at the talks that speakers do. We try to analyze what is going on and we try to understand when customers are delighted. And one of the things we kind of found out was that, you know, how do we measure, you know, if customers are delighted? We know that some talks customers are delighted, some talks customers are not delighted. When they make customers, we mean audience. So how do we distinguish? We need some kind of a matrix to actually calculate that. Now, by closely watching the thing, what we realized was towards the end of the talk is when, you know, you can actually sense if people were satisfied or not. You know, at the beginning, it's too early to say whether the customers are delighted or not. I think all through you think it's that. All through? Sometimes yes, sometimes no. I mean till the end. So we will see that, right? So based on our study, we figured out that it's typically towards the end and one of the metrics we found was that, you know, the intensity with which people clap kind of shows how happy they are. Right? So one of the things we saw is if we started measuring that matrix, the key thing was people clap when they see the thank you slide. Right? When people see the thank you slide, they clap a lot. Thank God it's over. Thank God it's over. So we found a high correlation between, you know, people clapping and thank you slide. And that's why we thought, you know, thank you slide is most important. So we'll start with the thank you slide. That was not too good. Obviously. Anyway, so that story is done. We started again working on the workshop outline. Right? And what happened this time? We, of course, followed Pomodora. You guys have heard Dave talk about Pomodora. So we followed Pomodora technique. And we ran out of time. All that research that we did on what would make our customers happy and how to figure that out sort of took up all our sprint time. Yeah, we ran out of time. And we didn't get around to doing that. We ended up with only 32 points down. This is where we stand. Right? So here is where our presentation stands. This is all we should get done. This is it, Karim. He's got a pretty kind-feel sponsor. Sorry? He's got a pretty kind-feel sponsor. Not a pretty kind-feel sponsor. Audience are not happy with it. One more thank you. Let's go back to the thank you slide. We have some deliverables. So that brings us to the real title of the stock. This is the title that you guys haven't seen. This is the actual title of the talk that we did publish. Right? Now it's not what you think. Right? We already burned our hands once. What do you think? So we didn't want to go down this slide. Who here thinks knows what WTF is? We already burned our hands doing that. We are smart individuals. We are expert agile practitioners. We don't repeat mistakes. Yeah, we did that retrospectively. We don't repeat the mistakes. Let's cut the chase. Way to fail. This was a demonstration so far of what you saw. We tried to monkey see monkey do stories and this and that and all the things that we don't even understand and we tried to follow them. We tried everything by the book. But we still failed. Our goal was that... Our thinking was that if we could do what the experts are saying and we could mimic that, then we would be extremely successful. But we ended up with this. So now we want to cut the chase and really get to our top. The highlight of that was that agile is not a silver bullet. Nothing can be. There are no silver bullets all day long. Let's take an example. Anyone familiar with this company? Anyone not familiar with this company? Then you can stand with a naughty bench over there in the corner. So what do you think is the top reason behind Toyota's success? What is the top reason behind Toyota's success? Why is Toyota so successful? People consider Toyota as a successful company? Yes, extremely successful in the car manufacturing industry. What do you think is the single most important reason for Toyota's success? Continuous innovation. Continuous innovation. Building what the customer wants. Building what the customer wants. Do you mean the other guys are not doing that? Yeah, kind of. Maintaining quality. Get rid of the waste. Get rid of waste. Leaning management. Leaning management. What do you think is the top reason behind Toyota's success? Why is the solution important? Why is the solution for the needs? So, we all seem to have a fair idea of why they are successful, right? There are books about this that tell you how they did it and how they succeeded. But, why is there only one Toyota? We seem to know all the answers. Why Toyota did this Toyota did that Toyota was successful. How many companies they wanted to be successful? They wanted to be always successful. All of us wanted to be successful. Because they did what they wanted. They didn't compete with anyone or anyone else. Because everyone started dating Toyota. They didn't figure out what to work for them. They started thinking what to work for Toyota. That brings us back to why you both came up with this workshop. You tried to follow the farm, but it didn't make sense. When you follow the farm and you don't understand the essence behind the farm, you are left with the facade. And even let's say, we have no kiddos out here, right? We understand the essence. Yeah, you are the experts, exactly. We are the experts, right? We understand every aspect of the farm. We understand every single practice, every single thing under the belt. You know, we were like, yeah, I am a certified scrum wizard as well. Oh, what's that, dude? Certified scrum wizard. Did you get that patented on it? Yeah, I paid for the people for it and all that. So we want to actually do an individual activity. What we want you to do is take the next two minutes and think about what are the indispensable practices on your team. Today you practice them, right? Whether you do agile or you do something else, it doesn't matter. Whatever you are doing today on your team, what are the indispensable practices that you guys think on your team? So take two minutes and just chalk down those points in terms of what are the indispensable practices, right? Individually. Okay, that's two minutes. Next, what we want you to do is self-organize, form some groups, groups of three, four, five people, self-organize, form some groups. And what we want you to think about in the groups, have a discussion. You have five minutes, you can form teams of five people, of the five people. What practices do you think are indispensable for every project that you think on? Right? So you've thought about, for your current project, what practices are indispensable now, form groups, have a discussion about what do you think for every project is indispensable, things that you can't throw away from projects. So form self-organize, form groups of four, five people and have a discussion. All right, guys, it's five and a half minutes. So let's go around. Quickly, you guys can talk about what are the practices that you came up with. We don't want detailed explanation. We just want the list of practices that you guys thought are indispensable for every project. All right? So we'll start here. It's just one person from a group can stand up or whatever. You don't need to stand up. You can just be seated and read out. Okay, any other questions? Are there any goals or vision defining the requirement? So that's the only one which is possible. Then communication, then testing and quality, tracking and reviewing, then team management, somebody has come up with, customer focused, has an innovative and adaptability, planning which you're viewing, that's all. All right? That's a good list of things. Let's go there and see what you guys have come up with. Just read it out loud. Okay, one is, I'll probably read it out in the order in which most people have consensus on that. So one would be coating and coat quality and working on the software, basically doing the stuff, getting things done in the sense that not just ideating all the time, but writing code even if it's horrible and probably improving that later on and obviously making sure that it's of a certain decent amount of quality. Second would be, I mean, you can call it pair programming, you can call it communication or talking to your group and making sure everyone knows what's happening and stuff like that. So that's probably also related to a daily and weekly stand up somehow because that means that everyone is in the loop and guys know what's happening and it doesn't land up in a situation where someone is on different wavelengths and stuff like that. Then one thing is, another thing is getting feedback from your clients or customers or users, whoever they may be. If it's an API, it could be an internal app. If it's a client-facing thing, it could be, you know, whatever. Another thing which you, I mean, it may go against agile but at least some of us strongly think is that you should be clear about the requirements and not change them unless it's extremely required to change them. So even if you think that, you know, it's slightly, probably yesterday you thought A and today you think A- probably still go ahead with A and not just change A- because it changes a lot of things as far as programmer is concerned and it just causes havoc and, you know, there's motivational issues also. And another thing is focusing on the title or on the problem statement. So you tend to, you know, digress and go along tangential routes, probably, you know, try to explore some atomically interesting problems that you may want to solve and lose focus of what you actually do want to do, which may be very trivial but, you know, because it's so trivial you don't want to do it. Probably. And another thing is avoiding recurring mistakes. If you already had, you know, if you already did some mistake or you already encountered some situation and solved it in a certain way, just remember that's how you did it and you know, try not to go down that route. And code review. So probably that is again somehow related to, you know, talking to your group and pair programming. It's kind of like one stops any other stuff and design before code. Which again some people may disagree with, you know, like upfront design. But sometimes it's like, it's very useful because you know what you want and you know, if you already know what you want, you can probably do it much faster and much better. It's like an already solved problem because you're just speaking then up and applying here. Right? That's a good list. Group here. Right, right. The things we came across was start-up in the order which we thought the process goes on. Yeah. So the planning would be one, sizing and stopping issues, the number of resources, articulating what is the done criteria. That's when the number of steps breaking down, exactly when it gets done, things like that. Then we'll be engineering practices like TDD, refactoring, stuffs like that. Metrics would be another one which we thought would capture things like continuous integration or burn down charts or velocity, things like that. And reviews and retrospections coupled with stand-up meetings. And also another factor we thought, I don't know if it is relevant or not, but there's a learning curve also involved. So that is some sort of a point that we could always incorporate and obviously maintenance. These are some of the things that we thought. Okay. Some of the practices have more higher level things, but that's okay. Let's come here. There are three things which we thought. One is planning for the iterations, sprints, and continuous integration and then having customer feedback and then incorporating that. Let's have a look at it. There are three practices. We're not saying anything. I'm just asking what the groups are coming up with and then we'll have a discussion about because things are at different levels. When we talk about practices, we're talking about communication. Is communication a practice or is it a value? So there are all these different levels where we want to talk through them. So we came out with pre-planning as one, coding a DVD, then see and tell with the customer feedback as often. Huddle for a positive confrontation to talk about stuff that they're doing and CI and work for each other. Okay, sir. So as you guys noticed, each team came up with a kind of discrete set of, you know, some had overlap but some had, you know, these different practices that they thought were, you know, indispensable for every team. Why do you think there's so much variation in terms of what everyone came up with? Before you answer that, the fact that the word every is their striker, you're thinking from that sense that these practices apply to every project. So we, like when you announced it, we had only one practice which was common to all what we thought it would be which was having a project with them. Apart from that, everyone else thought a different set was actually in the sense both for them, but we just proved it all together. All right, all right, go ahead. There's no book, it's the first thing. There's no book. And everything is unique, everything is distinct. That is where, that's the whole magic of it. Probably that's how we come up with a set of best practices, all the practices. What I'm wondering is we talked about lots of different things which are kind of, in some cases, some people said, you know, this might be against agile, but this is a good practice. In somebody else, you know, somebody else talked about practices that were all specifically agile practices that you would be. So what I'm trying to understand is why is there so much variation? You know, there is no cookbook. Different situations are different. So can we come up with best practices across all projects was kind of where I was going to? How many people think you can come up with a set of practices that apply across all projects? And how many people think, the rest of you think there is nothing that applies across all projects? Few of the practices reject. No, that can be. I would say that again, that would depend upon that we use that levels. Probably if you look at a higher level then probably we can come up with best practices. But when you go to a more granular level then it would be much less difficult to implement. So I guess what you're getting at is we talked about practices, we talked about values, we talked about something bigger than that which is kind of more of a cultural thing. Yes. And we had all these different levels and at practices level there could be a lot of variations. At values level maybe there is less variation and more agreement in terms of, you know, these are communication feedback and things like that are all values that we all value and we want to embrace them. So that's kind of what you're thinking is. That's pretty good because what we wanted to talk about next was, you know, the bloat effect. Have you guys experienced the bloat effect? You start on a team and you start with a set of practices. But as you go along, the number of practices that you use on the team starts increasing. The number of people on the team starts increasing. The number of bugs starts increasing. The number of, the amount of time it takes to produce something starts increasing. So there's a bloat effect that kind of happens and how many people try to throw away practices? That's great to know. With respect to the question that, or the thing that you mentioned, maybe at the values level we can have some sort of an agreement but not at the practice level. How many of you have been in a situation where you actually, you're doing a practice but no one remembers what the value was why you're doing it now? What's the rational behind some practices? So we want to talk about few practices which we want to talk about next and we want to talk about what is the rational behind it, what's the value behind it and why we think it's completely useless to do that in specific contexts. Of course we're not making generic statement that this is true for every project but we try to take a stand that from our view of the world today the way we are operating, these things just seem like too much of a process, too much of a regimen. So we want to talk through some of that without taking an extreme stand but trying to bring a new perspective to table. Please keep in mind that we're playing the devil's advocate here. We will make extreme statements but that's only so that you guys think about some of the stuff that you guys are doing and you don't end up in the place where you're doing the practices without knowing what the value is. Like dancing around the fire thinking something will happen. Does anyone know about that story where there was this group in a native group in America which used to generally dance around the fire thinking food will drop from the top and they did that during the Second World War and because there was all these flights flying out they would drop food when they would see smoke coming up and once the war was over there was no food and people would still keep dancing around the fire thinking that food will drop from the top. It kind of becomes like that a lot of times you go visit teams and you see they're doing some rituals and nobody knows why and how what difference would it make. What do you guys think is the rational or the advantages of doing release planning and print planning? Here we also want to be interactive so you guys can come up with your thoughts on this. This is more of a discussion we want to go into more of a discussion mode we want to take feedback from people we want to share our perspectives we want to go into this chaotic discussion mode. We don't have all the answers so we are here to discover them as well. Release planning will help us sizing and prioritizing sizing and prioritizing and print planning will get me into the engineering task involved. Break it down into the task. I'll come there for a minute. Forecasting. Identifying dependencies dependencies in what sense with other teams with other teams within the what needs to get done first to ask people that What are your dependency kind of stuff? What are your dependencies? To some extent it will ease the senior management decision ease the senior management ease the senior management decision process. So what do you guys think about this we are not seeing a lot of hands raised you guys are doing this can you think about why you are doing it and what value you are getting I personally think that I mean although I know on the ground that it will not add much value to it but I do have to pay a huge service to somebody because we work in the client environment so they ask us for this upfront and if I don't do it there will be more fire than I cannot even start the project so as opposed to saying we accept those things this is a shit for them if we do something at least it will give some information where it is going and they will be silent and the team also gets okay this is what the target is let's try to work towards that but we all know that it will win and we have to regroup again to do something So you guys are just doing it for the sake of doing it then Is it required for the client? See I come from the 877 so most of our customers that you know we want to go agile because of certain reasons and they are interested in us we are a traditional organization and we are not in a mode where we say we advocate agile that's where we are doing this so now but we are also taking on projects we have to do now in this model do you want to follow the agile philosophy in all this sense I try to produce research where it is purely a bottom up to the top approach and then you get caught in all this so do you want to get caught in the car or try to take this philosophy okay this is there and they have been advocating it helps so as long as it can help so as a mentor or a coach you want to put that in perspective but then not get too much you know led into it but you know let it be at the surface if the team wants to go there you correct them and pull them back that's a good point let's do this enough so that we can move ahead and start working on stuff that's a good perspective I believe it is also a good platform to have the entire team on the same page what is to be done and how it is to be done so more of a communication and visioning exercise for the team setting the focus for the entire team setting the focus for the entire team setting the focus for the entire team so all those are good points between release planning and sprint planning so sprint planning is like totally useless for us we don't do it at all but release planning is kind of useful to understand okay we have all these things to do which one do we want to do first which one do we want to do later and what is important and what is not important and then figuring out okay we can do these we can do these as a second one so we were going to talk about some of the things we have noticed that happens you know we talk a lot about you know this whole sense of adaptive planning right iteration planning and sprint planning and release planning is all about adaptive planning right how much of adaptiveness is actually there when you start you know signing up for a release plan and you say okay we are going to work on this release plan and you start working on this how much adaptiveness is there in real sense is something we have experienced that people get too tired with the plan you know there is a notion of delivering to a plan instead of planning to deliver kind of a behavior and even at this agile scale that people do we feel that still you know that sense of getting too tired of getting too attached with your plan or you know just following the plan because you have put a plan together you spend so much effort trying to come up with it kind of starts continuing happening so that's one of the big things that I have noticed there's also something that maybe you already mentioned directly but you know we as humans can't deal with uncertainty for a lot of people the release planning and the sprint planning sort of gives them certainty to some sense a sense of certainty at least and what we notice is that when you do that when you know disparate teams have the sense of certainty they then go back to their silos again and they are working and they come back after the release right so you actually end up building walls sometimes in between these because they think they have certainty in terms of where they are going that sort of break down the communication between the teams as well is what we notice yeah I mean that's actually a very strong point we can talk about that a lot if you take your personal experience and you know do a retrospective on that you will see that there is this small sense of security that comes in or small sense of certainty that creeps in when you think oh we have a plan we've thought through it this is exactly where we're going where glossity is showing us that we're on track and you know sometimes you know sometimes that doesn't really match with what it is but it's kind of creating this small sense of security what do you say there is a problem with following the plan rather than creating the plan and making it adaptive so again that's the point we are getting at is planning is important but plans are useless right the act of planning thinking through and constantly trying to keep planning and really being adaptive about it is more important than the act of having a plan and following the plan but sometimes also the fact that you are planning and creating that plan obviously talking about this very macro level we are doing that you end up delivering to the plan so the fact that you did it means that you might end up doing this you get attached to it in some sense I mean Scrum has this practice of you know basically terminating the sprint when things change and how many people do often terminate their sprints if you look around there are very few people who will actually terminate the sprint because they have already spent a lot of time planning but you don't want to terminate the sprint and go through the whole process again so things like that is an example of you are getting attached to your plans you are getting attached to delivering to that spec it was interesting through mentioned about even if the requirement changes you want to still deliver because that has implications on the coding aspects and the development aspects so you want to stick with that you know we are not saying that is wrong we are saying that is something to think about in perspective that sometimes that is a valid thing to do sometimes it is not we try to build this silver bullet answers that this is the exact way of doing everything we try to apply it everywhere and you know it doesn't work that way we need to move on one funny point is that we also notice there is a lot of overhead that you put in the process when you do something like this which in a lot of cases ends up being wasted effort also how much time do typically people spend on their release plans rough numbers one day, five days, one week 15 minutes 6 months half an hour half an hour one day on release plans what about sprint plans zero minutes where to go again think about these things is our point how much time you are spending how much value is it adding one question here if you take a complete organization there are too many people working and if you want to make people not delivering exactly at least have some collaboration to be working between them then you need to have a plan at least an organization level when you are building a product say for example thousands of people can work in it and there will be hundreds of teams so how do you get them on the same platform so that everyone so two things we are not saying don't have plans we are not saying don't have plans we are not saying just that hacking code and that's how you will do it the other thing is also a lot of what people talk about is push based planning push scheduling there is a lot of literature where they talk about full based planning there are all these examples that we can learn from and look into what are the differences how you can plan for a large project like a fire state building without having these huge grand plans so there are answers that we have to go find out and find and look into in our context what applies what makes sense in our context with the kind of people we have with the constraints that we have in our system what will make sense blindly monkey seeing monkey doing so we might not be able to cover everything that we want to but for example I have some examples that I could give to you from the perspective of how full based planning help us you know to deliver better as opposed to a push based plan so we could discuss that over lunch or whatever whatever place I think it's also very context per sensitive in my current company we don't do it but in my previous company we did it and it was actually pretty well and that's I think the message that we want to give as well which is that it's all contextual you have to think about your content don't blindly do stuff you have to think about whether this is important to you or not or what value it's giving to you Next point iteration and time boxes so what do you think what are the motivations behind having iterations and time boxes kind of building on the previous topic but going more specific to the iteration aspect the whole iterative aspect of things and with time boxes focus focus come on guys some form of tracking customer feedback customer feedback when you say customer what does it mean you have a time box for you basically get a customer feedback I want to dig a little more in terms of when you say customer are you referring to the end user are you referring to the product owner or the product manager who is the customer in this case the product owner and the end user the product owner and the end users that's something I have not seen a lot happen where you involve the end user at every sprint boundaries at every time boxes basically we do a demo for the end user that depends on the product that depends on the product that's kind of what I want to get at who is the customer in some cases that's not very clear right you will also get a clear idea about what are the items you need to release that would fit at a much higher level here you are talking about iterating the sprint boundaries the time boxes you are trying to say these are the set of things I want to work on and I want to iterate over them a few more times before I actually put something out there or maybe it's ready enough that I can put things out there so it's more about the time box attitude that I want to try and take this time box and work on these set of activities so focus is one of the things I noticed that helps it's about commitment getting people to commit to certain things so in that time box sorry you tend to collaborate better I mean when you have iterations between teams you tend to collaborate better that's not my experience but I'll take that point some kind of a rhythm some kind of cycles that you are going through it makes you work more streamlined there is a continuous improvement you see the iterations and you evolve and take a more streamlined towards the code more streamlining at some point I want to discuss the result and the streamline as well and you get to it maybe later so tell me if you want to share some of your experience in terms of iteration because no one explicitly mentioned in that way but one of the main motivations behind iteration was to avoid thrashing which is someone also pointed out that when I started working on something if I have multiple stakeholders stakeholders they all have a different opinion of how maybe this should the direction that we need to take and everyone will come and tell you that I think this is what we need to do this is not working out, this is not constructive so what they did was they built a wall around it they said this is our iteration boundary within this you can't tell us what to change you tell us before that and then we go into our rhythm and we start coding and then after that you get a boundary where you can change the plan again but we need those gaps where you are not disturbing us at all so that's primary and that's such we know thrashing you can't get anything done because there are too many things happening to you there are too many direction changes so you are not moving in a forward direction you are going all over the place context switching and thrashing because of that people are context switching and thrashing and those are the problems that the time boxes we are trying to address so one of the biggest issues that we have seen with iterations is that they tend to batch up work what that means is that if you are doing some things and two of them are done they still wait on the other three to finish to get that feedback to do that customer demo this also tends to eventually get very water polished where you are doing this in stages within those boundaries which sort of doesn't help in some sense if you see people bashing up waterfall the big reason they bash up waterfall is they say you do this one phase you do this one phase really batches you are batching things and you are moving through the analysis machine through the design machine through the coding machine and you are going through this big batch when you have done all the analysis which means you have built up a whole inventory which is not usable until you actually have something testable and usable by the user everything else is building up inventory which is a huge cost and risk for company so what the idea was that let's break it down let's come up do it in iterations let's break it down let's take these things slices or what people refer to as the least marketable feature let's take these marketable features and work through them but what we failed to notice is even in them we are still batching things up and maybe sometimes we are batching things that are unrelated because we want to fill the time box we have three stories that only comes up to x story points or x estimate we have some more time what do we do let's take one other thing and fill this up next to what is referred to as the capacity utilization over focusing on the throughput instead of focusing on the throughput now you are focusing on the capacity utilization nothing wrong with that we are not saying that is wrong but you know that's kind of actually what we were trying to avoid in some sense was to try and focus on throughput and not on capacity utilization so I have seen situations where you have you know a nutrition for a month you have to finish something at the end of five days and at the end of the month they are like what did I do there I don't know what happened there I have to revisit this again but finally because they batched they had to go at the end of the sprint one other problem which I have seen with iterations is like when people from other methodologies move to agile they suddenly look at agile as iteration as a smaller phase of multiple waterfalls and that makes it extremely problematic so you do an analysis sprint a design sprint that's also common but we are not saying what is the you can take any methodology and screw it up we are not going there let's assume you are doing it well but there are still issues with it there are still things that you might want to think about that might not work well in your context so we forget about people not doing it well let them have their cake and eat it too let's talk about people are doing it well and we still think there is scope for improvement we can still take it further because we are all talking about continuous improvement and continuous taking our art of software development further we try to focus on that aspect these are the issues even if you are doing it well you are still batching up you still have things that are going wrong you still try to fit something which is focusing on capacity utilization which might not necessarily be the goal that you are trying to solve 15 minutes to go my favorite topic so what do you think is the rational behind estimations and what are the advantages of estimation predictability sorry predictability that's interesting transparency transparency all controversial prioritization prioritization you got something which takes a long time then you might consider whether you want to put it up or down or where low value item takes a long time put it down so building an engine for a car might take a long time building a steering wheel might be a lot quicker so would you build the steering wheel if you build the engine like if you have the left wheel and the right wheel they are both the same value but one takes a long time then you might want to do the other one first I think both your metaphor and my metaphor kind of breaks down it doesn't really work so let's not go down that metaphor but that's a point about helps you in prioritization what are the points how else does estimation help what's the rational behind estimation why did estimation come into picture to arrive at the cost that's more of cost estimation so when we talk about estimation itself there are different forms of estimation cost estimation there's time estimation you can map these together and put some fancy formula and come up with some cost but there are different types of estimation are there any other types of estimations complexity complexity estimate and relative complexity estimate it will help it will help it will help it will help that's time estimation not necessarily complexity estimation will not tell you when you will deliver something okay it will help in improving estimation it will help support the continuous improvement estimations help you improve estimation but what you don't know whether you did something previously or not so it's time you got battery just so you can support the continuous improvement just so I can reword it if you said that it will take me 10 days and the estimate was estimate was 10 days but it took you about 20 days so now you can actually give an example what you said what you said complexity estimation it boils down to time estimation because that's what you are looking for time estimation a complex problem is going to take a little longer or shorter it boils down to for example if I realize that something is really complicated complexity as a context as well maybe writing a parcel is complex for me it doesn't matter but if there is a team of compiler developers they could do it in a day maybe so complexity is also valid in that sense what's complex if I realize something was complex I could maybe outsource it to someone who could do it maybe in a day for me so it might not necessarily translate into time in the sense that what I am saying is it doesn't directly translate into time but not necessarily time what I am saying is boiling down to time it's not corresponding to the time so it's one of the levers we could do this coordination by taking individual estimates of these pieces you can build an overall plan fiction it's a little far stretch for me but we'll go with that there's an aspect that we haven't discussed which is am I estimating everything up front am I estimating that up front to get that ideal I think it provides a platform where the team develops a better understanding of the requirements if I develop an estimation of somebody becomes satisfied then probably there is a discussion about why he takes it aside and why I think it is one so there is a consensus which goes on there is a discussion and the team develops a better understanding so if you want to decide if you want to go or not go it may make a big difference it's like one we're talking about the feasibility it helps you come up with the feasibility one thing what I observed estimation of that was like the prioritization of the task and second also it helps to distribute it like I have team members they are different based on the estimation like 20 hours, 30 hours they are different there actually is kind of quite contradicting to the whole self-organized team aspect where people pick the task rather than being assigned but let's say that works in your context and this helps you now I want to shift gears a little because we have other topics to also cover but with estimations has anybody feel this predictability paradox issue yeah what else predictability paradox the idea is that you know I have some knowledge of this if I have more knowledge about this if I spend more time on this I will come up with better estimates so when do you know it is good enough time to say okay I have enough knowledge to actually give an estimate so that is a very slippery slope for a lot of people including myself like you try to spend more time and a lot of time after spending a lot of time you still don't necessarily have a better estimate because the higher you climb on the mountain the better view you have the things but doesn't mean you know exactly how long it is going to take somewhere to get somewhere or things like that so what predictability paradox is just because you are spending more time doesn't mean your estimates are going to be more accurate which is an oxymoron how many people here think that because they have been estimating for a long time they got better at it they got better at estimating just because I have been doing it for a long time it is a problem because they are better at the same path and they know how much time to that's if someone raised their hand I didn't see anyone raise their hand if the context is similar if it is a similar one then yes it makes sense that is the case for everyone that raised their hand similar stories, similar common sense there could be a more probability of getting accurate estimations but there is more guarantee because people suffer from many other factors like the person and they are using the word guarantee but if I talk about probability and estimation is itself maybe an oxymoron also because I can't guarantee but the difference it is not like there is no say there is so many there is no say like estimation is it the project cost level and that also is a factor that's a factor as well what level of estimation are you doing are you doing the feasibility for example we need to know how many resources we need that kind of brings us to mythical man month in some case if you realize that you can't finish can you add more people on it and go faster experience is not always some kind of we can't just say how many people work in companies where estimation is mandatory how many people work in companies where you don't have to really give an estimate somebody else does it for us somebody else in that sense it's still mandatory and that's even worse that's even more scary as someone is doing the estimate for me there are actually a lot of points we wanted to go in estimation itself like the whole thing about lack of trust syndrome filling in the work fills in the available time and stuff like that how many of you feel as if when someone is asking you for an estimate someone has gone to your head and asked you for an estimate how many of you feel now Dave that's the aspect of the lack of trust a lot of times people are asking for an estimate because they don't trust people but then how do you break that I have been challenged by that why I take this let me step back I go with this it gives me an inference as to what it is for different people at different time in different instances just to clarify we are not saying don't do it maybe in some contexts it might be important the differences you draw from estimation are different for different people the management would like to see from a certain perspective but the team tells them what is in context available you have a certain number to it what is it that I am going to do when I get into the religious act of doing this in other sense you get caught up into this and tomorrow somebody else will actually the management will put a gun to you so in that sense I am kind of stuck between saying that I have to please somebody tomorrow and not get caught up or shot again and try to put a gun to my people so that trust factor or whatever so far junior how do I get out of that I mean these are issues so is estimation helping let's put it this way no it doesn't on the floor when you actually start pranking and working it is really probably bashed up in day one itself but the matter of the matter is everybody wants to know this number and then only you can get to start I have worked with a lot of consulting companies services company right and this is typical when they outsource they want to push the risk on you they want you to give an estimate and they want to say how long it is going to take how many minutes to go that's an estimate just putting a gun down that's actually all and a lot of times you try and do your best and you still end up overworking burning yourself out or you end up compromising on quality everyone knows of the golden triangle right the project manager's golden triangle now everyone wants more scope less time and less the more scope less time and less effort is there a way of saying the time that's one way I don't know I was asking for an estimate there have been a lot of cases where I have gone up to the CIO of the company and I asked you're asking for these estimates tell me in the last 25 years of your career when people have given you an estimate how confident were you about the estimate how did it make you feel what was your goal with asking the estimate what were you talking about other activities and things like that how much buffering did you do on that so if you sit down and have that conversation with the guy asking you for the estimate it boils down to a few of these things about educating them about the predictability paradox thing if I can deliver value at a constant stream to you that is a good sense for you to start seeing when probably things might be completed rather than getting caught up up front when you have least knowledge about the project when you're starting something that's when you have the least knowledge about it when you're trying to give an estimate at that point in time which is quite risky so instead of trying to go through some process and then seeing how you're going along by focusing on value rather than focusing on the how much hours and things like that seems to work better in my context here again I have an example if you would catch me over lunch we would discuss that as well a situation where we had the same problem over to showing value we had sales guys who wanted an estimate to give to customers we had management who wanted an estimate but we switched over to showing them value and now we don't do any estimates alone it's always associated with some risks and also leave an open disclaimer that this is supposed to find a subject to an act I just have a very bad taste with estimation I have been in a situation where we spent way too much time on estimation way too much time on doing that and when it boils down to actually getting stuff done none of that really helps you and it starts getting in your way obviously this contextual also there might be situations where you have to do it where it might help us but in our experience it's stuff that we've been working on in most cases it wasn't used to us but how do you define just one question 10 slides more estimation we need to jump ahead we can talk more about that but our idea is not to cover everything it's to spot these thoughts where people are thinking about these things that's our goal sustainable pace what is sustainable pace not burning earth that's the rational behind why you want to have sustainable pace but how do you define sustainable pace if you look at extreme programming the first version of extreme programming talked about 40 hour work week 40 hour work week is sustainable pace if you do more than 40 hours the chances are you burning out how many people believe in that the number for now and then we'll talk about doing too much what does that 40 hours mean to you guys does that mean that you're consistently delivering in those 40 hours I wouldn't say 40 hours probably my productivity is much lesser than that the thing is if you're working too much probably you're not being true to your team or later if someone else joins the team they're expected to work that much as well it's just not sustainable for anybody to continue delivering the same amount of work probably any customer expects more work out of you just because you burnt out on concrete so those are all the drawbacks you know those could not be problem and sustainable pace but those could be problem because of other things right that the customer you set that expectation with the customer and things like that is not necessarily a problem of sustainable pace or working extra we're not suggesting work extra we try to understand what is the motivation behind sustainable pace more focus if you're leaning towards getting burnt out then your focus starts reducing your mistakes and things like that but how do you know when to draw that line and is that consistent like in my experience I'm productive at certain time of the day I'm not productive at certain time of the day it might still mean I'm only working 6 hours a day you know that the focus thing is not something to do with how much you're working but it's more to do with what times of days suit better for you in terms of working there are weeks when I'm not productive right I could have a 2 hour session where I'm very productive and I could burn out or feel very tired I'm supposed to you know working for 8 hours I'm doing nothing except for being solid at me and there are also cases where you can work for 12 hours and still feel not burnt out when you're like really in the flow a lot of times and that's where we want to get at is the flow seems to be more important there are times when you're not in the flow and you could still be doing 6 hours and still not still feel burnt out you might not be enjoying what you're doing and you might feel burnt out after 4 hours of doing it and you might be in cases where you really enjoy you're in the flow you're in the groove of doing things and you can work easily for 16 hours I mean how many people have spent 16 hours at work and felt productive all of us most of us for 2 days for 2 days for 2 days I just lost out my paired partner we paired for like more than 6 months at about a very large 72 hour work weeks and you can ask him if he felt burnt out it's very subjective again what we're getting at one other example I want to draw is how many people study throughout the year for your exams how many people study the last day of the exam the previous day of the exam what happened to sustainable pace for 16 years you've done that and exams are for at least a week or more so we're told challenging that it's not 2 days it's probably more than that we've done that in a lot of times we need to move on in stand-up meetings a lot of people mention that they think that's indispensable how many people do stand-up meetings every day how many people are forced to do it every day how many people love doing stand-ups every day they look forward to it what is the value you derive from stand-up meetings we need to speak up we discuss like what are the tasks we do today and we also involve QA in that discussion we check with QA and what is going on how the what we're doing we can reopen those kind of discussions because we are a small company so we have a lot of issues during the discussion we found that some duplication of issues we can basically it's a very dynamic information tool for the project dynamic information it's for people who mentioned sharing across the team sharing across the team what about team bonding what brings in that keep on doing we didn't have stand-up for 2 days and 3 people ended up doing the same you did a stand-up and you said you did not do a stand-up and 3 of us ended up doing the same thing so why you guys distributed across locations distributed across locations I kind of meant it stand-ups the reason only being that the break-dreams of the tradition are to this and the ingrate of the why you need to do this so that the positive confrontation gets a lot so I mean as a post you are used to working in silos or in cubical kind of a mode that's one mode where you break out of it as a team and get the spirit going so I mean only in the initial sense but if you are mature enough in a couple of spirits and things like that I would not pay much attention to it as so long as it grows so couple of quick issues that we see with stand-ups one is again the trust factor a lot of people raise their hands that they are forced to do stand-ups that again is a sign that there is no trust between the team as well for them to I don't know it's hard for them to solve the problem as well they are just making it worse by doing it in some places it's also a symptom of micromanagement you know you see scrum masters or you see people asking how many hours left and that's kind of their version of stand-up meaning or deriving data from it so they can then what used to happen once in a month earlier now they can do it on the harassment the biggest problem that I have noticed is that someone mentioned communication there the whole idea is that you should communicate more I think if you are communicating regularly the stand-up then just becomes a formality it's just a formal thing that you have to do and stand and talk to each other and that doesn't build a team that just builds I don't know what it is frustration again when the transition one second I think when the transition happens from the traditional system they are fine to adapt towards the drive initially they allow for assistance but usually if you do the sprint planning transitions from one sprint to another sprint you make sure you give the team the perspective that this is where we got the value of the stand-up especially make sure there is a value and then retrade that you know, remove the jig okay end up with some things that helped a lot so there was this thing straight over there because I can go down that path and say because we went through waterfall because we went through this now when you have new persons coming on team do they also have to go through the learning project to appreciate the value or they can start with something that we believe today that's again something to ask ourselves because a lot of times we say they have to do this, they have to do this they have to do this because they can understand the value behind it but not necessarily because not all of us have done every single programming language to understand, appreciate programming languages that we use today there was a gentleman over there yeah again what you said like the stand-up but that's again an ideal situation like T3,T5 we're talking to you like that sometimes there would be a requirement T3 should get together it would understand how are we getting more正面 there is so do a just-in-time stand-up meeting no it doesn't matter stand-up meeting it can happen like coffee or a test but again the only thing That's the problem right and the word that it has to happen, you know when you don't have anything to share, what's the point of this kind of thing? In a room you just go to every day, put it on someone's office, put it in your office tomorrow, but again it has to be some forum where we need to be in sync on how are we feeling. The other point people talk about is knowing who is where. I think if you, you know there are alternatives to that, you know there are pretty much very powerful alternatives. If you have like a story wall, then you have a sense of who's working on what and you focus on making sure people are in sync with respect to the story wall. You don't necessarily need the stand-up meaning to know who's working on what, but we're not saying that discard your stand-up meaning. We are again saying that think about, you know, what is the reason behind stand-up meanings, we've done away with stand-up meanings, we don't do stand-up meanings anymore and it just seems to, for us, seem to work fine. The other thing I want to mention quickly is that, you know, people talk about continuous improvement, right? How do you do it continuously? What does it mean to do it continuously? And people usually translate that in terms of, you know, by making it a habit, that's how you end up doing it continuously, right? So, you know, you make it a ritual basically. Though what happens when you do that is when you create a habit, your mind starts switching off when you're doing that stuff, right? It happens with everything. So, which is the thing that I have noticed when you're doing stand-up. People then just switch off at that time. There's just a formality that they have to do. Proper training, all guidance also helps, because when people see how things are done in the right way, then they begin to adopt them. If they don't know how it is done, they just read from them. They say, okay, yesterday I did this, today I did this. Part of what we're saying is that it's up to the team to discover the right way. Somebody who's just doing training for the whole life can't come and teach you how to do stand-ups correctly. So, what happens is over time, teams evolve, projects evolve as well. So it was right for us maybe six months ago. It's not right for us now also. So you're constantly, you know, discovering what you need to do, as opposed to following, you know, one set of a process. But what we break is the favorite topic of clean code. TVD, repackering, simple design, whatever you have. How many people- This one's like, we're eating into your lunchtime. So if you guys want to leave, you can do that as well. It's up to you guys, yeah. Even man, if you get up and clean. How many people think clean code- How many of you have clean code? Put your hands down. Put your hands down. We work in that code. So who else? I didn't see the hands. Who has clean code? How many people think they have clean code? Half hand up. As everyone, you do constantly, you do continuous repackering all the time. You practice simple design. If anybody walks into your team, the whole notion is you only have the whole principle of what you need, the simplest possible thing that could work. Keep it simple and stupid. All of that philosophy. And it is not clean. Is it not- Sorry? It is good words, but it is not clean. It is probably lacking in repackering to half-hand up. Half-hand up. So if it works, what is wrong with it? That's the question we're asking. If I do it, I would believe that it is very clean code, that somebody looks at it and tells me to do it clean. So it's subjective. Yes. What is wrong with it? It's what you talk about in practice. It's not just about working, finding, understanding, and also finding. It should be, you know, like- We should have a lot of alternatives. Then we can say it's a clean code. We are talking about an agile. A lot of people talk about clean code. I'm cutting you short because I need to run. A lot of people talk about clean code is very important. TV, refactoring, these things are absolutely important. So by no way saying they're not important. What we're trying to highlight is trying to understand for yourself where to draw those lines. Where you say I've done enough of refactoring, where I've done enough of this. Because the reality is, if you look around, under the code bases you work, where people maintain code bases and stuff like that. How many of it is clean code? And, you know, very rarely people will raise their hands saying yes, it is clean code. And then you ask them, even if you've done TVD, you've done all of this, why is it not clean code? How many of you think there's a very strong correlation between clean code and successful products? Sustainance of a product. I'll add one more. Sustainance of a product, clean code is required. Sustainance of a product. I think that's part of what we're saying, what we're saying is that, if you all know the classic benefit curve, when you start doing this, you get a lot of benefit, but after that you'll slow down and you'll get incrementally much. The benefit that you derive out of it will start decreasing over time also. The problem is that we talk about this just one second. The problem is that we, developers sometimes, don't know when to stop also. People, this is a refactor. I see people spend a couple of points refactoring also. You don't need to obsess with the clean code, but it depends upon the context and business value and what is the kind of product you are developing. Absolutely. That's another point that we ought to make, which is that there are times when clean code is important, there are times when they are not. If you're starting off a product, maybe you don't need all this stuff. You just want to try out an idea, get it out to the customer, validate it, see if it works. At that point, discovery is more important than sustainability because you don't even know if this product anybody is going to use or not. Once you discover what the customer probably needs or have some sense of it, maybe you could then rewrite it from scratch, maybe refactor this, then you have to weigh your options and figure out what is the best way. And sometimes, starting with clean code because you're doing something extremely critical is important. And it's very context-sensitive. You have to see what is applicable in your context rather than saying, you always have to do this and this is indispensable practice. Because there are a lot of startup companies that we come across or we meeting these days where they don't do testament development, where they do some refactoring and they're still able to build the product, get it out there. It's not like, you know, they're struggling to do anything because they don't have clean code. Just one second. Many of us think it's driven by the customer's point. So the customer says, I want a result. I want 80 percent, you know, just cases to run. I can talk about ways to do that without having clean code also. Test design itself is a very relevant term and it is very difficult to define what is simple. So I believe something like performance testing and user acceptance testing can be mapped to how clean a code should be. Visibility has nothing to do with how clean your code is. And what I'm saying is that it's very difficult to define what exactly is clean. Like if I'm like four years of experience, probably I write clean code, which appears clean to me and there comes a person with seven years of experience and he tells me what, you know, what the SHIT project is. So it is very difficult to define what exactly is clean. So as far as my acceptance criteria, user duties are working and there is no substantial damage to the performance of the product, probably I would say it is clean. Right. Someone has to define those acceptance criteria. So I have a friend who has this, it's a Hindi dialogue where he says there is benefit but what is the benefit? Which means there is benefit, what is the benefit of that benefit also. A lot of times we think about the benefit but we never think about the benefit of that benefit. This is giving us this but what uses that to us right now in this context also. You had one last point. When you say a successful product, what do you mean by a successful product? A successful product can never break and works in all cases and makes money. It is basically all something that is embraced by people. That's a very good customer. Both? Product owner? Product owner. Product owner. Product sponsor. Product sponsor. Requirements like a program of delay. Requirements is like a? Program of delay. Program of delay. I would agree to that. Not if it keeps changing though. Yeah. That's why I wanted to require them. Fixed requirements. In my, I'm trying to cut this short so in my word, requirements is one of those four letter words. To me, you know what do you mean by to be satisfied? It's very vague. A lot of times requirements means that this is mandatory. The sense of this is mandatory and in software there is no such thing called this is mandatory. Sometimes people don't know what they want until they actually see it. Until they start using it, that's when they realize. Also, Fred Brooks talks about, you know, you don't know what the real problem is until you have solved the problem. So how can you define requirements? You know, in some cases maybe you can. But in a lot of cases, in my experience, I've never been on a project where we had the perfect requirements where we knew exactly what the requirement was. Requirement is also a solution domain thing. It fits into the solution domain. And a lot of times we forget to think about the problem domain. What is the problem that we are trying to solve? Yes, you need this screen. You need this screen. You need to do this. You need to do that. But what is the problem that you're trying to solve? Do you even need the software? How many people ask that question? Right? A lot of times, I've worked with NGOs and there are other people who will jump on and just say, oh, we'll build this website. We'll do this thing. There'll be this backend stuff. And you look at it and you say, you know what? All you need is pre-printed letters. You can send them. That's all you need. There is no software required. So what is requirement in this context? Is requirement about the goal that the user has, the problem that they're trying to solve? Or is it about this implementation of that problem, or implementation of the solution that you're thinking? So it's very subjective. And a lot of times, we get caught up in, you know, we need the perfect requirements. Let's spend time getting the requirements. And a lot of times, I've seen projects go down the lines of trying to get the requirements. Yeah, but in the context of product companies, requirements become extremely important. Where it defines what the product needs to do. Because that comes from the users. That comes from whoever. But at the end of it, when it is crystallized, you know exactly what the product is supposed to do. Not like what the user wants and all that. My experience is to give some questions. I work for a product company and I think the most important thing for us is feedback from the customers. We also need to discover what the customer wants. We can say, inside a room, inside a company, we only have opinions. We don't have facts. We get the facts only when we go out there and show it to the customer. Exactly. I mean, in our context, I mean, for example, when we want to build a car, it actually comes from the users. Like you build a concept, normally you think, but when you get it as requirements, so they have to be done to satisfy what we found outside the customer wants. Like for instance, some acceptance criteria even to produce a product in the market. Like for instance, specifications of some kind of product in the case of some mobile. So it's acceptance criteria requirements. One of them, which is mandatory, you have no escape room there. You have to say that there is no need for requirements. Actually, don't get into the subject as well. Whether too many, too detailed requirements are bad, requirements are bad. The whole notion of requirements, what is the requirement? I think it's primarily about the word requirements. It gives you a mindset where you think that it's absolutely necessary and you don't therefore tend to ask questions about do we need to do something. It's not my problem. Somebody else has figured this out. I just need to build this thing. That's the problem. Somebody else has figured out what the requirement is. I've been in way too many situations where someone's got a requirement and it feels wrong but they're still going to make it work. They're not thinking about whether I need to do it or not, but they've caught up in trying to make it work and I've seen so much effort in ways because of that. I just don't get dumbed by listening to the customer requirements. You need to take the requirements. Requirements come from everywhere. It comes from your CEO. It could come from your manager. It could come from anywhere. But the fact that you do the requirement itself sort of puts you in a mindset which is what you want to change. So mindset, this is there. It's given we have to do this. There is no questioning. It's kind of building this wall. They built the requirement. They tossed it over. Let's build this. Now, that's not what agile is about. It's about discovering what the end users need, what the businesses need, and putting both of them into perspective and trying to understand how can we do less software. Now, if you guys have read agile manifesto, one of the agile manifesto principles is simplicity. What does simplicity mean? And it defines that simplicity is the art of maximizing work not done. The moment you put requirements into the picture, that's challenging the whole simplicity notion. It's about doing as much as possible, as quickly as possible, and agile boils down to rapid software development. Not necessarily simplicity. That's what we're challenging here. I'm just reminding you guys again that we've needed 30 minutes of your lunch break. I think we should just close. Retrospective is another thing that we find is a ceremony that doesn't add much value. I'm not going to spend much time to move on. There are places where it's important, but in most cases it just becomes a ceremony as well. How do we get feedback? Retrospective is maybe one way of getting feedback, but are you going to wait, patch up things and get feedback? A lot of times you want to get feedback on a continuous basis. If something goes wrong, sit down, ask five times, maybe that's a technique. You don't have to wait till the end of the sprint or iteration. There are a lot of times when you can sense it, you can start inspecting and adapting instead of waiting till the end of things. There's a lot of notion that you start building ceremony around how to do retrospective. I've been in some of the sessions where the Uber retrospective facilities are there and the whole thing goes for a mess. You talk about all this stuff and how much is it really helping you doing these retrospectives? Is it helping you or just sitting down with people and having an appreciative inquiry kind of a discussion or some other kind of discussion is helping you? There's so many options. So let's not lock us down saying retrospective is the only way to get feedback of our process and inspect them. It's a collision point, right? Why do you gather inputs all the time? Interesting. I was interested in asking that question. How many people have been in retrospectives and never got done? They never got tested, right? So that's one of the points that I wanted to highlight. No, I'm just saying that we are not holding retrospective meeting, but say collecting, but you might be collecting what you have already done So it depends on how this drum master is actually drawing it. It's a drum master. It's a master. Right. All right. Quality assurance. I'm going to stop there. We can have that discussion later, actually. Scrub master, scrub master. That would have been the last thing, but quality assurance, I think a lot of people have by now read about this, building quality into the process rather than having the last thing in the process and slapping it on. So I just had a quick story that I wanted to complete and if you guys are getting late, please do leave, all right? The story comes from how looms used to work. So back in those days when you had looms, you had a lot of defects being produced by the looms, so what they would do is at the end of the day they would put two people who would sit in front of each other and they would start checking each cloth the moment the thread is missing they take this cloth and they say this is waste. You know, if there's some insect moving into the cloth, oh, new design, that's a waste, you put it out. So people try to sit at the end of the day and they find out and then they saw there's a lot of wastage being produced which could have been probably stopped beforehand. Now you have too much wastage so it's too high cost. So what they started doing was they started putting one person on the loom. What does this map do? The traditional waterfall kind of a mentality where at the end of some phase you sit down and you check things and then you raise them defects and things like that's wastage that you have checked in. Now people in agile world say let's put the QA people on the teams. Let them be embedded in the teams and what happened in the loom phase is they had one person each loom but they're still so subjective because it depends on the skills of this person. If the person has to go somewhere then will the person leave the loom running at the risk of something slipping through or stop the and take a productivity hit on the looms. Things like that started creeping in. Also in spite of doing that they still had to do at the end of the day some amount of testing to make sure things are not slipping out. So if you map that to your teams today you might have QAs on your team but you still need to do some kind of regression testing before a release and supply that you still need to do some other kinds of tests before the release. So that kind of maps to this and that's when Toyota which is the precursor to Toyota as a company kicked in and they started manufacturing looms. They said one of the biggest problems we find is missing breaking threads and how can we fix that problem. So what they started doing is they started putting these small livers on top of each thread and as soon as a thread broke it would go jam the machine and that way you know broken threads didn't slip through and they started building quality into the process. They went on to innovate by you know basically having automatic thread replacement they had parallel threads so that if one broke it would not take any term and they actually went on to innovate by building quality into the process rather than relying on after the fact check of something going wrong. Now you take that and you draw a balance to what happens in software and it's interesting to see that you know there's so many lessons we can learn in terms of how we think about quality assurance. You know somebody coming in later and assuring you that the quality of the product is going to be good. I try to introduce something into the system in our team. By saying that we'll ring a bell as soon as we find a bug and everybody will stop working that's what they used to do. That's the Toyota stop the production line culture. So I got a very strict response to that. Do you think the customer is going to allow us to sit down and wait for something to be fixed which was not their fault but the team's fault? Why should the customer waste their time and money? Waiting for some quality model to take place and you know and make things better. So how, if it is good as you probably are going to suggest, how do we incorporate this in the production stop? How do we get the customers So there are lots of I think that's one way to do it, making your production stop. I think it's more about building it into the process where you're doing things. Stop it from repeating again. Not necessarily telling everyone to stop programming now. CI continuous integration is one of the manifestation of that thought process of the production line. If somebody checks in the build breaks, then you stop and whoever checked in has to fix it before they proceed. So that's kind of the manifestation of stop the production line culture. In a distributed environment, the guy who checked in, it takes a lot of time, his state is waiting his state is probably not well, his wife is falling and he goes off. And the build breaks at the half now. The onsite team is sitting out they can't do anything because according to the team's rule, it says the guy who broke it must fix it but the guy who broke it is not there. There are a couple of things that we can do. For example why does the build take half an hour maybe that's maybe the first question that we might tackle. So there are a couple of things that we can discuss in the afternoon. We want to end this and we want to let you guys think about now in this context, just take a minute and think for yourself what are the practices you think you can throw out of your project. Think to yourself, I don't expect you to give an answer. This is a thought we want you guys to leave in terms of thinking about what are the practices you can throw out of your team and still be as productive as you guys are or as happy as you guys are or whatever your measure of success is. Maybe throw out seems like a very drastic word. You want to think about it in terms of what are the practices that are getting in the way. What are the practices that I'm not happy about. What are the practices that I don't think are providing any value at all. What he has to throw out. So this is the real thank you slide guys by the way. No one needs to harm in the making of this presentation. And this presentation was made using only recyclable trick sets. Ask the feedback but it's like they're not going to use that. That's it guys. Alright we'll have lunch and then we'll be back here for programming with the stars at 2 o'clock. Not much time.