 And this is Siddharth. We're both from Amdauks, and we help projects in Amdauks adopt agile and other big transformational changes. Our topic for the day is the snowball effect. It's about an alternate change management approach that we used to complement our efforts to help our projects adopt Kanban. This grounds up approach that we tried kind of snowballed into something a little bigger, and that's why it's called the snowball effect. And because it's called the snowball effect, we kind of felt compelled to put in the picture of a snowball. So what you see over there is a snowball, and maybe we went a little overboard with it, but it made us really happy to put it in there, so we kept it. He looks a little like me, right? He looks a little like Siddharth as well, yes. Okay, so before we start, brief background of Amdauks. So Amdauks is the leader in CES customer experience systems in the telecom domain, telecom billing domain. We have around $3.6 billion of revenue last year in 2014, more than 20,000 people working for us at various locations worldwide. We have more than 70, more than, we have customers in more than 70 countries. The who's who of the telecom world, beat AT&T, Sprint, Singtel, Vodafone, so all the big names in the telecom world. Okay, so about two to three years ago, Amdauks delivery unit specifically was looking for ways to improve our responsiveness to the customers, to deliver what the customer really needed. So we were looking for ways to be a little more agile, and the vehicle of transformation that we chose was Kanban, and why did we choose Kanban? So we chose Kanban, I would say, for primarily for two reasons. One reason was that we are a 30-year-old company, a legacy company. We have a lot of, we have processes tools established over the years, a successful company. So we really didn't want to rock the boat. We didn't want something which will kind of an overnight big change. So we wanted something more gradual, more evolutionary, and Kanban promised us all that. Also, the other reason was that we had different accounts, and we wanted each account to choose the changes that the practices they wanted, so they pulled the changes they wanted at the pace which suited them. So each account went the Kanban way, but at a different pace, the pace which suited them. And we have Yuval in the room who introduced us all to Kanban, so it's nice to have him here as well. Okay, so very, very briefly, we will spend about two minutes looking at what is Kanban, so that the slides which come later make a little more sense. So Kanban is like a meta process that helps you improve your underlying processes, and this is what we were looking for. What you see over here is a Kanban board. It's a very powerful visualization tool. It helps you look at your workflow, all the workstations through which your work items need to flow through. It, what you see over here are the cards. These are the work items. You can see who's working on what, where work is getting bunched up. Do we have any blockers somewhere? How do we manage the project better? How do we improve the flow? So the visualization aspect of Kanban is very, very powerful. And the other thing, maybe we can show the whip limits. So what you see at the top over there is the explicit whip limits per lane. So limiting the work in progress is something that helps us get to done faster. So it kind of encourages us to focus on completing things rather than starting a whole bunch of things. So explicit whip limits is one of the other core ideas behind Kanban. And the other thing is about issue resolution. Can you just click? So let's say if you see that somebody's blocked somewhere, then the entire system sort of aligns to see how that person can be helped, how the issue resolution can be improved, how the blocker can be removed, and how we can improve the flow of the system. So managing the flow is something that the Kanban board will help us do the Kanban. Principles focus a lot on improving the flow in the system. So did we have any buy-in challenges, sort of big change? Right, so... Okay, so yes, we did have a lot of buy-in challenges. You know, as with any big transformational change, we expected buy-in challenges and we had them. Some of the things that we had was one, that the delivery unit in Namdax has a good track record. It has always had a good track record of meeting milestones. So it was something that made us very comfortable where we were. We were comfortable with our processes, our tools. People were invested in those. They had probably built some of those processes, et cetera. So the comfort zone, the healthy track record, these are things which encouraged us to sort of stay in status quo and not look for a big change. So that was something we were sort of grappling with when we were trying to make the change happen. Right, right, and of course there were a lot of risk for also as I was mentioning before that we are a legacy 30-year-old company. So a lot of established tools, processes, veterans. Getting into Kanban and managing the project in a completely different way was getting into untested water. So there was definitely a big risk. We were used to working in very specialized, super specialized teams. Teams working in their silos, working on the things they specialize in and then integrating later. With Kanban, we were trying to do things differently. We were trying to have teams which collaborated, people from different teams working together. So these were things which we're not used to. The other thing was we were used to having plans with dates, doing heavy planning up front and managing the project as per these plans. Now again Kanban meant doing away with these things. So definitely the management layer, the managers and everyone was feeling a loss of control. So these were big risks for us in our Kanban journey. So one, some things kept wanted us to stay where we were and some of the things made the change look too risky for us to move there. Right, so when we started our Kanban journey, we of course did all the things which are big implementation like this needed. We did our front trainings, mass trainings, buying sessions, management workshops. So everything which took to get this implementation in place but at the same time we also thought that maybe doing things a little differently will also help us. So we thought of and we had read about all these things which other companies had done, our consultants also encouraged us to use the Kanban in different things we are doing. For example, we saw Yuval who would come into a meeting and use wherever he could. He would just draw a Kanban board and manage the meeting or training session with the Kanban board. So we started doing personal Kanban and team Kanban. Basically personal Kanban is managing your personal stuff using a board. It helps you visualize your stuff, focus on fewer things at a given time, manage things to completion much better. And a team Kanban similar things but at a team level. So even if a project is not doing Kanban, we encourage the smaller teams within to start using Kanban boards to manage their stuff. So irrespective of whether the project is on Kanban, maybe for team activities Kanban could be used. Right. And let's look at how these methods sort of complimented the larger change management effort that was going on. One was that the fact that they were doing it at a personal level or a small team level meant that the impact of something going wrong was fairly small. It was controlled. So the cost of failure was low, which encouraged people to try an experiment. They were more open to these new ideas, et cetera. And they felt that these were safe experiments for them to take up. So they felt a little more confident about trying these things out. And we found them to be a lot more open to the change than when we would go to them via the project. So they felt that it was a safe experiment to undertake and it also allowed them to learn at their own pace. We had teams which just started with the task board. They did not even have WIP limits, et cetera. And they gradually graduated to something like having WIP limits and then managing the flow. And then some good practices like team meetings around a Kanban board emerged. So people were learning at their own pace and that made them a lot more confident about pulling this kind of a change. And this way they started to experience some of the benefits of Kanban, like low WIP limits, better visualization, better flow management, et cetera. Right, right. And another thing, of course, we were trying to do is influence the individuals. That is, by working with the individuals, we were trying to create champions. So these are the people who started using Kanban board and started talking about Kanban board, they started demonstrating to others, maybe within the team, maybe friends, that how Kanban is actually helping them manage their stuff much better, the power of Kanban. So we had these champions who were talking about Kanban and that made others around them actually feel more comfortable and start using Kanban themselves and also for their project work. So it kind of started leading to easy adoption of Kanban. And it snowballed into something bigger because it snowballed in the title, I have to use the word sometimes. And see how big a snowball has grown, so. Yes, so we saw people using Kanban for different things. For example, here we have one of the managers, Guru, who was using Kanban board to manage a testing phase. So the project was not actually on Kanban, but for his, the testing phase, he created a board at his, you know, at his cubicle and started managing the work on Kanban board. And very soon, the whole team started using it. We here, we have one of our friends Prashant who was doing, he was doing his PMP certification. And for all the certification work, whatever was needed to be done, he created a Kanban board and started focusing on, again, completing activities. Right. And what you see over here, the colorful one with the colorful posters is my personal Kanban board, which I share with my six-year-old son. And we use it for planning, you know, weekends and special occasions like his birthday, et cetera. So it's really simple to do, kids can learn it as well. So do try it at home, it's not done by experts. And what you see over here, the electronic Kanban board is something that we coaches use. We thought we should kind of practice what we are preaching. So we decided to have a board for our work as well. And I think it did help us become more effective coaches. Fewer things started falling between the cracks. We were getting things done rather than, you know, just starting a whole bunch of things. So I think it definitely helped improve our effectiveness as coaches as well. Right. Right. So, of course Kanban, within the two years of starting, we starting to implement Kanban, it, as you can see, it has become quite a big implementation. And we are not saying that is only because of personal and team, you know, of course there's a lot of other activities which happened around to, but still we do have reached, we have reached a point where there were a lot of the projects which were on Kanban. We had many, many boards, a lot of users, and almost all our projects started using Kanban. I think that's more, that more or less brings us to the end of the talk. I think our takeaway for you guys for this talk was primarily to say that, you know, try some of these grounds up approaches. They can compliment your larger efforts and they can definitely help, you know, act as catalysts for the big change that you're trying to make happen in your organization. So I hope some of you will be able to take this back to your organizations and try it as well. I feel like something is missing. Missing something? Okay. So thanks a lot. We'll be happy to take questions now, also suggestions, tips, if any. Yeah. So I think, so when we started our agile or Kanban journey, of course, it's been a, it's a profitable company. We have a very good track record of meeting our deadlines, but at the same time, we know that we have problems in projects. We know that our testing phases, for example, our UAT and everything is very chaotic, long hours and things like that. So yes, we wanted to solve this part of the problem and then we wanted to be future ready. For sure, we know that things are changing. Already in our service, which we do with customers, people are expecting us to be agile. Though we are the leaders and we have all the big companies in our customer list, we know that things will change very fast and we need to be ready for that. So we wanted to be agile, to be future ready and of course, we thought that Kanban is a good way of starting. Okay. Just follow the code, things like setting up with limit or have you changed the processes themselves to do QWIT? Right, so can I take that? Okay, so some of the things that I think largely, you can say we borrowed some practices also from Scrum, which I think made the way our teams work much better. So in Scrum anyway, they focus a lot on the teams whereas Kanban is largely, it doesn't talk so much about it, but we did introduce the daily Scrum kind of formats. We introduced the retrospectives, of course, measuring cycle time. These are things that we do along with Kanban anyway, but these are things that we started doing and also we looked for closer collaboration between the testing teams and the development teams. That is where Siddharth mentioned the cross-functional teams. We tried to create these cross-functional teams, improve the collaboration, improve the issue resolution kind of reaction time. So these were some of the things we did. A lot of it Kanban anyway recommends, but then some things we borrowed from other places as well. So we did, in some places, we also did Scrumban, but some of the practices alone that we borrowed were with Kanban. Any other questions? No, we used the tool. We were using Leankit, so the Leankit. So we started using Leankit, yes. What is that again? So for our kind of projects, big projects, teams at various locations, we like a physical board. Nothing beats a white board, but we needed an electronic board for sure. You want to add something? Yeah, for some of our projects, we're talking about hundreds of cards, you know, going on, which needed to be visualized on the board. So it would have not really worked for us to have a physical board. At the team levels, personal levels, et cetera, we are still using physical boards and people like it. People prefer using it, but then at a project level, we had to go for something which was... What we meant to say was that in an, for example, in an account. So an account wants to go and Kanban. So we will do a management workshop, get aligned on the basic principles of Kanban, and then of course, with the account we decide how the board should be structured, what practices we want to start with, how it should be, and things like that. They are aligned. So yes, so all the accounts... Yes, all teams are on Kanban. But two accounts would never look the same. So two accounts would look different. When we were just talking about the personal and team Kanbans, over there we allowed the teams, if they were just trying something new, they were just doing things at their own pace, and they were getting comfortable with it and only then moving on to something new. There is one KPI that you must track is probably the cycle time, because that's where the focus is really. And once you start focusing on it, it will force you to sort of fix a lot of things in the way you work. So if there is one KPI you must track is the cycle time, and that is something new that Kanban brings with it. You should probably continue to use some of your existing KPIs, some related quality, like escaping defects, et cetera. We retained some of those, but the cycle time was something which was the primary new KPI that we started. So on an average, I would say that a standard story earlier would take anywhere between eight to nine weeks. Today we are doing these stories in roughly three weeks, two to three weeks, three to four weeks, maybe that range. So when we started two years back, if somebody... They would do four to five weeks stories, and they thought that it was impossible. They didn't even thought that it was a possible... But now teams are very, very comfortable with the two to three weeks cycle time. Yes, you had a question. Right, so we... Yes, we have stories. So the idea is, of course, it takes time to get there, and I'm not saying that we are still there, but the idea is to break the stories as small as possible. And it's a challenge, I would say. It's a challenge. It's not something which we started with. So it was not unlike what you said that WIPP is something we didn't start with with WIPP limits, but it is something which we got comfortable only later on, and not that we are very comfortable even today. No, so he's saying that each story can be... If a big story will maybe take a few weeks, and a small story can be done in a few days. So how do you take care of those things? But you're right. The unit of measurement is these. Okay, thanks. Thanks a lot.