 2014. How many of you are for the first time? Okay, two, three, four, five. This is my second or third and I'm so excited to stand here because till last year I was sitting there and watching a lot of sessions and gaining a lot of knowledge. This time I got an opportunity to come up with my personal experience report. We'll wait for another one more minute, maybe. Okay, I think we can go. Fine. So my name is Vinod Pushotaman. I am working as technical architect in Enversnet, Inc. I'm traveling all the way from Trivandrum, Kerala. So today I'm going to talk on hurdles, the sprint with impediments on the way to automation. So this is a personal experience or what I have experienced with my couple of teams in automating few things. So this section comes under experience report category. First of all, I would like to thank agile India team to giving an opportunity like this to share the experience report. And second, I would like to remember my agile guru, Mr. Gunasundaram, who took me into agile stream and thoughts and again like Bangar Subramaniam, a man who I admire a lot, who inspired me a lot to speak. Anybody identifies this person? Anyone? Very famous person. Yes? He is Thomas Alba Edison. Like what he has said, he has said like I have not failed, I have just found 10,000 ways that won't work. So I think he is the first agileist because agile says the same thing, failurely, fail often. So this would be the capital to start with automation. For my team also it was the capital to start with automation. So when we talk about automation, it could be different automation units like it could be build automation or deployment automation or database deployment automation or your testing automation. So when I refer automation units here, I meant building blocks of automation units, not a continuous integration or continuous delivery. But eventually when you work on different automation units, slowly you will keep on building one by one and you will reach continuous integration or continuous delivery in long time. So a background about my team or the experience from where I am sharing this, this is from a team of 20 to 25 member size of SI systems. It's tenet based offshore development team. We work with Java, Cold Fusion, ASP.net and SQL server. We write couple of restful services to support certain client mobile applications as well. We have three different products which we support like one is SI systems public website, client site and match guide. These are the environments we had like we have development environments, collection of machines and then we had QA, UAT, then production and the production replica. So you know how much effort we took to push codes to different environments. So these were the common challenges we were facing. One was like we never had a good release team. Like the developer plays the role of a release team and every time we end up with a lot of problems like always we miss us release timelines and we used to push the code at the edge. Always when the things are in developer hands we used to make lot of quick fixes and last minute code changes which resulted in poor quality releases and there were frequent post production issues and which we have to sit late or we have to even spend our weekends to resolve all those issues and patch up and do things. Most of the time database configuration and normal environment configuration was real mess or problematic. So a need for change was visible. Like everyone understand like okay that we need to change we have to implement something to get rid of the all these things but nobody was listening to it or the team members were not that keen to like listening to this issue. Like each of the developers were aware of all these issues but nobody was ready to go the extra mile to do something special to get rid of all these issues. Then we realized like we were dealing with the hardest thing in this universe. What is the hardest thing in this universe and that is change. We know like to bring changes into the team or to bring changes into our environment or culture is the most difficult part in this world. So I was also not dealing anything bad. So even we know like we have like sometimes we have personal characteristics which we would like to change but we find hard time to change it. So what Newton said was correct like everybody continue to persist in its state until it is cumbersome to change its state by a force impressed. So we know that this is the case in our environment also like people will set up something and they don't want to change. They follow that continuously whether it is a system or a production environment or they have certain plans to do code pushes. They follow that. Even we are like that. For instance I had a very bad character like I was shot a bird in my teenagers or early 20s. So I want to change that very badly but unfortunately like I was not able to change. I tried my level best but I was not able to change. Suddenly I fell in love. I became very soft. I became very cool. So I thought okay fine some change happened because of something. Then I got married. I became shot and bird again. So what does that mean? That mean there is an external force that impressed you which made a change in you. Now the force is bad or good that you will know only after the marriage that I don't know how to express this. This program is not live right. So I can express. So like that in the case of corporate also the thing is not different. The only difference is it is not every body. It is everybody. Everybody in a firm continue in a particular state and they don't want to change. What is the reason behind that? When it is a development environment or it's a production or anything, they set up a cut cast and they don't want to disturb that. Whenever we suggest some changes they will they are afraid. They are telling okay if we touch that again something is going to break. We don't want to change the process. Let it be like that. We will take the code manually. We will build it manually. We will push it using this way. We will push it using that way. We'll continue what it is already in there. You don't believe I have experience with one team which which build and deploy code manually from repository and they don't even have a branching strategy. They take the code. The manually integrate that into folders, structures. They build there and they manually upload that in the FTPs and all do all kind of mess. And this was this process was implemented in early 2003. Now it is 11 years ahead. Still they follow that but they are telling like we are comfortable with it. We don't want that is the word. Everyone is comfortable what is going with. They don't want to move out of that comfortable zone. So keeping that in mind, we tried a different approach. Like we thought to bring changes in three different mode. Like one is first move and then the pace and then the climax which end up to in a success. So what I have tried is I have read a book called switch how to change things when changes really hard. It was written by I think Heath brothers. So that book mentioned lot of cool stuffs which you can apply on your team to make change happen or make things change. So we will go one by one. Like first approach you know like whenever there is a first approach whether it is in a game or whether it is in a strategy or it is in a change it is going to be really, really hard. So we want to make things very, very special or we want to pull people in. So what was the first problem was like we know we need a change but people was not listening to the change. So we want to make the pain evident. What was the problem? Among the team members only one developer was assigned as the release engineer role and none of us was bothered about it. So we thought to make the pain very evident. What we did is we tried to rotate the release engineer role among each developer. We trusted the developer. We never thought okay he is the super developer or star developer in the team. He should always do that or he is talented or he only knows about the environment. We never stick to those kind of attachments. We thought to exchange the role and we pick each person every week. So why every week is like we want to cover the span the people in a very short span of time and we rotated the release engineer among all of them and eventually in weeks we were able to make the pain evident in every team members and everyone come together and said like okay there is a problem in release releasing. We have to make some change. So next thing was like how to start with like how to win the hurts of the management or how to win the confidence of the team. So whether it is money or whether it is time we invest when we saw good return. So here also the thing was not different. So if you want to invest we have to showcase something very very interesting. So we try to sell the best one. We identified what are the areas of manual stuff going on here and we identified the best one to sell first. In our environment in our team the most tedious job was to do the production release. So we thought to do automation in that area and what we did is we picked that item and we automated it and we showcased it and everyone was really like welcoming it and appreciating it and everyone realized okay we can do that. If we can do that in production environment we can do that in other environment as well. It doesn't mean that it is complete end to end automation in production environment. It was just downloading a package from FTP location and deploying it in somewhere. But same thing we can replicate it in other environments plus additional stuff. So second one was limit the automation work in progress. So the moment we started to think about automating immediately a big product backlog piled up right. Okay you have to do that. You have to automate this. We know when we show something to somebody everyone will get over enthusiast and people started doing things parallely. So then what we thought was okay we should not do like that. We should keep the the work in progress very limited. We don't want to rush through all the automation. So we did one by one. So we did a slow and steady pace like we pick one by one and we keep on building each manual jobs into automated mode. Second mode so once we have done this we were all set into like the momentum. Okay everyone understand we have to automate. We started with one particular item. We know what are the areas we need to automate. So next we want to attain the pace. So you know it is very difficult. I have heard a saying like every fool can start a business but very very few will sustain and get succeed in that business. Same thing here as well. Like it is easy to talk about automation. It is easy to talk about test driven development or whatever it is. But to sustain it in and to get succeed that is the difficult part. So what we did is we want to get a collective ownership as a team. Like we are agile team. We are self-organized team. So we want to make a collective ownership rather than assigning it to somebody and getting things done by individual peoples. What we thought is we come up as a team together. We start together and we identified what are the items to be automated. We referred all the past retrospectives to see what are the missings. We know like whenever there is a problem people will blame each other or people put that on the table and discuss this problem was because of the deployment was not proper or the build was not proper or the package was missing something or some database script was missing something. Like that we identified all the nodes from the past releases and then we identified a product automation backlog which include all the items that need to be automated or that need to be like changed. So we try to identify all the manual and boring jobs which need to be automated. Then what we did is rather than assigning again rather than assigning it to somebody we showcase that in a retrospective we showcase this product backlog to the team and we effectively utilize retrospective to communicate with people and with the team and they voluntarily came up because we have a self-organized team they know what is the pain of doing release. So they came up and they started picking up item one by one and we progressed it. And next point we did is like we never thought about putting a fixer plan. We never thought about okay we will start in this month and in six months we will complete all the automation and we will make continuous integration or we will achieve continuous delivery. Because whenever we had some plan always he had other plans. He will always come up with different struggles and challenges to us. So what we thought as rather than going like that we did a different approach. We became an ancient doctor rather than a modern doctor. You know what is the difference between that right? Modern doctor like he depends upon the diagnosis report but an ancient doctor he depends upon like trial and error. Like how to do things like try one if it is not working then move on to the other one. Like that he keep on doing trial and error and he succeeds in it. So we focus on what works not what's the best. Always when we think about automation there are hundreds of tools available in the market rather than getting a heavy duty heavyweight item and fit into your requirement you have to go for what works for you. So next difficult situation we were facing was like our efforts. These are your efforts for like automating things. You have to spend a lot of time and you your business feels like this. This is what you have done. The reason being the business don't feel the change. Suppose if you took like one month to complete automate a production build and you did that. What's the difference in the management or the business is going to see at the end. They don't see any difference. If you do it manually or if you do it through an automation tool at the end at the particular deadline time they are going to get that items in the production environment right. So they don't see any direct difference but definitely they will get benefited with indirect benefits like you are your release readiness or how fast you are doing things. So definitely that benefit will be there but there won't be any direct involvement or direct like benefit that the business feels. I would say like you should do it for the team not for the business because it's like how productive or how effectively you can deliver some products to the business and the different another point is like you are you are delivering something you have to maintain the quality as well. So from these two aspect it is better that you do it for the team rather than doing it for the business. But how we will get the time. We will never get the time because business have already their own priorities and they want to complete it. They never give you time to work on your items or your refactoring items but how you will do that. One item is like we need to maintain all these things to get succeeded in the automation so the climax. So we have to motivate the team members. How you will motivate. Like one thing we did was like we did a campaign like one of the problem we were facing was on a release date the team was always getting late. We push at the edge like at 5.30 or 6 o'clock then then after that we lot of post production issues will be coming in. We sit late up to 10.30 or 1. So what we did is we did a like campaign like go home early on release day. So that was a hit. Like after completing the automation in six months or so people started going at 3.30 or 4 because we completed our production push at around 3 and there was no production issues or sometimes one or two that we will do it very quickly and we can leave on that day. So the promise that we gave to the team that happened and we started going home early on the release date. And second thing is like we have to cast right tools for the right problem. Again focus on what works not what's the best. Look for the tool which is shooting for you. Like we were working on automating Java.net and lot of stuff. We could have gone with a tool and we could have integrated that rather than we went with and an script and we write our own scripts to communicate with the source control server and get the source code and build it and natively we write the workflows that we have which suited us. And the other one was like we have to set clear directions to the team members. Like most of the time whenever we come up with a process or whenever we come up with a change somebody will be there to break these things. Somebody will check in with builders that will break all others others code. So we have to make sure that we are communicating very effectively with our team members. There should be enough gate lines. There should be enough training sessions going on. There should be dos and don't dos. So you have to communicate that with your team very effectively. Your communication should not be like this. This is a like banner I have seen in an ATM. Like it is telling like that particular ATM is for visually challenged and they're giving the instruction to the visually challenged person. Just plug in your headphone and hear what it is. How a visually challenged person can see this. It is not possible. So you should not communicate like this to your team members rather that you should be very clear and very specific. So you keep on building one by one like branching strategy or how you do the release emails. You automate that as well. Test automation, build automation, compiling the configuration changes or how will you do the deployment. You keep on building one by one. At one stage you will reach here. You don't need to plan for continuous integration or you don't need to plan for continuous delivery. You keep on building all as much as manual boring, manual efforts and eventually you will reach here. So these are the technical details which I can rush through in two minutes. Like one issue we were facing was like there were no like proper branching strategy which were like affecting us. So we introduced a new branching strategy and we kept it very simple. We can refer more on like internet to see what are the different branching strategies available and you can adopt, adapt which suits you well. And we gained more control over the changes and there were no more build or release issues. And another technical detail is like database deployment. We know like this is a mess for most of the team members how to do the database deployment. So actually we were trying to do it with Redgate comparing production and other dev database and getting the scripts and then executing that in different environments. So it was leading to a lot of problems. What we did is we come up with a template driven structure where we trusted the developer. We trust, we empowered the developer to write the scripts whether it is author statement, data definition languages or like data manipulation languages, whatever it be. We trusted and empowered the developer and they came up with their scripts associated with the feature or change request and they checked in along with their changes. So which we picked up from using our tool and we replicated it. So the benefit was like in each environment this change set was wetted and at the end it was perfect. Like there were no builder, there were no builders or no suit procedure or database script changes was missing in the production. Another one is like compiling configuration changes from various change request. What we did is we took the configuration changes into source control and we again empowered developer to make changes necessary to the each environment and we picked environment specific configuration from source control and we put it in the build package which was then pushed to the environment respectively. The other one preparing the build package we used and script and enant to do that and like careless check ins and integration issues were there. So we set up so cruisecontrol.net as a continuous integration server which do a build on every night. So these are the values we gained like with every single change, quick round trips like you by implementing testing automation whenever there is an issue we are getting it very very upfront, very early. Then avoid redundant manual efforts, automated rollout build more frequently, more quality deliverables for you and finally you will be more release ready. Your release readiness will increase. You will be ready to do releases at any point of time and I believe this is not an idea of a single person or a single like thought leader. It was a teamwork. Together the team achieved more. There are several things to go for, several things or points to go for automation but you could die for one precious thing in this world and that is time. You choose if you believe. So I believe like last last year I attended the session and when Gatsubramani was talking about automation he was telling like ten years back we were talking more about object oriented programming. Everywhere it was object oriented programming and now nobody talks about object oriented programming. Everybody talks about just programming. So just like that now it is time for automation and he says like it's a time to automate things and you have to more talk about automation. So I believe that was true and we succeeded in it. So anyone can start practicing as I those who sustained the enthusiasm succeeds others fail that's my point of view you can reach me at VinodPTHMN at gmail.com and you can get me at Twitter at VinodPTHMN. Thank you. Any question? Do I have some time for questions or? Okay, okay fine. So we are running out of time I will be available outside. We can have chat and I will be available tomorrow as well. Thank you.