 I'm Vaidhi. This is Lena. We are longtime colleagues and have built a good amount of software together. I've got a confession to make. We are process geeks. And the impact of that has been felt by our own team quite a few times. Let me give you an example. We have these daily morning company-wide stand-up meetings. And Lena and I would very excitedly talk about things like continuous delivery and continuous improvement in these meetings. And things were going great until a colleague of ours told us or asked us whether we had noticed that the number of folks in the stand-up was kind of steadily coming down. It turned out that folks were coming in to work just after the stand-up would get done. And we wondered why. We were talking about all these super interesting topics every day. Then we met a friend of ours recently who told us that process talk sounded to him like a trip to the dentist. And I guess that also answers the mystery of the reducing stand-up count. What we'll do today instead is to talk about some war stories and throw in some thoughts on continuous delivery and culture along the way. Any brain signs, neuroscience geeks over here? Anybody who's interested in that kind of stuff? Well, thank you. So time permitting, we'll talk about some of that as well at the end of the presentation. Are you able to hear me okay? Okay. So continuous delivery, I think most of you know that it's a large topic. It's a huge topic. There are many ways to skin this cat. Today in this talk we are going to talk about majorly three aspects of continuous delivery. That is build quality in, then make your build always ready to deploy and continuous improvement. And while we'll also talk about the practices that are required for these aspects and then connect those into the motivation of the team, how those practices affect the motivation of the team, impact the motivation of the team. We're going to talk about motivation 3-2, which is three pieces together, autonomy, mastery and purpose, which are key for a knowledge worker to sustain the motivation for a longer period of time. And that motivation intact, how does it create a culture within the organization? So before we move forward, we have one more confession to make. We don't have any PhDs in this subject, but we do have a thesis that we would like to present in front of you. That is practice continuous delivery and you will end up with having a great culture. So let's start with the stories. Let's start with the first story. So this is way back 2010. We run a software consultancy out of Bangalore and we had a customer approach us to build a product in the consumer space, specifically utility product. And we suggested that we kickstart the whole thing with a two-day brainstorming session. We had our scrum kit ready, lots of story cards, multicolored stickies, lots of those wonderful sharpies. And at the end of the two-day session, we had more than 100 cards neatly laid out on the table and also on an online spreadsheet. The next logical step would have, of course, been to start the estimation process. True to scrum principles, we decided to go with story points. And the idea was that we would go ahead and estimate each and every one of those 100 cards, 100 plus cards, over a span of the next few days. Fast forward another couple of days and we had our estimates ready. It was going to be a good, nice, long, six-month project at the end of which there would be a beautiful product that we would have built and that would scale quickly to a million plus users. Fantastic, right? I guess some of you can already see where this is going. We also ended up injecting a few more milestones into the process, three milestones to be exact. And at the end of each of these milestones, we would have a party and then get back quickly to working on the very next milestone. We would also work in two-week iterations, since this was a scrum-based system, and award the team with story points as soon as they'd finished coding a story. We just couldn't wait until they'd also tested it. And then we would finally also have these demos with the customer every month or so. So things were going great until after about four months or so, the customer asked us to schedule a demo with an investor of his. And there was about seven days or so to go for the demo. We asked for just a couple of days to get everything ready. And a day before demo day, we had the entire team camping at the office of feverishly fixing bugs. Let's just say that Weekend isn't the best one that we've had in the last four years. So most of you might be familiar with this kind of setup. We have already spoken about scrum, but there are two more parts to it that is called the water and the fall. So let me explain the water scrum fall model. That is the HIPPO, the highest speed person in the room has a great idea. And he comes to the engineering team to build it. The engineering team has just finished their two-day scrum course. The only difference being that they take all the instructions standing instead of sitting. And then we have a fall part that is an ops team who sits in the corner, in the secluded corner of the office with a tiger on their computer ready to pounce on anyone who comes to meet them. Okay, so this is all funny. But to be very frank, we had our most stressful days back in 2010 when things went wrong. And we really wanted to fix it. We just wanted to fix it, not just because we want to regain the credibility, but also wanted to retain the motivation of the team. So, but the question is, where should we start? So the similar chance to do in those case situation is that start with in those cases where where you have control more over. So the biggest problem that we had was the quality of the product that we were shipping. So and that is that that is what is in our control. And we wanted to fix that first. So let's move on to the next story, where we fixed that. Fast forward another six months, 2011. Another customer that we worked with another product, things that remain the same, where the water on the fall bit, the things that we made some changes to the stuff was a stuff in the middle. At the end of the six month period, we noticed some significant improvements, especially with respect to the confidence of the team. The number of weekends and late evenings that the team worked on. The quality of the product itself, which was much more stable this time around, we did not need to track defects in a separate bug list anymore. So that was kind of good feedback for us. We had a customer who was much easier to work with as well this time around, perhaps because of the fact that we were making updates to the staging server much more often than we used to in the earlier episode. And this allowed the customer to kind of give us feedback at least once a week or so. So things were going pretty good in comparison to what was happening earlier. So let's come back to the stuff in the middle that we made changes to, because that was the reason why all this had happened in the first place. What we did was we brought in some practices to build quality in. Now you may have seen those GAN charts where you have analysis, design, testing, development testing, and so on and so forth. What's funny is that after the testing phase, you don't really have a fixing bug space. Building quality in very simply is to think about quality as you're writing your code. So you don't really think of testing as an afterthought. It's part of the process. Great concept, but how do you bring this in on a day-to-day basis? So extreme programming brings in a lot of good practices to help us with this. Test-driven development being one of those. I know there's a lot of activity that's happening on Twitter these days with respect to the comments which DHH made the other day, but I think he was talking more about test-driven design than the stuff that we are going to talk about. Test-driven development does give you a suite of regression tests which gives the team an enormous amount of confidence to go ahead and make even big changes to a constantly growing code base. And this is invaluable. There is really no two ways about that. The confidence in turn ends in creating much higher quality software as well. Add to this practices such as exploratory testing or continuous refactoring, pair programming and so on. And you have a suite of practices that are cohesive that kind of make it possible to kind of ship good quality software. So we've spoken about the values of build quality and the result in terms of actually creating better value for our customers. But there's something more to this. So what we've seen is that apart from the quality of the product, we have also started seeing the behavior changes within the team. I'll try to explain with an example. When we started with the development, the team used to check with the customer for each and every small changes that happens for the priority or for the plan. Later on, when we started shipping working software, the customer started asking us for the opinion, started asking the team for the opinions. And then later on, team started deciding their day-to-day work rather than checking with the customer. And then they will go to the customer or discuss with him when they think it is appropriate. So what we are seeing is that they became more, they started sensing more autonomy and then they started feeling the freedom of that any team would love to have when they are working with the customer. So XP actually allowed them to become more autonomy. That is what we have started seeing. And because of these kind of values that XP brings in, we started continuing with the XP practices for every product that we brought up after that. So now you might be wondering why we are talking about extreme programming in a continuous delivery talk. So we spoke about the WaterScom form model. And if any team who are there in the WaterScom form model, if they want to reach continuous delivery, then the first step that they should be taking is start practicing XP practices. And that is the first step towards continuous delivery. In our opinion, continuous delivery is a superset of extreme programming practices. So now coming back to the story, we spoke about the quality and the team motivation. So things were great. We had a great product and then which is high quality. And the day came when it has to go to the market. We had a big launch party when it opened to the public. But what happened was even after a month, there were only a few users in the system. And we kept on waiting. And even after a few more months, there was no change in the result. And then the customer had some funding issues. And also, he was not getting enough traction to the product. So he decided to move into hibernation. And even after three years, we are still waiting for him to come back. So even after we delivered a high quality product, the reality of that, the product didn't become its success that had a bad impact on the team. And that is the next thing that we would like to fix. So you're a consulting company, right? So we didn't own this product. But in spite of that, you know, the disappointment in the team was quite evident. Let's move on to the next story and talk a little bit more about this. Actually, autonomy is great for bringing in short-term happiness into the team. That's something that we've seen. But to create long-term motivation, you need something, you need to add something else to the picture. Can anybody think of what that might be? So what we need is, we need to provide a method or an environment that actually allows the team to connect with the bigger picture so that they can actually feel that they're part of something quite important, something that matters. And I'll explain this as part of our next story. So this is a customer that we worked with quite recently. And the original vision was to basically have a network of tablet devices installed across multiple cities. And these would be remotely controlled from a central location using web services. Even though the original plan was to kind of, you know, go ahead and build this entire thing, the customer chose to go ahead and build the smallest piece possible that would allow them to test the tablet with real users first. And as you might expect, we found quite a few issues very early on. Let's give you an example. So the USB power cable that actually came with the device wasn't actually long enough for the length, for the distance between the tablet, where the tablet was installed and the power source. So a new set of longer cables was ordered and when those were installed, things seemed to work out well. Problem solved, right? Well, not exactly. After about a day of usage, it was quite apparent that the battery level of the device had actually come down by about 50%. Now, it turned out that the length of the cable, the length of the cable was a reason for the voltage drop across the voltage drop which in turn resulted in the lower battery levels. Simple problem to solve, we asked our end users to go ahead and switch off the tablets and the nights and then added a high priority item to our backlog which would automatically switch off these devices in the night from our remote control system. We also discovered a few usability issues which we fixed by picking the user interface. Now, none of these problems would have been discovered if not for the desire that our customer had to go ahead and test a very early alpha version with users. And this in turn allowed us to kind of iterate the product quite rapidly very early on. In turn, allowing for a rapid feedback loop with everybody across the company, including the engineering team back in India. So this was invaluable. This really helped to kind of realize the early goals that our customer had which was to go ahead and implement or install the tablet across multiple cities. They also got advertisers on board and that very early on that allowed them to kind of test their pricing model as well. All of this is great from the perspective of the customer because you know if it was not for the fact that they had good relationships with their end users, even getting feedback from the end users would have been difficult. But there was something the engineering team did as well that was quite useful. So one of the key things that happened over here is that the customer was able to iterate through multiple versions of the application of the product. And that is something that the customer did great. But how did the engineering practices, there should be backing up engineering practices that will allow the customer to do that. So let's look at some of the practices that we did for achieving that. So one of the key thing in continuous delivery is make your build always ready for deployment. Anytime when someone wants to deploy it, it should be possible by just clicking off a button. So for achieving that we have to make changes in the entire software delivery process starting from the estimating and planning. So we actually reversed our estimating instead of asking how long the story will take. Instead of that we started asking what is the simplest thing that we can do in a couple of days or less so that we can get a quick feedback on. And the next thing that we started was having a real continuous integration system where the entire team checks into the mainline branch and then they work on small chunks so that they can get feedback on whenever they make changes and make sure that it is aligned with the existing system. Nothing is breaking in the existing system. And the third aspect of it is the build pipeline which is a key part of continuous delivery. Let's talk a little more about build pipeline. Build pipeline allows us to achieve three things. One is to make sure that the deployment process is a very risk-free and completely automated activity rather than a mundane manual error-prone activity. Next thing is that it allows you to identify the bad builds early on so that you can ignore those by not allowing them to move forward on the pipeline. And then the third thing is that it is sanity of the build is maintained. The same build, you can make sure that the same build is moved from this testing environment to the staging environment and from the staging environment to the production. So these are the major practices that I would like to emphasize on in this talk. There are many things that we have to do especially from the automation perspective to achieve continuous delivery. I'm not going to into the details of those practices. I'll be available over here who wants to know more about it. Come and talk to me. We can explain it. So the thing with all these practices what we achieved was the deployment is more of a business decision rather than an engineering decision. The customer can go and deploy whatever version of the product that they want by just clicking of a button and it's as simple as that. So this story compared to the last two stories had a happy end. The customer was happy and the engineering. So let's look at what is the feelings of the engineering team. They were also very happy, extremely happy. Not just because they were able to deploy it multiple times but mainly because of another reason that is that they were able to connect their day-to-day work to the big picture. They were able to see the purpose of what they are doing and that actually ended up creating a lot of a lot of motivation within the team and then they became very... they are also able to connect to the end users. Not only that they are able to connect to the entire ecosystem that is the advertisers, the network personal and all the entities within the entire ecosystem and that made them feeling very proud of what they are doing and then that keeps them motivated for doing a better work on a daily basis. So you spoken about two aspects. Two aspects of continuous delivery already. Building quality in and keeping the build always deployable and we've spoken about the corresponding motivational aspects with respect to these two as well. The third thing that we want to talk about is continuous improvement and this is actually an integral part of continuous delivery. Not only is it required to have continuous improvement to get to continuous delivery but you need to maintain... you need continuous improvement to kind of maintain continuous delivery as well. It's key. To talk about continuous improvement I'm going to bring in a story from Toyota because that's... because those guys are the lessons in the space. So Tai Chi Ono is known as the father of the Toyota production system and he was part of Toyota in the 1930s. It was called Toyota back then, spinning mills, not car manufacturing yet. One morning one of his assistants actually came running up to him and told him that the plans for their newly constructed factory had been stolen and there was a obvious look of nervousness on the assistant's face. Tai Chi remained unfazed though. He said we don't have to do anything about that, you know, let's just get back to work and went on to explain that it doesn't matter that they've actually stolen our plans because of the fact that by the time they actually build a factory based on those plans we would have refined and improved our current systems so much so that the gap between what they would have built by then and where we would have been by then would have been significant enough that you know we don't really need to worry about the competition anymore. That's the power of continuous improvement, right? From the waterfall days, what has come for all days all the way up to the continuous delivery days, you know, we've been taking these baby steps one day at a time to actually get to this. We in fact did not even know that you know we would actually, that continuous delivery was what we were kind of targeting. We were not even aware of the fact like four or five years ago. But the point I'm trying to make is that folks actually come into work these days to when they build delightful products they're doing that because you know they see their work as a way to express themselves. And when you see your work as a way to express yourself you see it as a craft and if it's a craft if it's craft and not a job then the natural tendency is to kind of keep honing it, right? You keep improving it and it's a journey towards mastery which is the third bit of the autonomy mastery purpose circles. And as Ken Beck says, perfect is not a noun it's a verb. So the question if at all the question arises as to when does the process of actually honing stop it never stops, right? It's a continuous journey. So you want to summarize? Yeah, so let's summarize the motivational aspect. So we spoke about autonomy, mastery and purpose and these are the three pieces of the motivation and what you see on the middle, the intersection of all these three is called the engagement. That is a motivated team will have a highly engaged team. They are more outcome focused and they keep on honing their craft and then they love their craft and then they know why they are doing and they will always try to connect on a on a day to the basis why they are doing something and how much of impact that they are doing will have on the actual on the end users. So the main difference between this team and the water scum fall is that this this team is more outcome based outcome focused rather that that is they focus more on the impact of the software that they are building on the end users or on the customer's business rather than the output that is the stories or the velocity or whatever it is and and then yeah so this is our team picture back in Bangalore and we we think the smiles on their faces shows of the in the level of engagement that they have on their work and so let's move on to the culture of it we have been talking about continuous delivery and and practices and the motivation within the team but where does culture come into all these things. So culture as you all know is a shared values and principle among the team and then so let's take up two values that we believe in that is a delighted customer and software craftsmanship there's a values that we believe in truly believe in but how do you identify which practices will help you to achieve or gain these values. So to the answer to that is that take take those practices which passes this motivation 3.0 test that is those practices which will allow the team to be autonomous which will give them room for improving their skills honing their craft and which will help them to connect their day-to-day work to the to the big picture then those practices you should continue on and that will align to your values and and we have seen continuous delivery helps you to do that. Continuous delivery helps you to become a continually improve your practices and then it is purpose-oriented because you know why you're doing certain things it gives you feedback and then it makes the team more autonomous. So practice continuous delivery and you will have a great culture. Looks like we have time for some neuroscience so if all of the stuff that we've spoken about with respect to motivation isn't convincing enough for you to kind of take the plunge into continuous delivery then perhaps some brain science is going to do the trick for you. We're going to talk about two parts of the brain. The first bit is about the the prefrontal cortex the stuff in the front part of your brain and there's something called the limbic system which is something that's on the inner side. Let's talk about the prefrontal cortex so when you're driving to work every day you'll probably be you'll probably be able to change your radio station without much trouble but try doing that when you're in a foreign country on the opposite side of the road and you know what I'm talking about it's you need to kind of consciously think about it. Same thing with respect to setting up setting goals, writing code, analysis, stuff that you do on a day-to-day basis you know at work. For all of these things you need the prefrontal cortex. Let's move on to the limbic system limbic system is actually responsible for your emotions positive and negative emotions and it's also responsible for accurately telling you whether there's a threat or a reward in your environment. Another important or interesting thing about the limbic system is that you actually have that it actually has a higher level of affinity towards negative emotions so you may have heard the saying that you walk towards rewards but you actually run away from threats right and that's actually because of the way the brain functions. So you have if the brain is kind of wired to kind of keep pulling you down with negativity every day then how are you going to go ahead and maintain positivity in the workforce and this is where the the seesaw effect actually comes into usefulness. It turns out that your limbic system cannot function if your prefrontal cortex is functioning and vice versa. It's just one of those quirks of the brain wherein either your logical reasoning part of your brain is working or your emotional part of your brain is working not both of them. So it kind of pays to create an environment where your workforce is always kind of engaged in creative activity because that kind of pulls them away from emotional depressing circumstances. There's one more thing about the brain about the prefrontal cortex rather and it's actually called the Goldilocks the brain because it needs a certain level of stress to actually function well. So stress is not necessarily a bad thing by itself. It gets bad when it's actually too much. So if you're not able to think creatively when you've just gotten out of bed or when you've just come back from work when you're tired that's because of the fact that it's not the right conditions for your prefrontal cortex to function well and it pays to create at the workplace it kind of pays to create an environment where your folks are doing work that actually keeps them in the middle part of the inverted U. And that's the best way to kind of get those creative juices flowing. Leena will talk about how a continuous delivery is actually linked to all these things. So continuous like we mentioned like we were talking about continuous delivery is always about making sure that you have a bill ready at any point of time. So you need frequent pushes and that gives a sense of urgency to the team and that makes sure that they are always on the on the right stress level the inverted U and because of that and then there is no fear for the team as they are doing in small steps there is no fear for the team okay will something break that question never arises. So that that keeps the limbic system away and make sure that the PFC is always active and because of that you create a highly you you tend to create a high creative environment rather than a stressful environment. So if you are not convinced with the motivation continuous delivery helps you is tuned to work well with how the brain works. So this is one more way to go to to start using doing continuous delivery. And so we have spoken about many things now coming back to the thesis again we strongly believe that okay practice continuous delivery and end up with the great culture. But the question arises where will you get started? A journey towards something like continuous delivery takes a lot of persistence and willpower and we need evangelists for doing that and the best way to get evangelists or to make people think about this this is that by asking these two these two questions that is why must your business exist and if your business doesn't exist who will miss it? And if you get an answer for that then you will be able to connect the circles the then then the purpose part will will get answered why you why you are why are you doing what you're doing and then that will help you to the team to be more autonomous and they will have to improve on a daily basis if they if they want to reach the goal that they want to be. So I will leave you with a quote from Jesse Robbins Jesse is one of the co-founders of ops code the guys behind chef the popular configuration management tool and he is also a part-time firefighter a true achiever super achiever in his own right don't fight stupid make more awesome thank you very much these are four books that we have been using on our journey I think you might find it useful as well you can find our contacts on the site as well so you're ready for questions if you haven't thank you