 So, this session is a workshop on Agile MythBusters. It's based on really something that I wrote in 2007 when I kind of really decided that I'm done with Agile. And I kind of wrote this blog about all the myths that are there in Agile. But I think it's been seven years since I wrote that and I believe that there are a lot more myths, maybe 100 more myths that have been added. So what I want to do is basically over the next 45 minutes, the first 10 minutes, we will spend collecting a list of facts that you believe are really, you know, like the true Agile facts. And, you know, we will work in smaller groups. We will pick up facts from you guys and then we will select as a group top six facts that we want to debate about today. So that's how it's basically structured. Disclaimer, if you're here to listen to me for a presentation, then you're in the wrong section. You should go find some other sections. It's going to be mostly you guys doing the work because you are the real experts. I have not been doing Agile for maybe seven years now. So, you know, you guys are better experts than me. So, again, if this is what you're looking for is a presentation from me, then this is the wrong session. There are other wonderful sessions happening. You should go there. Use the law of two feet. Did Ravi talk about the law of two feet? Use the law of two feet. So, what I want to do is if you guys can come together in smaller groups, that would really be helpful. And especially if you're from the same company, try and sit on another table because you're not going to learn much more if you're going to hang around with the people from the same company. It doesn't matter. Five people should be good enough. Why don't you join another table? So, this will be good. One, two, three, four, five tables. That's wonderful. All right. Someone's calling me. Let's turn off my phones. Basically, I'm assuming most of you work in the distributor to come in because, you know, as I presented the proposal two days ago, put it together with the distributor dropout. We really want to touch upon the effect of Agile in the distributed environment. The myths around that actually get compounded when you talk in the distributed environment. So, I do want to make sure you bring in the flavor. What are you seeing in the distributed Agile environment? Are facts about Agile? And then we will look at whether they are myths or not. So, in each of your groups, you're going to talk about this. So, for example, fixed price contracts, you know, can be done beautifully in Agile. That's the fact that you believe. So, you know, put that down. Or there might be other things, you know, you should do distributed retrospectives, for example. So, that's the fact that you believe that it's true. And then we will talk through if that's a fact or it's a myth. So, take five minutes in your tables and come up with a list of facts that you believe are true about Agile. You have people from the same company sitting at the same tables. You should try and find different tables. Now it's okay, but you should try and find different tables. You don't work with each other. Okay. Top three is good. Let's consolidate to top three. I want you guys to please pay attention. It's a group learning activity. So, let's pay attention, please. So, you know, what you can't do in ten minutes, you can do in one minute. So, we thought three is good enough. The first one is I think Agile demands a high level of discipline amongst all team members. High level discipline. Yeah, to be successful. Second one is Agile works when all departments or all organizations complement Agile. Otherwise, Agile becomes a namesake. So, you can't reap the benefits. All teams are all departments. All departments. So, when we say, you know, just not IT, you know, the consuming organization. Yeah. All departments work in sync or have the... Compliment Agile. Working in sync is not the word that you want to say. Compliment... Compliment or follow Agile. Or follow Agile. Last one. Co-location works better than distributed Agile. Co-location works better. Okay, cool. We'll go to the next table, please. Let's go with three, top three. Yeah, first one is the crumb of scrums effectiveness. Scrum of... Scrum of scrum. Scrum of scrum. S-square back in the days, that's what it was. I don't know what they call it anymore. S-square works better, is effective. Time zone management. They're saying it's effective. That's a statement, right? Now, whether it's true or not, we will debate it. We'll debate it. I want to phrase all of them so they are a statement of a fact. Zone issues are there. Time zone management. Distributed Agile does not work when you have time zone differences. Yeah. That's a statement, right? It has to be managed. Distributed Agile does not work with time zone differences. Velocities. Okay? Last one. Yeah, velocity is often misused. The term velocity. Velocity is often misused. Anyone misuses velocity here? Nobody, right? It's always somebody else. We are all the perfect guys. I'm glad I have the right guys in the room. It's all the other guys fault, right? Cool. Thank you. Agile doesn't mean getting project delivered faster. Agile does not mean delivering faster delivery. Yeah. It's more of quick feedback delivering what is the value. Okay. Second one is pair programming doesn't really mean two person doing one job. Pair programming does not, doesn't mean two people doing one task. Is Agile a fit for a fixed price pricing model? Agile works in fixed price. Is it only fixed price or fixed price, fixed scope, fixed? There's nothing obvious to me. I'm just a moron, right? So you have to be very, very specific. Fixed price, fixed scope, projects. Fixed time as well. Throw the iron triangle in there. There's a bonus point which is Agile is 80% hype and 20% fact. Agile is 80. So 80-20 rule applies everywhere, right? Yes. 80% hype, 20% fact. Yeah. Is that a fact? I don't know. Next table please. So we have top five. Two is already there so I will not repeat those. Perfect. The first is proxy PO or proxy scrum master. So proxy PO or scrum master is the right thing to do. Tools play more important than individuals and interactions. Of course, tools and processes are more important than anything else in life. The project manager is playing the scrum master role in offshore kind of environment. PM is the best SM. All right, we'll go to that table. Let's cover the other groups and we'll come back because I'm running out of board space. This is why we had index cards to write stories. We left that long back 10 years ago and now our stories are two page narratives. I think you've got one of them there already. Velocity as a metric is killing agility. Velocity is killing agility. The next one is Agile equal to no documentation. Agile equals no docs. The last one is cross killing is difficult in distributed agile. Cross. Cross killing. Cross killing. Cross killing. Okay, the whole. Cross killing. Scaling. Scale. Scale. Scale, right? Cross functional teams. Yeah. Or cross functional or generalizing specialists. Some are playing multiple roles. More roles. More roles. That's what you meant, right? Yeah. Cross scaling. Skilling. That's cross killing. Cross killing is what's your statement? Is difficult. Is difficult. Okay, cool. We'll go to this table. Last table. Our independent teams. Okay, skip that, right? Just come to which is not covered. We only have 45 minutes. Agile equals not... Nobody's accountable in agile, basically. Everybody is accountable equals no one is accountable. Agile meetings. Or should I actually say scrum meetings to be very particular? Agile not equals scrum, right? Scrum meetings is very productive. We will see, right? What's the fun if we let the cat out of the bag already? Scrum is stressful. But nobody's accountable. These are wonderful lists of facts, right? This is good. This is a good list. Are you guys happy with this list? Then we can go home. All right, so we need to pick a few of these that we will actually go and debate in detail. What I'll do is I'll do a quick run through this and maybe we will pick some of the obvious one and knock them out so it would not take much time. And then the real meaty ones we will spend more time and we'll go into detail, right? So hopefully we'll cover a lot of these. Agile requires very high level of discipline. Everyone agrees? So should we change the name from Agile to Disciplined Agile Delivery? Dad, anyone's heard of Dad? Disciplined Agile Delivery, right? That's there. The focus is very heavy on, you know, it's about discipline. So you really need to be very disciplined. So we are saying this is true. Everyone in agreement? Let's move faster. All departments must follow or complement Agile. Agile should work, you know, in an Agile fashion for Agile to work. True? Not necessary. Let's hear it. So you're in agreement with the fact but here we have folks who... I don't think they all have to be in coordination. I mean it would be great but I don't think it... I don't think it would be great for us to be successful with Agile. So let's phrase this this way that, you know, businesses can still succeed if not all teams are practicing Agile but it would be great if everyone was practicing Agile. They need to be aligned. Compliment. So they're saying complement not just follow, right? So let's put this as true saying it would be great if this happened, right? That's what's easy. Coalocation works better for Agile. I will park that because I have an extremely strong opinion about that, right? So I'll park that and we'll come back to that. The whole Agile team is co-located. Product order, sales, marketing, HR, whoever you need to be successful. So I'm leaving it. Let's not debate it. We're going to come back because we get off the easy ones out and then the hard ones we will spend some more time because I think there will be lots of different opinions from different people, right? So we want to hear it all out. So let's leave that. Agile equals no docs. So what do we mean? Let's spend a minute talking about what do we mean by documentation? I am assuming, right? I'm assuming when people refer to documentation, they're mostly talking about process related documents which are done, you know, to ensure that there is some amount of sanity in terms of the process or someone can audit whether you're doing the right things or not. That's what I assume people are saying when they're referring to documentation. Is it the safe assumption? Any documentation done to satisfy process adherence, right? It could be code related. It could be me having bath related. Doesn't matter. Anything that is process driven by process for for auditing the process. Writing user stories can also be considered as documentation, right? Agile equals no waste form for documentation. But how do you define wasteful? Because we can't even agree on what is documentation. Documentation is not required to start, but it is required for reference in future. Agile manifesto only says working software over comprehensive documentation. Not instead of? Yeah, it's not instead of. I don't think that's a confirmation as long as you don't overdo the documentation. I think the manifesto is fine, right? But I think they left a lot of gray areas. And because of that there's a lot of confusion in terms of does it mean, you know, I can do this kind of documentation, I skip that kind of a documentation. So we'll go there. So is it safe to say that the team should be able to decide what is the right amount of documentation for their project instead of external people dictating what needs to be done? Stakeholder is part of the team to me, right? You'll not be successful if you don't have stakeholders as part of your team. They don't have to physically sit next to you. That's fine, but it's a virtual team, right? Because you're working together. You're working together to ensure that what stakeholders need is actually met. So in that sense you're working as a team. Because if the stakeholder is saying I want this and the team decides to do something else, then they're not working together as a team. That's what I mean. It doesn't have to be the physical team in that sense. The stakeholders would demand some of the documents for operating purposes just because it's a government form. Absolutely. You would have to take some of the optimal documentation. I agree with you. I work for medical organizations where you need to follow certain amount of documentation for you to get an FDA regulation clear even before it can be pushed out, right? That's a stakeholder to me, right? The FDA is a stakeholder to me. And we as a team have to figure out what is the optimal amount of documentation that adheres to their requirement but doesn't tax the team beyond what they need to do. If it fits into the category of we are factual, we need to provide it. We are not sure. We are writing it now rather than doing it later. Okay. I was hoping that we're consolidating it and everybody seems to be in agreement. This is... We'll be always doing the extremes. Either it will be... Most of the times it will be like no documentation at all. Like you are not in the code, no technical details, no technical documentation and stuff like that. Or if you have to do, we'll go and we'll go and do it next time. The extremes is easy to follow, right? It's about trying to find the fine balance which requires lots of experience. It's easy to make extreme statements, right? Either ways is easy. So I want to move. There are a lot of other good points. I want to move. I would say that we have busted this. This is a myth. Agile equals no documentation. Scrum of scrum is effective. It's a fact that scrum of scrum is effective. I want people to give the verdict. Do they think it's... Is it effective or it's not effective? Anyone's being in a successful scrum of scrum. Define success. Because the teams are complaining about each other. In a release level retrospective, the teams are not complaining about each other. That's a good point, right? About the scrum aspect. It's not about retrospective. You are complaining about scrum aspect. Scrum aspect is part of the team. So we are saying they are not complaining about others. The teams are able to proceed without selling any roadblocks. If the coordination between the teams is smooth, right? They are not waiting on each other. Then we would say that scrum of scrum is working effectively. It can be effective but it's often not. It's very often not. I'm trying to get it. I would say that it's not effective. It's a bad idea. It's a stupid idea, I would say. But I want to hear what people want. Because it's not about me. It's like a Chinese whisper we had in the previous session. In the previous session. It's like most of the information gets lost. Scrum of scrum, most information gets lost. It gets to the team. There becomes a controlling authoritative body rather than a collaborative environment. These are hard problems that people are facing. You see the video spot or something. All three locations come. Time zone for some people it does not matter. Indians can always work very late at night, right? What's the big deal? That's a fact. It's a necessary evil. So we can rephrase this saying scrum of scrum is a necessary evil and say that's a fact. All right, I'm going to park this. I'm going to park this. You're going to come back. Distributed agile does not work. It's kind of simple related. So we will come back to that together. Velocity is killing agility. What does it mean? Anyone's going to debate on that? Yes. What does it mean? The measure the team have gauged over multiple sprints is then used by project managers or outside management to push the team harder to say why have you achieved me a velocity you're going to have to work like, you promised this now deliver. I want to summarize what he just said. So everyone's in agreement with velocity one of the problems that we run into is that external outside the team people outside the team or stakeholders probably start pushing for higher velocity. They start using that as a measure to push you harder. It becomes this thing about, you need to do better. You need to work longer. You need to work harder. You need to do whatever. It becomes a thing in itself that people are after. I would actually argue that we completely missed the forest for the tree by going down the route of velocity. It was the guys who originally came up with it any clue who was the person who came up with velocity who came up with the idea of story points. What Cunningham and Ken Beck were the guys who first came up with the concept of story points velocity. There was another thing called load factor which got missed out when the scrum guys borrowed some of the XP stuff half baked. Velocity was discarded very early by Ken Beck and what Cunningham is saying. We are actually measuring the wrong thing. We are measuring output not outcomes. We are measuring how much code can be generated how many features can be completed how many stories can be completed but we are not measuring whether this is actually helping achieve the goals of the users or the business or whatever because it's kind of orthogonal. I could build 500 features but that does not mean that will solve the business goal that I have tried to set out. So they kind of discarded it very early but somehow the rest of the community without naming any particular community seemed to be running very crazy off the cliff with that. What is wrong in going behind velocity? At the end of the day Agile is also to be about being productive. Agile is about being productive should we put it out there I have also different experience in a big distributed project we train our management first to understand velocity so nobody is pressuring people to get into higher velocity because we know that then people start to take statistics or just give arbitrary velocity values but we use very strong transparency we get by the velocity from each team and to see where something is going wrong and where we have to discuss with the team and not about pressuring them but about helping them or they are helping them in moving So we would educate the management to do some of these things but I am questioning the fundamental premise of velocity itself. Let's take a minute because I want to put this to rest. How do you calculate velocity? Number of story points completed in a sprint? Accepted in a sprint? Number of story points accepted in a sprint? Perfect. That's good. How do you calculate story points? Based on complexity you assign Fibonacci series What do you assign? T-shirt sizes? Fibonacci series is the most popular one from what I know. What was the reason behind going Fibonacci series? Because you don't want people to say two is two times more than one. It was about sizing things differently relatively saying this is bigger than this but I don't know is it two times three times or five times I am just going to assign these arbitrary Fibonacci series numbers so we can distinguish that they belong to different buckets. Everyone in agreement with that? And the other reason for doing that was so that you cannot apply arithmetic on top of it. You cannot apply arithmetic on top of it. So I have assigned one story point, three story points, seven story points or whatever numbers you use. And then we total it up and we say this is our velocity. Let's say our velocity is 20. Next sprint if I pick 21 pointer stories you know where you will be in soup. So the whole velocity is fundamentally flawed. It was only very originally an idea that people were toying around and they immediately discarded saying it's a bad idea. But we seem to have been stuck with it. So that's the problem with velocity. Arthematics cannot be applied on story points but we seem to be going crazy doing not just arithmetic but statistics on top of it and you know comparing teams and doing all kinds of crazy stuff when it kind of was really what what Kenningham was trying to do was getting people away from talking in terms of effort required to do something or measuring people on those basis. Aligning number of hours per student or whatever student. That's the next step I suppose. That's always been there because if you see a lot of trainings also people you know it's very hard for people to grok their head around the concept of story point. Because a lot of people are used to thinking in terms of effort estimation. How long is it going to take? That's what we've been asked from childhood and we're so used to it. So when you say story point you're also thinking four hours so two story points. And right there we've missed the forest for a tree. We kind of completely missed the point. So I'm going to not debate too much I want to move on but I would say this is clearly so actually the way it's phrased is this is a fact. True or a fact. Agile does not mean faster delivery. Is it a myth or is it true? Agile means faster delivery. Agile means faster delivery. How many people for? Agile could lead to faster delivery but Agile does not mean faster delivery. Agile could lead to faster delivery but Agile could completely drive you down faster down the cliff. It's a wonderful way to drive off the cliff because you're fast. And when you're fast you can go down in the wrong direction and burn all your money very fast. What's missing in Agile? People focus a lot on working software but the wrong software. Look inside your organizations after moving to Agile how much of the features that you have actually built very fast very good quality, very high quality all of those things come along with Agile. You get high quality, you get faster all of that good stuff but how many organizations if you look inside you've been able to be more closer to what your actual market required. When I've talked to customers when I've talked to companies this is one of the big challenges they face. So Agile does not mean faster delivery. Agile can lead to faster delivery but still be careful. The disclaimer is be careful that it is a great way to drive fast down a road which might be a wrong road. It certainly helps because you can get faster feedback. You can do smaller iterations and you can get faster feedback but how many people actually do real iterations with real customers. So you're not really getting feedback if you're just doing demos every sprint. You're going to get feedback when you actually can see real users using it. And again that's something that does not happen so you don't even get really faster feedback in the true sense. You get feedback saying this yellow button doesn't look good, yeah I know that. It's about whether you even need the screen. Is there a better process? Is there a better optimization in terms of your workflow that you can completely avoid all of this stuff? Those are the kind of questions that people should be asking in my opinion. So what do we say? This is Agile does not mean faster delivery. Pair programming does not mean two people doing one task. I would say it is a myth. How many people for myth? My good guy. So why do others feel that in pair programming you can work on two different tasks? Why would you work on two different tasks? Kind of defeats the point of pair programming. What was the idea behind pair programming? Anyone? Where did pair programming come from? Not from extreme programming, sorry. Where did pair programming come from? No, I understand but I'm asking where did pair programming come from? Who originated pair programming? Which company brought pair programming? No thanks. Not Toyota, not NASA. There is actually a big paper written and what can he have talks about that paper. He says that's where I got the idea of pair programming was a very late comer to the extreme programming community. It was not something they started with. The company which used to build compilers. Anyone? Borland. Borland is the guy who originally came up with the idea of pair programming. But let's park that for a minute, right? What is the rational behind pair programming? Two people working together, why would you want to do that? It's a waste of time. It's never about expert and junior or any of that stuff. There are two different perspectives. We have Arlo Belsi here at the conference. Please go follow his feet once. Arlo Belsi is the guy who did a lot of research on pair programming and he's written a paper which was very, very popular, still is very popular. It's called Pramiskius pair programming where he did a lot of experiments on what is the right combination of pairing people and how much time should people spend together in a training session. Beautiful paper. It's a hardcore research that he's done. Should go read Arlo Belsi or go meet him and talk to him about his paper. I'll summarize what he came up with. Pair programming works most effective when you pair randomly two people and you swap them every couple of hours. That was his results of his research. Don't go by somebody else's research. Do your own research. But be aware of the research so that you can challenge some of your mental models. Anyone's read this book by Andy Hunt, Refactoring Your Wetwear? Yeah, few people. There is Dave Thomas here at the conference who's Andy Hunt's partner. Go talk to Dave Thomas about the refactoring wetwear. Again, a beautiful book where he talks about rubber ducking. Anyone's aware of the concept of rubber ducking? So a lot of times I'll quickly summarize this because this is a very dear topic to me and I want to put that to rest. When you're working if you're a programmer or if you're kind of doing some large complicated thing, a lot of times you feel stuck. You can't figure out, I'm debugging something, I can't figure out what's going wrong. Everything seems to be right but it's somehow just not working. You go call your friend, you call your colleague, you start explaining to your colleague and you're like never mind I found it. Anyone's experienced that? Everyone must have if you've programmed it. Why does that happen? When you start somewhere that you're just struggling there, when I start speaking something, I feel like, oh actually I did that and I just come out. Your mental model is out of sync with your brain. You're operating on a mental model. This should be here, this should be the values and why is this not working. When you try to explain someone, you step back and you kind of go through, you're trying to explain the reality to someone else. When you speak, it's a different part of your brain that gets activated. When you listen to yourself speak, it's a different part of your brain that is getting activated. You move from a single core, single processor to a multi-core, multi-processor thread. That's the simplest way I can explain why when you're explaining to someone else things work much better. That was the premise or rubber ducking. People keep a rubber duck. They don't need an actual physical person. They keep a rubber duck and they talk to the rubber duck when they're stuck. The first time I saw someone doing that when I was a kid, I was like they've been programming way too long. Why are they talking to the rubber duck? That seems like so freaking weird. But then I realized the power of rubber ducking. And then the guys at Boreland were taking that one step further. They said talking to a rubber duck can have such a great impact. If you're programming with another person, you're constantly looking at it from different perspectives or kind of making sure that you're in sync with what is happening, you would be much faster. You would stop yourself from even creating the mistake in the first place. Rubber ducking works well when you're stuck. But what if we want to even avoid getting stuck? So that was the premise behind programming. Personally, I think it's very effective in my experience that I have done and it's very effective and both of you are looking at the same thing. If both of you are looking at two different tasks, then I don't think you get this advantage at all because it's about talking. It's about syncing up. It's about making sure you're in sync. And Laurie Williams has done a lot of research. She's got a paper. She's got a book where she's done a lot of studies across things and she's published the book called Pear Programming Illustrated in which she talks about it's actually you get more productivity for however you want to measure productivity which is debatable. But you get more productivity when you pair program for the reasons that I talked about. Time check. How much time do I have left? I have five more minutes. All right. That's a good way to stop someone from asking questions. So it does not mean two people working on the same task. That's a fact. It is about them working on the same task. Pick one last one. I got that. Yeah, I don't need to look at it. Agile is 80% hype, 20% fact. How many people want to debate that all the consultants put your hand up? Right? Because all the consultants will say of course it is false. No? That's good. You're a good consultant. I think Agile and we are all the 4% it's the 96% that's outside who don't come to these conferences because they don't want the hype. Please please go watch Andy Hunt's webinar that we did before the conference. It's a webinar. We couldn't get Andy Hunt here, so we did a webinar with him. It's a free video available. Please, please go watch that in that he puts this point to rest. Andy Hunt and Dave Thomas. We invited Dave Thomas to come here. I'm letting the cat out of the door but if you are here on Saturday you should go to Dave Thomas keynote after writing the Agile manifesto Dave Thomas for 13 years has not gone to a single Agile conference, right? So he said Agile died for me the day I wrote the manifesto. Right? And this is the first Agile conference he's coming and he's going to try and put that to rest. Right? So he's going to talk about the video that I was talking about Andy Hunt's video where he talks about, you know, you ask a kid about solar system and the kid will draw the sun at the center and the planets around it. Right? That's solar system and most of us believe that's solar system. Right? And then he showed a video where he said actually the way to look at the solar system is the sun is basically heading somewhere at a very high speed. It's just like constantly moving somewhere and then the planets are just wobbling along with it because of the whole gravitational pull and electrical pull and it's just like randomly going somewhere we don't know we have no clue where it is so point he was trying to make is it's a very dynamic system not a static thing that's sitting there. Right? And he said what we were trying to do with the manifesto was to portray that image of Agile that it is it is this constantly moving thing none of us have a clue where it is going we are uncovering better ways of building software we have not uncovered all the ways but we are uncovering ways we don't know where we are heading but it's going somewhere but people seem to have put models and frameworks and all kinds of fancy stuff around it to make it look like a static thing right and then he talks about we completely missed the point of what we were trying to do right so I would say Agile these days is 100% hype right because it completely missed the point but if you believe in going back to the basics and looking at what these guys were trying to do there is a lot of benefit to be got out of the wisdom that these guys put together right so forget all the hype remove all of that clutter right look at what these guys were originally trying to do right there is a lot of wisdom in that in my opinion there's a lot of interesting stuff especially in extreme programming because it's very controversial it's very it shakes you fundamentally when you look at it you are like this can't this doesn't make any sense right and those are the kind of things you should be looking because what makes sense is already something that you've tried 100 times right like Albert Einstein says doing the same experiment thousand times and expecting different results is height of stupidity right so it's about you know if something does not make sense give it a shot is that might help you uncover something else but what we ended up doing is basically taking what makes sense extrapolating it to what we were already doing and calling it agile and putting a framework on top of it and another framework on top of it and another tool on top of it and that's agile so if you look at agile from that perspective it's 100% height right but if you go back to what these guys were originally trying to do and look at some of the things that don't make sense to you then there is a lot of wisdom to be learned from that right so I think I will not mark that but that's pretty much what we have so I'm going to leave two minutes for question answers and then we will you know let the next speaker come in I have silenced the room if I'm generating more hype so back in 2009 I gave a keynote called agile is the new waterfall which had 16,000 downloads of that presentation so I created more hype with that presentation right but I think people are smart enough to figure out what works for them and the rest I don't worry about I don't know where you got that number but that's beautiful alright thank you guys