 I find that Scrum is very old-fashioned. We are doing things now that are simpler, easier, and I find a lot better for even beginners to start this newer way rather than what's something that's 20 years old. 20 years ago, maybe Scrum was the best way to get started. Maybe 10 years ago, it was okay. We've advanced. It's like working with a laptop that's 20 years old. Are you going to do that? Just because that's what everyone's doing? It's crazy, but we keep seeing so many teams around the world doing the same thing. I've got a product owner, I've got a Scrum master. We find lots of problems with this and we've come to easier ways of doing things. This is why I'm not really a big fan of Scrum. I could go on and on about other ways to do things, but I don't know if there's a lot of time. It's just that I want you to realize there's life beyond Scrum. Okay. For me as well, probably Scrum is now killing agility. When we're being agile, we're looking at new ways of doing things. With Scrum, to some extent, we give it a lot of framework. You do these ceremonies and you should be doing these then you're a Scrum team and so on. In fact, I don't know of any team which does pure Scrum by the book. They always do something which is out, but they still like to call themselves a Scrum team without knowing how agile they are. I am also for that topic. You better be against it otherwise we're not going to go ahead in this debate now. Okay, I will give a viewpoint both for and against. This is the difference between being agile and doing agile. I don't know if this is specific to India or whether this is prevalent in many cultures. We seem to be so obsessed with these templates. Okay, here is Scrum. This is a set of prescriptions that it gives you. You're supposed to be doing ABCBE ceremony. You've got these roles one, two, three, four, five, and this is what your team size needs to look like. Unfortunately, in many instances, we tend to take these prescriptions at face value without trying to internalize the mindset and principles that goes behind it. That is what I call doing agile. So does Scrum kill agility? Yes. When we end up doing the ceremonies without trying to internalize the values and principles behind it. So here is the opposite viewpoint, where Scrum doesn't necessarily kill agility when teams don't know where to start with, when there is chaos and lack of orderliness and everything that is killing a team, you might want to consider asking, why don't you start with something that's still 20 years old but something that's better than what you're probably doing today. So yes, Scrum kills agility. In my opinion, Scrum does kill agility when you don't internalize the principles. But yes, there is a lot of value in some of the principles that Scrum created. What happens at the end of a sprint when you're trying to finish your stories but you haven't done testing and refactoring? The sprint's coming to an end. You haven't written any automated tests, you've done no refactoring, but your name is somewhere on some visible board and you haven't finished and you have some final work to do. What do you think happens? Spill over? Do you actually ever get to the testing and refactoring? You want to hit the sprint, it's the sprint ends, right? And you don't do the testing and refactoring. So we... So I understand this challenge is very challenging, so I'm not debating that. The way we try to address it, and we're not always perfect, but what we try to do is, as the sprint progresses, we try to see whether the stories are going to get met or not. If not, we might even draw a story and actually focus on something that's really doable. And make sure that it actually has all the things done, like the testing is done, the code review is done, and if we are strained by the number of stories, it's okay to drop the stories or drop the scope of stories. That is what we try to do. Okay, slippage still does sometimes suffer because we think by dropping a story, we have done the right thing, but sometimes we need it to probably drop too. So there are some mistakes that still happen, but that is what we try to do. Try to reduce the scope of a sprint if we feel that we really cannot complete all the sprint, but this decision should not be taken on the last day. It should be asked the sprint progress system, and that's why in various scrams, we don't just say what we did yesterday, what we are doing today, what are the intervals. We also try to have another question. Are our stories getting done? So we go story by story, so we do talk about story by hand, and then we try to answer the question, is this story going to get done in the sprint? So for each story, each day, we are asking the question to ourselves, is the story getting done? If not, we discuss, which is the least priority story in this sprint, we drop that so that all the other stories at least try to get done. This is what we try to do. I'm not saying this is the best practice, but this is what we have been doing, and I would definitely like to hear what is the other simpler way you do, because I'm really... Just on a lighter note. What is the function in those situations? Call the story done, create a small story for technical debt. Somebody was telling a story, you sneeze and you get a point. You were saying this. Yeah, on the initial topic, I would like to present a counter view. Is crime killing agility? Now, all of you said that there is a template that people want to adapt and go as a prescription, take it as a prescription. I would say at the initial stages of maturity, when you are not mature enough, that's what anyone would do. As a very young... We all have young children at home, and we have seen babies grow. So babies just repeat what you feed them. They probably try to imitate you, take it at the face value. They start memorizing some... Humming some songs that they hear on TV without realizing their meaning. And somewhere, they are going to catch up with us. So I think that's a valid way in which we progress. And even if you replace crime with something else, the same thing will happen. So why not stop? Counter point. I have a niece and an nephew. They don't repeat what we do. They have their own way of doing things now. It's just very, very new now. Probably my father observed that that whatever he did, I used to repeat that. But then these days, these kids, they have their own ways of doing it. That's how we are trying to move from... Probably it was there for a little bit of time when people wanted to move from waterfall to some more structured way of doing agile and then rather being completely agile, if I may also. People have... I mean, I've seen teams who treat a sprint as a waterfall. So they do waterfall, waterfall, waterfall, waterfall. And they say, okay, we are doing strong. That's the real danger when you go by them. Yeah. Things are getting faster and faster in the world. Something we used to do would take a long time. Now, we can do it much faster. My interest is in helping people become agile. Much faster. Like mature agile. Not years, not even many, many months, but how quickly can I get them to be relatively mature at agile? And for me, one of the biggest issues there is balance. There's a... With Scrum what I find is many teams adopt Scrum and they don't have any technical practices or any technical maturity. Agile doesn't even... These days, the most popular definition of agile, there is no technical stuff there at all. It's gone. I mean, literally, we go to places, giant multinational corporations, they say, we're doing agile, and they say, okay, so you've got your agile planning tool that you've spent the fortune on and you do sprints and stand-ups and that's what you mean, right? Yeah. And then what about continuous integration and refactoring and test room development? What about the things about the software? Because at the end of the day, you're shipping software, I think. But that's the hard part. So there's no balance from the very beginning. Now, when my six-year-old daughter learned to ride a bike, she did it in a way that I never did. She learned on a tiny little bike, it happened to have... We didn't go buy a push bike. We have these push bikes now. There's no pellets. But they're very low to the ground and you just learn how to glide with your feet up, so you glide and you're learning balance right from the beginning. And once you learn that balance and it's safe because you can always put your feet down. Anytime you start moving, you put your feet down. She moved from that to pedaling in one day. In one day, she's biking. Incredible. This to me was like, when I looked... and there was a father in the park that day and I was like... I offered him our bike to try and he's like, no, I'm not interested. What I'm saying is that there are faster better ways to learn and balance is critical. We have so many customers come to us and say, we've been doing this scrum for two or three years and we're not seeing any benefits and the software is still a mess and we're like... we come in and we're like, oh my god, you've not changed anything about the way you do software development. All you've done is turn yourself into sprints, estimators, story points, stand-up meetings and you think this is going to deliver value? I mean, there's a reason that I'm angry about this crap because it's hurting our industry. Agile is supposed to make a difference and this stuff's not. There's no balance. There's no real... rigor there. It's terrible. So to me, one of the main things about Agile was the putting focus on people and the thing that attracted me initially to Agile was the emphasis on developers, testers, the team members, the people and nowadays all I hear is process talk, process talk, process talk. It's all about process and you ask, okay, what's in for me? And it's like, no, no, it is about the customer. It is about faster time to delivery. It's about better quality. It is about this. And people are like, okay, that all makes sense, but what about me? And I don't think we have a very good answer, at least in Scrum where people talk about what is the role of people. It all seems to be so much process-centric. Thou shall do this. Thou shall do this. It's become like that. Maybe the guys didn't mean it that way but that's what we're seeing around us and I think that's hurting us. That's hurting us real bad and talking to someone, they said, yes, we are super excited. Our entire company is moving to Scrum and I said, are you really excited? Let me spoil it for you. So I asked them, do you know any successful company which was successful because of Scrum and they listed a bunch of names. I said, that's wonderful. Do you know any company that failed because of Scrum? And they were thinking for a minute. It's like, okay, any company that failed because of Scrum. So if you can say the company succeeded because of Scrum then you should also be able to find companies that failed because of Scrum. Well, I believe that the process is just a placebo. It doesn't make any difference. But if you give credit to companies for being successful because of Scrum, then you should also blame companies or Scrum for failing companies, right, if you go down that logic. And I remember Nokia was the poster child of Scrum. I mean, they used to talk so much about Scrum. They had this Scrum maturity model and all of that stuff, the assessment. And we all know the story what happened to it, right? And people said, oh, they implemented Scrum badly. Of course, they implemented Scrum badly. Scrum is beautiful but it was them implementing badly. I think that argument is really weak. I'm sorry, but you know I have to say something about Nokia that was involved quite a bit with Nokia and actually they implemented it well as well. It was not that they implemented it badly. If I know any company that is of that size personally, it is Nokia that has done a reasonably good job. I think reasons for failure are different. Yeah, Nokia's reasons for failure are different. And which part of Nokia? There's a bunch of it. No, I'm just saying that it is not that Nokia implemented it badly so you cannot play it. So I'll tell you what they did badly. Managers put the gun against developers and said you need to have 70% code coverage. True or false? Not that you're aware of. So Nokia also had to make it more simple and I thought it would be more simple and all that. No, that happened much later. So Nokia had two big divisions where they went Scrum. Again, I don't need to beat them down. I'm just taking an example for the sake of example. I have nothing against them. I know you're not Nokia. You're The point is that they had all these wonderful things that they were talking about Scrum and I don't think there was any mention about as Josh was talking about any of the engineering practices, but that's not true and that's what I'm saying. That's not true. There's a lot of mention of engineering practices but things like you need to have 70% coverage. You would have to things like this. I've gone into the company and I've seen tests and the tests have zero assert statements and basically they have a bunch of junk that they have written to satisfy the 70% coverage number. So they've done a lot of things which did hurt them in the long run. And if we talk about agility, agility is about knowing your market, knowing your customers, staying in sync with them and they went wrong probably because of that. Now again, we all can act very smart in retrospective and look at why they fail but I think they saw it coming right. They saw it coming really well. So I really have no opinion on anything else you're saying because all I wanted to say is Nokia at least parts that I saw did Scrum reasonably well and there are many many many other companies that do Scrum really really badly and to say that one of the better ones does badly I just wanted to come to that. There are many parts to failure only a few to success. So Scrum is just one of the things that help you succeed not many other part of the way. Let me add to that. It's not a magic word. This is a funny thing. So because in Scrum somewhere there's a small line that says the certification doesn't guarantee that you it is a small print somewhere. They didn't make it bold enough. I agree there. Yeah that's true but yeah anyway, I really don't think certification is the answer. Okay, I'm from Finland so Nokia is from there. Okay, so how I see about Nokia, Nokia case as a thing because Nokia was the it was the identity of Finnish people that time and when we discussed about safety what Joshua told me told us we discussed about safety so I think that Nokia how I see like Finnish like whole society that we are putting too much trust we put promises top of each other and it feels like I don't know Scrum or anything else but somehow it's just like full trust that okay this will carry this will go on and on but now as Nokia it's a mobile part of Microsoft. I feel in Finland how I see now when staying one and a half year in India so there are very many new things new like you know a restaurant there was no bird well it started from Finland but there you can do pop-up restaurant and I think lots of energy also freed after Nokia collapsed it and then there are some positive things also behind that okay so this is good parts of large companies collapsing that's good okay but they're also utilizing the practices so it's not just a Scrum they're also utilizing XP practices are we also going to blame XP practices as well for the collapse just so I'm clear my point is that there are several presentations I'm not sure the these conferences they came in and they said we've been very successful because of Scrum right this is statements they Nokia employees were making consistently at various agile conferences you can go back in history and you can see lots of places where they said we are successful because of Scrum right and I'm saying now that they've collapsed can we say they failed because of Scrum you can point to one thing and say we were successful because of that then you should take the counter argument as well you failed because of that it depends upon the situation I mean we were debating about the topic with the Scrum is killing Agility though Agility Scrum is just one part of Agility there are different practices when they came up with this manifesto it's not just Scrum that they actually discussed in Ohio they discussed all lot of practices in mind they came up with a manifesto there was a XP practices there was Scrum, Canva and all those things it's not just Scrum I think when we say I'm implementing a project in Scrum I mean we are considering only Scrum as the framework we're using but there are different other frameworks which comes together with this and they form it a team as an agile team so I mean if you use different frameworks or the practices you still can succeed so it's not just a Scrum which is killing Agility I think it's the way you are implementing it I would agree to that it's not just Scrum that's killing Agility but just going back to your previous point so let's talk about 2001 when the agile manifesto was written there's lot of misconceptions about how it was written I don't know how many people are aware but let's talk about a little dirty secret about how the manifesto was written 17 white guys got together in a skiing resort to talk about object oriented programming and object oriented technologies agile was never really the thing but they wanted to talk about lightweight methods you know how they were doing things and they all got in they debated they argued but they all agreed that we believe in similar values and then they try to put the values together and no one could agree so pretty much everyone left except Kent Kent Peck was there no actually Ward Cunningham and Martin Fowler was there and one other person I don't remember it was actually three people who wrote the manifesto right and then the rest of them came back and they said yeah mostly it all looks good except the last point and they changed that and then there was a big debate after that about you know what do we call it and you know a lot of people were very disappointed when they called it agile so that's a little story about how the manifesto was written I don't think they talked so much about the formal structure or any of those things and that's pretty much up to people how they wanted to implement it My only point is I think when we when we're saying that a scrum is killing agility is a scrum which is killing agility or if you combine a scrum with other factors or the practices and you start improving but still utilizing a scrum with other practices and you're actually doing a good job you know in developing your products do you still say that is a scrum which is not creating these good products it's the other practices which is creating this The single ring the bull neck the product owner role is really hurting people it's hurting teams it's a bad idea very bad idea Mary Poppendike who wrote the books on Lean completely agrees many people agree Shane and Shane's talk here he talks about the critical importance of a cross functional team where there's a value facilitator someone who's trying to facilitate value in the large multinationals that most of you work in these are complex software systems where you need input from all kinds of people to figure out what the heck to go do the idea that one person can think this up and manage the backlog and do this work it's crazy and you know all over the industry we see people saying I have the product owner we have the product owner we're doing scrum and I'm like you're on a religious disaster you're not listening to your support people you're not listening to your subject matter experts you're not listening to your sales people marketing people all of the architects their voices are not being heard when you pick what to work on so you can have a tremendous amount of technical debt but the product owner is not choosing to work on it and so great you're heading down on the road to disaster it is fundamentally flawed that's one of 20 things I could tell you that are really bad about scrum so yes it is an old fashioned approach to agility that is filled with hazardous practices hazardous roles and practices it's not it doesn't buy us much all I'm saying is there are better ways now I think where we're miss we are remiss in not publishing the better ways right there are better ways that there are pieces of the part so Kanban I like to see user stories flow across the Kanban board if it's in the doing column lane right we're doing it I can be working on it if I'm not done testing and refactoring there's no end of sprint where I'm going to try to hurry up quick and get it done so I look good that I got my story done no I'm going to spend the time it takes to get the thing done am I going to work on small valuable stories yes I'm going to teach teams how to work on small valuable stories that's critical to agility now scrum, Kanban crystal most of these methods right they all punted on something critical what are we building and why are we building it and is anyone going to use it the definition of done is brain dead brain dead because it doesn't look at the actual users using the thing it just says we finished here's the definition we did all of the work we did all the things it's done is anyone using it in production we don't know is it making anyone's life easier you don't know but we got it done we are not in the deliverables business there are people who deliver pizza they're in the deliverables business they deliver pizza our job is not to deliver features our job is to make better outcomes for users and most of these old fashioned kind of agile processes including XP they all punted on this critical thing focus on outcome newer approaches like lean startup they place a heavy focus on this so who's here I ask people has anyone read the lean startup book here show of hands very very few of you right start reading books like that and get yourself beyond scrum start reading the startup owner's manual talking about customer development and you're going to go far beyond scrum and these things are not advanced they're actually critical and we just missed the boat auto so that's what I'm saying there's just better stuff beyond scrum I think when they started the bottleneck was software delivery seemed to be the bottleneck back in the days and yes at that point it made sense to get the team together let them to work together and focus on getting the delivery out and that was the critical bottleneck back in the day I think we've moved way beyond that that's no longer the bottleneck now we have teams that can deliver decent quality stuff at a consistent rate that's not a delivery is no longer the biggest bottleneck where we have issues is figuring out what to build what is the most important thing and it's easy to say oh that's not my problem that's the product owner's problem but hey we don't have this let's figure all these things out we don't know what happens once we commit the code and how actually people are using it do we go back and delete other practices that enabled us to go and delete features which nobody's using if you're a startup these are things that becomes extremely critical for you because it's going to slow you down but I don't think we seem to be focusing on those things and rightly so because back then that was the problem so we need to move beyond it and we need to talk about things that will help us solve today's problem everyone's talking about moving to the cloud I mean how is these things going to help us get there how much focus is laid on the new ways of doing things I think those are the questions to be asked and by the way sorry one other thing certification is really killing us I mean I don't think anybody would debate on that there is an assumption as to which problem we are trying to solve I think sometime back Shane gave us a very good model about this thing with a small group he discussed four quadrants I forgot what that model is called yeah so in that model basically it says that if the problem is well beaten well defined you know what to do go with something go with the best practices like waterfall or whatever just you know what to do just get it done then when you know what to do but you don't know how to do that's where agile the development model comes in because now the question is not about what to do and when you don't know what to do that's where you are figuring it out that's where lean models will come out because that's where you will fail fast so it depends on which quadrant you are in and that's a good mental model to have so instead of just discounting scrum assuming that we are always in that we don't know what to do is probably a mistake it has its place that's a very good point the challenge is that we often fool ourselves thinking we know what needs to be built and I think that's the hard part how do you know what needs to be built if you don't complete the cycle if you're only going to focus on this saying we know what needs to be built we just figure out how it needs to be built then I think you miss the complete cycle that's where I think things like lean startup, continuous delivery things like this are focusing on completing the cycle completing the whole thing so you know for which kind of problems where you will it's not static there are certain kinds of problems where you know what needs to be done and how it needs to be done there are certain kinds of problems where you don't know what needs to be built so the team is not static the problems you're solving are not static they don't fall into a quadrant and you just follow a process so at different points in time you won't be in different quadrants which is why you need to be thinking about something much bigger which is end to end not just solving a piece of the puzzle next topic who wants to propose the next topic just thinking we have agile manifesto almost eleven half year old and when we say agile we think if it's not working we rapidly change so what sort of opinions people carry in terms of the agile manifesto needs some changes because we see software craftsmanship has been bit of one step ahead I'm not saying ahead but extended the agile manifesto so what are our valuable speakers think in terms of manifesto needs some sort of rewording or adding a fifth one addition to the fourth four things we have already we wrote a blog post a few years ago saying the agile manifesto did its job let's bury it, let's put it to rest let's move on because it solved the problem now we moved on to solving a different problem a lot of people got upset with that and they said that that's not expected from someone like you you should not be talking about things like this so I think I personally don't believe in going back and modifying things because that thing solved the problem let's move on there's craftsmanship, there is a lot of other stuff happening I'm not sure if we need a manifesto we've had we've seen the problems with manifesto I don't know how many of you were here at the 2014 conference that we had we had Dave Thomas who came to the conference and he did a keynote at the conference Dave Thomas was one of the original signatories of the agile manifesto and since the agile manifesto was written he said he's never been to a single agile conference this was his first agile conference after this and he said I wanted to get something off my chest and this is why I want to talk at this conference he's like long live agile let's just move on it's done, let's move on because there is no such thing called agile there is not a lump of agile sitting somewhere it is about agility and we've put it in a manifesto and we've kind of cornered ourselves thinking about it so he gave a new manifesto if you're interested and that manifesto is about talking about tacit knowledge so he came up with a tacit knowledge manifesto which I don't think many people talk about so if you're interested to look at that that's a good video to look at but the point I'm making is we don't need another manifesto generally corners us into thinking something and that goes out of date very quickly but people stick on to it for many many many years to come and that does more bad than good next topic I would like to introduce we had a keynote today about scientific learning so for me I'm curious how to introduce the scientific methods and learning to our teammates or to teams we work in like one alternative is to let's go and do a PhD on something and we will get 7 years of practice and expertise into these methodologies and why of research but how can we do it in our software development teams and setups so that we can learn because the last half an hour I was wondering what the hell is wrong like I have worked across 5 teams big teams 100 people, small teams, 4 people I kind of understand XP I have read like 5-6 books XP, Art of Agile Development Practice of Agile Development all that makes sense but all that is coming from some place that we want to move fast we want to deliver better software and these are the values that will help us do that so I was kind of wondering why people are talking about Scrum when they will talk about measuring empirically what works and do more of that or adjusting that so I kind of was a very great experience but I kind of found that rigor missing like why are we not talking about measuring things empirically and improving them or just basically scientific method more I think you already know the answer see understanding it and then how to actually do more of it and do more of it as a team any leads or any suggestions so it's about experimenting it's about small cheap experiments so the pattern in Fearless Change is called just do it and you I'm sure have great ideas and you may even have something specific that you'd like to try when you go back to your workplace and now what you want to do is involve a couple of other people to try it with you so just do it thanks I think I'm so impressed with the people in this country and that you have a lot of initiative and a lot of good ideas you don't need me to tell you how to do some experiment you already have an idea don't you yeah that's what I thought thank you anyone proposing the next talk this is just what I read in wikipedia about pay programming and some of the empirical studies suggested that it's not working effectively so I just wanted to propose this topic I don't know both sides of it because I never experimented it yet but I just wanted to understand whether there are any benefits of pay programming and if you know what the empirical study is done by so many people out there which have actually presented their stuff in wiki is it the correct way or we just have to try and experiment by ourselves and see whether it's working or not just going based upon my own empirical studies you know what I found was that in my own company with the product development we do when people did do some solo programming on our product defects went up and so I noticed that we have far fewer defects when we do pair programming you could say that well we could have replaced that with code review but we we tend to ship as soon as we finish something it ships it goes into production with continuous deployment so we like the pairing because it keeps the quality high keeps the defects low and it's more affordable believe it or not that's more affordable then if we start to have all of defects to fix you know development is not as fun and our customers are unhappy and so forth so that's my own empirical you know studies from that so if you were at the keynote this morning I did cite Laurie Williams book she's one of the few people in our domain who's done an enormous amount of research about some of little pieces of what agility is all about and she spent a fair amount of time focusing on pair programming and she has lots of experimental data that shows not only is it a practice that leads us to more productivity whatever that is but that the solution itself that arises from two brains looking at the code has higher quality whatever that is and so now there's plenty of evidence that shows clearly that what your initial reaction to pair programming is is false that we think that's a waste of time we've got two people sitting coding when we could just have one person there clearly we've got two people twice the effort expended for the same product and so it is a practice that takes a certain amount of overcoming of resistance especially by management and I think now we have enough evidence that we can show that that's not the case there are lots of other side benefits as well I'm looking around for the guy from JP Morgan who talked about pairing has he gone? he's also cited the paper that I mentioned this morning it was in tandem with Laurie Williams book we had Laurie's book on one side the reference on the other side was for Arlo Belchee so they've done something similar at JP Morgan and measured for them ideal times for pairing what kinds of pairings how long before pair rotation should there be a break how long should the break be he has presented some interesting data a little bit different from Arlo's in his paper so probably different context but people are starting to look at that now and not only are we looking at things like defects or code quality but what we can also see is other human benefits he mentioned one for instance about bringing new people in on the team and the way they do promiscuous pairing which means everybody pairs everybody they see faster introduction of new team members less producing of a bottleneck because there is an expert who is the one who works on a particular area everyone knows everything so there are other benefits besides increased productivity and increased quality I think the benefits now are clear if you look at what Menlo Innovations is doing they pair every role now to my knowledge at this point they don't have two CEOs but I think they are thinking about that so if programming was about typing code if programming was about typing code pair programming was the lousiest idea anyone would come up with but programming is maybe 10% about typing code 90% about problem solving about understanding the context understanding the bigger picture understanding where we are heading and a lot of times you are not driving in the same territory you are driving in unknown territories and when you are driving in unknown territories people use the analogy of a navigator and a driver and I think that is something to consider now I want to talk about so I talk a lot about benefits of pair programming I encourage a lot of teams to do pair programming I and Josh used to pair program quite a lot he used to stay up late in the night and I used to pair with him in the morning and we used to do remote pairing which a lot of people say is not possible remote pairing does not work and I think again program pairing is not about typing code if it was about typing code distributed it becomes really hard it is about changing ideas it is about getting on the same page it actually works really well since I left industry at logic I have pretty much been a one-man show so I have stopped pairing I don't pair anymore on products I build how do I feel about that is it really bad I don't think so I think I have I see slightly improved productivity in the short run and whatever productivity means to me I am just talking about I can get stuff done more faster it might have more bugs it might have other kinds of problems but if I am just looking at purely getting stuff done if I am working all by myself I think I can get more stuff done if nobody ever else has to look at the product I am building then I don't think it will be a problem but if you are working in a team environment where there are more than one people working on a product which in most enterprises that's the case then if just one person is working then there are knowledge silos and that creates other problems so what I am trying to get at is it depends on your context whether you want to use pairing or not it is not a silver bullet in my opinion if you are in an environment I have been to many companies here in India where they are given the design spec they are given the logic diagram of how you are going to write the logic and they cannot change the framework they cannot change things they have hard constraints around what they are operating I think pair programming would be a waste of time in that specific environment but if you said yes you could change the framework yes you could change you don't need to follow the spec you could come up with interesting things then I think pair programming would have real advantages if you put a lot of constraints and people just have to do coding not programming I distinguish between the two coding is converting from one thing to another thing you get a spec you convert it to another you know write it in the programming language I think pairing is a waste of time in fact I think programming having people do that is a waste of time you could just automate that and it could be done let's go little bit in history earlier people used to code along and people realized later very soon that people are creating not really quality stuff so let's review it that's the logical step so people started reviewing it then there are I keep using the word called pseudo smart people they look smart they pretend smart but they are actually not smart they came up with four eye review or whatever they are reviewing actually but only on paper or only on computer they are not actually doing reviewing they are just performing the process so people figured out that this reviewing is not really benefiting then comes this pair programming concept now there are two aspects of pair programming why in my opinion it's beneficial or how it's contributing first aspect is technical stuff technical stuff in the sense as he is mentioning it's not typing typing is possibly the last step we are doing before that we have to think over it and most of the time it's we just we don't know I mean there might be multiple ways to achieve what we want to do so what happens we have to do a lot of thinking so if two minds are thinking and then we are coding then it's a much better process so that's the one of the aspect the technical aspect of the program the second aspect is people aspect if two people are actually sitting together and they are working together then their personal bonding is getting mature and what happens is if I'm working as a silo sitting somewhere and then I'll be little hesitant to ask him or him hey I got a problem there can you help me but if I'm he's just next to me and we are working together as a pair so my personal bonding will be much better so I will not be hesitant the problems keep appearing I mean it's there will be no end to the problems and if we are pairing it then it's relatively easier to solve them I just have one question I mean we are saying pair programming as you rightly pointed out it's not coding is there anything for the testers over here in this particular stuff when I say testers because in most of the financial organizations, big organizations we are still doing manual testing we are not doing automation testing so is there anything for the testers when we say pair programming or it's only focusing on to the developers I don't think we actually want those strongly separate testers and programmers as separate species it's alright you know you just sit down and it's just code it won't bite you so you just start understanding it and one day maybe they can and it need not be very far away I know a friend of mine who is actually a computer operator this is some many years ago but he went ahead and fixed bugs because those days there weren't all these processes to block the right person and the wrong person from doing this part and that part so I think it is something that can be done but coming back to pair programming one of the things points I want to make is we do always complain about complexity in code and pairing I think is one great way to maintain some sort of simplicity because two people have to actually understand it while the code is forming so I think that's important to have simple code I think pairing we are talking about pair programming but from testing point of view a lot of organizations do pair testing you have new joinees coming in you are actually doing some inductions to them so that's just not pair programming you are doing pair testing you are also pairing with other roles like product owners or business analysts that's still part of the job I am not contraing but the main thing is you are again separating as testing or as pair programming I think there is too much of separating development into its constituent parts from what little I have experienced there is pairing and pair programming tends to happen across roles for example if I am a tester and you are a developer we could be pairing there is a story that you are coding and I am testing while you are coding it I am looking at how to break the code how to make your code fail so I am designing tests that can break your code pair programming is between two developers but it can also happen between a developer and a tester so back to your question is there something for testers one thing that small thing that we are experiencing right now we are experimenting right now is pairing as much as possible what's working for us in our company is we try to hold on to a pair for at least couple of iterations and then rotate to pairs so I was just talking I think we shouldn't limit to pair there could be instances where I have seen four developers actually focused on solving one problem for even couple of days this is not the pair it's actually the team is looking at solving one problem and more eyes on that complex problem might give you better solutions I think that's one way to look at it okay I want to bring a very contrarian idea here it's not limited to just pairing but the concept of working in the team so we had someone CTO of a company quite old he came over we showcased the trial process and all something very unique which left me thinking he said this all agile looks like some communist mumbo jumbo you have this guild and you have got these teams and whatever so I have one question here in the interest when we make a team are we somehow trying to curtail what we called as individual genesis some of the best inventions in history have been made by individual genesis are we now mode where we are like bringing in uniformity and reducing the duality in terms of software development on anything we do before I go into that track I have to add something about testing one thing we are talking about having testers and pairing on it one thing that we did not talk about is having as much automation as possible like as developers when we are writing unit tests or even when you are doing integration tests we are trying to save time especially time of people who will be testing doing exploratory testing as much as possible so that's the motivation over there even when we are breaking down stories or writing integration tests the motivation is more automation so that's one point I think that was not being discussed here another thing there are definitely merits to having testers even working alone doing exploratory testing they can be product owners as well those who have business domain expertise there is merit to having individual testers over there I have never seen anyone pair testing in that manner maybe sometimes in meetings and stuff but there is merit to having good business domain knowledge who do exploratory testing yeah so I just wanted to echo the same point but he talked for me I guess so basically I see a lot of worry around testing here so I agree that you know there is no point in differentiating between development and testing going forward so but one point we are missing like there is one important quadrant about type of testing we do in agile and that is called as exploratory testing but right now people are not getting enough time to do exploratory testing because things are not automated and they are spending time in checking what we call checking actually it is not a testing right so if you want to do more testing then first do more automation automate all your regular checks and then think about exploratory testing you will do much better talking about individual geniuses here the point that was already made was knowledge silos so when I talk to someone in my previous team and someone hates me like 3 months later I am the one who is maintaining your code but it is not that the design was bad at that point of time I was happy but the thing he hates me because now he has to work on it and he has no idea how the code was structured so maybe avoiding knowledge silos that is fine but we have to understand that some people like we have extroverts and introverts we have some people who prefer to work alone and they are very good at doing it alone and you have an organization and you have people who do that how do you fit them into this entire structure of agile how do you bring them in you changed the question on me so I am going to ask your earlier question is that okay if I go back to that one so the lone genius is a myth even Isaac Newton said if I can see farther it is because I have been able to stand on the shoulders of yes and what he did before he had his insights his great insights about what became Newtonian physics he was afraid of the plague and so he went home and with him he traveled with a large library which was a luxury at the time and he spent a lot of time reading what was in that library and it was only after he had sort of had conversations with people who had written all of these great works before him was he able to come up with his insights now he wouldn't have to do that nowadays he could just have international communications with people with the web but what we know is that not only Newton but all great scientists work best by collaborating if you were at the keynote this morning and if you looked at that quote from the Nobel laureate from Cambridge and he said we used to all get together and we'd have lunch and we would share ideas that would lead to better science so I think you'll find that myth of the lone genius working away in the laboratory is just that it's a myth and that they've all whether it was Newton reading a lot of books or Einstein trying out his thought experiments or the Nobel laureate at Cambridge spending time over lunch and tea breaks discussing ideas that we all work best with collaboration now yes some of us feel that we need time alone in order to incubate those ideas yes there's probably an element of that but I think we all also all benefit from the chance to collaborate and bounce ideas off others even if those others are not particularly smart or maybe of our caliber just having a conversation with another human being it's a pattern that a friend of mine named James Noble wrote just the idea of talking to your dog can improve your ideas so we as humans seem to need that time for collaboration time for incubation we need both