 to all, let the other guys get the coffee. To start with, my name is Venkatesh Suryan. I do reference Venkat. Along with me, my colleague, Anil. We are going to walk through the journey of agile transformation done in Cisco video business. So predominantly, to start with, yeah, as I said, it's me. Around 14-plus years of experience I have in embedded domain, working for various areas of product development and customer delivery projects in domains like consumer electronics, mobile multimedia, and digital broadcasting. On top of that, four-plus years of agile experience I have in transforming the organization within Cisco, as well as executing research-based projects, product development, and customer projects. Hi, I'm Anil, Senior Product Manager at Cisco. I have about 17 years of experience in the digital TV domain, mostly focused around project management, project delivery, pre-sales, and currently part of the product management team in Cisco Video Client Solutions, focused on the software side of the set-up box solutions. Yeah, so the moment when we say Cisco, people do connect with routers or networking systems. But this Cisco is related to pay TV. Like we, I was part of NDS three years before, so Cisco has acquired NDS. We were into pay TV business. So we were predominant into cable, digital broadcast, satellite, mobile, and internet. So these are the kind of end-to-end solutions we give to our end customers who are nothing but operators. And this is the kind of product portfolio we have. We have standard definitions of our set-up box, high definition, HDP VR, IP box, video everywhere. So these are the kind of product solutions we do, you know, deliver to our customers. As of now, we have been engaged with, or the partners who are engaged with us is around 47-plus pay TV operators worldwide. And we have around 78-plus million subscriber base. And these are some of the few customers who have been working with us. So in this journey, why agile for our Cisco Video Business? So if you see in the pay TV space or even video viewing space, there is a lot of changes been happening from last one decade. And there is a lot of changes are happening in marketplace, which are pretty much fast. And we need to catch up with that to sustain our business model and to ensure the existing customer base and to get the same revenues. And then for the employees to focus and to have fun at work, like as Z just bought the Joy. The Joy part, we just wanted to, you know, be ensuring that. And then we want to improve the predictability of launching the complex features. Like earlier, we used to have a new feature which we want for six months. We used to take for deploying it to launch it one-and-a-half years. So we want time to market also to improve. So I'm going to cover this journey into three stages. One is with the preparation, whatever we did, and how did we kicked off and how are we maturing right now? So basically, we have three levels of transformation categories we did. One is on the organization level. Second one is on the execution level and the people level. So predominantly from the organization and execution level, my colleague, Anil, will speak about it. And on the people level, I will speak about it. I expect to have two things in my head. I'll do that. A lot of... I realized I was sitting in Dananjay's presentation. A lot of... I would say a lot of commonality in the issues, the issues and the challenges we tried to resolve in our journey. So before I take you on the journey, I'll just give a bit of a history in that from our NDS and into the Cisco days, we did have some form of agile pre-2014 localized some teams picking up agile methodologies, trying to implement it and see how it works with them. We had some local success. We had some failures. And around early 2014, end of 2013, the senior leadership of our group had an opportunity to take the whole group, around 550 people, a full agile transformation, backed on the Cisco escape velocity program. So this was a Cisco-wide program which encouraged the engineering organization to adopt agile. So as part of that, the leadership team decided to take the whole team, the whole organization, into the transformation, agile transformation. And I think one of the key decision points is your leadership signing up for this. And they're deciding that they have a business need to make this transformation. And then you come to the problem of the structural situation that you have, the org structure that you have, and having to move it from a traditional system to a pro-agile structure that would help you on your journey. So we were organized component-based. The expertise were built in components, and the team was built around components. We had multiple components. We were a layered architecture, and we built up the reporting structure in such a way that it matched the components that we had in the architecture. And to supplement that, we had a metrics organization which had a set of project managers and an integration and validation team which would then support this team into taking whatever code was done by the component team, integrate it and deliver it to the customer. So this is the organization structure we had. And from here, we had to move to a pro-agile thing. We had to go to cross-functional teams and move from the component-based structure to end-to-end cross-functional feature teams. And this is where we ended up. So we had Scrum teams which report into directors that report into the general manager, and in the support, we had the other roles, the product owners, Scrum masters, strategists, and the product managers. You had the coaches also as an integral part of our organization. So this was the organization level change. The second one was to have an execution model change. So I just told you about how our architecture was organized. And you would see that from the system architecture, each component derived their design, did their coding, did their release as a component piece of code. And then it was delivered. So this is a very waterfall model with parallel component development happening. And then you have an integration team which is specialized to a particular customer who would do the big-bang integration of all that is required for that, all the development that has been done by the component teams for that particular customer, integrated, fixed all the issues that you find in the component level integration, and then delivered into the product. Now, if you scale this, you would see that for the second project, for the second customer, you would have another team, another integration team which would do a similar work of taking all the component development and then integrating it and delivering it to the product. So you had a problem of the scaling of your integration teams to deliver to customer, and it had to pass through that big-bang integration, the waterfall model, and then the big-bang integration before reaching the product. So there was a lot of time spent in delivering it to the product. So the pro agile execution model that we came up, which is you have Scrum teams that work on the same projects now, customer projects, they do their design, development, and integration and deliver directly into the product. So we have eliminated the need of that integration team that we had in between. So similar the scaling of it, you had for the second project another set of Scrum teams delivering their changes directly into product, and this point that we had quicker deliveries to the product and more deliveries to the product on a frequent basis. Now, in this journey, in the execution model transformation, we did see one interesting problem in that when we were in the component structure, the expertise was very local, and we had component experts who helped in the design and then helped in the review. Once you moved to a cross-functional Scrum teams where you had people from across components, you suddenly had to fill in this gap because you were now cross-functional and across components. So we sort of encouraged people to become moderators, and they are the gatekeepers of our code architecture. So the primary aim of having the integrators is to keep the sanctity of our main trunk. They are the gatekeepers of the architecture. Each team builds or contributes to the moderators and have sufficient moderators so that whatever they check in does not break the code and the main trunk. And we have encouraged these moderators to transform from being local experts to being vertical cross-functional moderators. So now comes on the people part. So when we are having the traditional waterfalls, we have roles like project manager, program manager, component manager, component lead, team lead. So when we want to move these roles to pro agile roles, where we have product owner, Scrum master and individual contributor or a Scrum team member. So that is where we had to go through a challenge. How should we do that? That is where the senior management has taken the people part also seriously, where the individual preferences are being asked. Why are we like what are the business priorities we have? And based on that, there was a room given for an individual to say that, you know, I want to become a PO maybe and then see for six prints and if it doesn't fit. So he will be given a second chance to, you know, take other role. So that kind of room was given and then we moved from the fancy designation kind of a, you know, hierarchy to a profession-based roles. That means when you're opting for as a PO or a Scrum master, you are really thinking as a profession, not like, you know, the project manager, senior project manager, instead of that, you try to contribute to that role more efficiently and effectively. Like as Scrum master, you start with one team, then be a Scrum master for two teams, then, you know, you scale up as a Scrum master. So for any organization like as we discussed in the morning, few sessions here about the culture and values. So definitely every organization comes with a culture which has good and bad, whether you are following waterfall or whether you are following agile. So now when you're trying to take this transformation, you just review what are the good parts of your culture you have as organization, what are the strengths and what are the things you want as organization to unlearn. So based on that, you decide and you, you know, frame a values. So this is how like the senior management and the teams together signed off on a values. This is what the way forward on these values we live with. Whenever we have any dilemma on, you know, doing these things or that things. So let's see this value as a sounding board, make it visible across and try to navigate, you know, our decision making based on these values. So that then only it will mature our practices or the ceremonies, whatever we are following on that we can sustain over the time. So keeping that values in mind when we started, this is where we said that the first, the senior management team, say for example, vice president, director, whoever are the key elements of that BU are the ones who are going to take the leadership training first so that they work in the form of a scrum so that they can lead by example. So they had a five day regress training. They formed as a scrum team. They created the transformation backlog. How should we, you know, way forward do the transformation for around, you know, 550 people? How about it? So they created the backlog items. They created the storyboard. They have a scrum board. So they had led with example and then they hired external coaches who can able to guide them so that if there are any behavioral changes or with about practicing the ceremonies, they are of great help. And this is where the outcome of that backlog was translate into seven batches where we have around 60 to 70 people, you know, from spread it across to four or five backlogs of whether it is a feature backlog, product backlog or a project backlog. And then a primary coach has been identified for each backlog who can able to hand hold them and guide them for the first six sprints. So we had to start with, we had two external coaches and two internal coaches to start with. And this is the, you know, a kind of a steps we take once the batches are identified, backlogs are identified. This is the circle they go through. At each backlog, we identify the leadership team. For them, we identify it and then we have a three days training for them so that they understand what are the ceremonies, what is agile is all about, what is agile manifesto and what is the obstacle, what is the definition of done. So these things were been taught in the training and then they create a leadership backlog for the backlog, whether it is a customer project or a feature project or, you know, or a product. So they create that. You have the team training for three days and then they execute a mini sprint so that they understand what is the prioritization, how the planning is done, how the retrospectives are done, how the daily stand up has been performed. So in the one week mini sprint, we do that and then a hand holding for the team by the coaches will be there for the next six weeks. So in that process, what happens is people first understand on the process part so that they all get aligned and the work creating working agreements. So people slowly start moving into that agile mindset and then after that, whenever the support is needed, we do that. As our business actually is a little bit complicated, as I said, we are into pay TV. We have an end-to-end deployment. Say for example, satellite, uplink, downlink. You have a head end and you have a box at different subscriber base. When we are releasing an image, there is a margin of error should be very low. So in that case, the competencies may not be located across multiple sites which are distributed scrum teams. So when you are starting this journey, the key important thing is we need to get along with all of them including delivery, account, sales, end-to-end architect, everybody together in this journey to make it success. With that kickstart, how are we in the maturing process? As we are dealing with a product which is having legacy on top of that which has been matured in the fields from last 10 years, on top of that we are creating new features. The first thing we have is technical depth. For any organization to mature and practice agile and move faster, we need to assess the technical depth. The kind of technical depth we had is with respect to automation, CA infrastructure. There are many ways, many technical testing. From manual testing, you want to move to automation testing. Or your build is taking like 10 hours. So these are all things which may be exist and you need to see are these a depth which you can able to clear in a day or it is going to be long term. Then you need to strategize that to make faster the teams to move faster and close the stories. So some of the things what we did was we created a working agreement. Then we created a definition of done with buy-in of the scrum teams where they said if I am writing a one line of a code, introducing it. These are the things I adhere to and I follow. Then the second thing is like technical depths are little very like monster kind of a thing to handle that. We said technical depth reduction day and we set a theme for each backlog. Somebody might have a technical depth of automation. Somebody might have a technical depth of building the build infrastructure. So these things all hands one day so that they can contribute and reduce the depth whatever we have. And also like effective engineering practices. Apart from that another flow is about obstacles. So this is something people do refer and the hardest part of any obstacle is like to realize that. Like what is the obstacle which is slowing down the team or in that backlog. If we realize it, I think the 50% of the problem is solved. So for this what we did was we had a kind of a visibility workflow where we said the scrum teams when they are trying to do the daily stand up they say based on the task break up you know I cannot able to move the task forward. Is there any obstacle? It could be anything. Like obstacle can start with a server room adjacent sitting to a developer is making noise and I am not able to work properly. Starting with that your build is taking like longer times. Your CA infrastructure is not robust. I don't have the APIs to be developed or I don't have the reviewer available on time. So it could start with from very small things which can slow down to any major you know systemic obstacles your organization have. The key workflow is bring this surface it out first and bring it visible to the organization within the team and outside the team so that whoever has the competency to act and resolve it faster. This workflow has helped us a lot. So we have a promotion criteria also in this is like after 48 hours if the team cannot able to resolve that obstacle we promote it to the program board. So we bring the visibility to the program level. If within 48 hours we don't get that we bring it to the exact level so that we wanted to bring the highest attention that if this obstacle is not resolved we cannot able to close this story or this release as an impact. So that we play a kind of key role and here Scrum Master is the one who actually plays a key role in identifying, nailing it, solving it and tracking it. So some of the systemic obstacles what we have encountered in our journey so far is like poor build CI infrastructure poor automation infrastructure shortage of competencies inflexible software architecture. So what are the ways we have dealt so far is like the poor build infrastructure like we had a CI earlier which used to run for 24 hours but the point is the reliability and the robustness of that was challenged and then we took an action item on that obstacle and then the resolution was we invested in the infrastructure we increased the number of build servers we need and also the frequency of the feedback so that a developer when he check-ins he knows that he has made a foul or you know is it good so that 4 hours, 12 hours so that there is a constant feedback which gives to the developer in a day at least twice or twice. Then the poor automation infrastructure like we had a huge number of manual test cases which we need to run to ensure that there is no regression for the code what we are going to deliver to customer but the time taken to complete that manual testing was huge and if we want to really get an instant feedback for the you know only automation is the only way out and for us to build that automation infrastructure from scratch it is a huge obstacle that is what we also identify as a technical depth the resolution what we found was at least once in a month like one day in a month all the you know workforce within our BU put hands on different features whatever we have and build the you know at least five scripts in that day by for different features so that we can able to build an infrastructure which is reliable and which can be used interdependently and the other thing was shortage of competence yes, yeah I think Jeff wants me to repeat your question you are saying that we are spending one day in a month resolving the automation problems no, no, no, that is not that what Venkat said is that we are running the tech reduction day the technical debt reduction day once a month and the concentration for that day is on getting your legacy automation covered so you do about five or ten scripts depending on what the team are willing to commit for for that particular day to reduce your technical debt two weeks and it is for all backlogs that is what as an organization we have concluded that two weeks is the duration and then shortage of competencies as the moment when we move from the competencies within the pockets to a cross functional team we cannot scale up those many competencies can be available in each backlog so we definitely have a shortage so the only way what we did was we invested in a technical coach and try to see at least if we have a backlog and we need C skills at least five people Java skills we need you know ten people automation skills we need you know three people like that at least whatever the minimum can be provided we accommodate and then we see in the next six months you know by doing pair programming or test driven development or extreme programming how can we able to scale up so that we are seeing some results like some that doesn't want like a tester sometimes is interested to become a developer sometimes a tester want to be a tester only so we take that individual preferences into account and we see how we can able to scale up and inflexible software architecture this is where we have a goal that where we were releasing earlier like yearly once a launch from there we moved to two months a launch from there we want to move to two weeks and from there we want to move for one day like each day you can able to give a potential shipable increment software which can able to be there so for that if we if our current architecture code architecture doesn't support then we have to move to a modular architecture which can enable us so these are the things we have encountered and this is the way how we have dealt with that to sustain our way forward actually we need to create sufficient like external coaches were there they handovered us but then we started creating like internal we have two tracks one is on the process track and one is on the technical track we start created like internal champions who can able to like next batches who are coming they can able to you know join with them and try to see how they can able to share their knowledge and learn from them and we can improve together and our journey continues so with this actually I want to just share a quick highlight on the what are the unique things actually we think in our agile transformation we had you know got or we wanted to share with you all is Cisco has as Anil mentioned like Cisco as a escape velocity we call it as a playbook which is a kind of a framework which is the start like when I be you says I want to move to agile for my business reasons where should I start with so this is the place we go and there is a framework which is available which says you know a kind of a not mandated rules but it says this is how you can do and if you think you can adapt something and you can so that is the starting point and also another thing was like there was a strong commitment from top management to perform all agile practices so seriously the senior management has adopt like they made a decision to move agile for business reasons and their commitment is very high and we have adopted like top down training model so since the execs have been participated in creating a backlog running through the sprint you know within sprint complete the you know story they know what is the pain like a CI server is not working we created a story that they do it in five days but the story might be taken for four sprints they understand what is spill over now you know what is the cost of why the velocity is going down so these things was very well understood by them since they have you know they have travelled through the journey and it helps us and hired and appointed external coaches this is very important because in 2014 before we tried scrum scrum but whatever it is internally but once the external coaches are there they can help the blind spots within our organization structure and they can able to surface it out much quickly than within our internal things emphasis on individuals and interactions through physical scrum boards like we like individual interaction versus processes and tools this is where actually we create the complete physical scrum boards like we ask even directors to walk in rather than asking the status from a tool so that they come and the witness they can see the board in the absence of you know team or the presence of the team so that tool is there if we have a distributed you know teams to share it we use tools but otherwise predominantly we prefer with physical scrum boards yes the question was did we have co-located teams yes and like we rolled out various guilds like for product owners scrum master and team members the like minded people can able to come and they can do innovation like we have some problems like even they can able to do a creativity like my retrospectives are getting monotonous what should I do they can like like minded people are whoever has facing the problem they can form in a guild and they can do for like two months three months and they can find like different techniques like out of that we with the help of coaches or with us reading several books we can share the knowledge and the guilds can give a better outcome it could be with the process or with the technical yeah over to you Anil so this large size the challenges are not unique you would have seen it in Dhananjay's earlier presentation we've added it just to say that we got a feel of our maturity based on the sort of obstacles challenges that were rising up so when we started the journey when the transformation started we had as Venkat already showed in the previous slide lot of traditional designations and people had to be mapped to the agile roles and a test engineer would walk up and say to the manager will ask what am I going to be am I going to be a developer am I going to be a scrum master the role they were going to play and around that role where the first few problems that people managers had to face the directors the senior leadership had to face they had to explain they had to educate a lot and then once the teams were formed and they started playing you would see that the roles especially among the first few teams tend to crossover and a PO thinking that the scrum master is doing his job and the scrum master thinking the PO is taking over his job so lot of stepping on each other's tools was happening these sort of you mature from there the teams learn the practices and then learn the roles and understand the role and then they start practicing the ceremonies and there you start seeing the team struggling to have to adopt the ceremonies and to stand by the ceremonies stand-ups not happening in the 15 minutes going on and on people not coming on time for the stand-ups things like that so that takes you through the next stage of maturity and your challenges become sort of competency missing in the team so you have asked the team to become cross-functional they were focused on one area they sort of try to live in that one area and suddenly they feel that there is nobody to do the UI because they are middleware guys so these sort of are the issues and these are the next set of issues that you are going to find because you have asked the team to become cross-functional and these up till now these are the easy issues to find you with little or with a systematic investment you can sort of overcome this issue once you cross this point in your maturity in your journey you sort of hit the big problems your systemic issues your CI not being able to scale to be able to make a build in 30 minutes you have set out and saying that is my target but then it takes 4 hours and then you realize you have to overhaul your whole build system and your CI not able to run all the test cases and you get only half the test cases done in that 4 hours and you have an overnight test which sort of breaks halfway through so you find systemic issues which become obstacles for the team to not perform and it takes a lot of time to resolve these issues and a lot of investment and then you reach point where the team now is adopting the processes the team now wants to improve its velocity picks up more stories and they are not able to complete the stories and they sort of carry on the spill over the stories and not able to deliver and that's where the coaches have helped us a lot in breaking that trend and those come with as you mature further and the next set of challenge comes you find that your team has hit a level of velocity and it's not moving beyond that and that's where the engineering practices the new engineering practices that you have to adopt across the organization come into play so we just put this up so if you are doing a transformation for you to get a feel of where you are the issues and challenges that pop up sort of give a good indication as to where you are on your journey with that so yeah any questions yeah yeah thank you so I was just wondering whether obviously there's been a very very huge prioritization with the senior leadership for agile implementation was wondering if you can elaborate more on what were the triggers for that you did touch upon some initial part prioritized but any particular reason why it was prioritized so high by the senior leadership no it is because right now as I said the video market whatever if you see right now the competition whatever it we are seeing like say from youtube or from apple so if we and we are in the traditional you know viewing business through setup box from that perspective the market is shifting much faster and if we have to do with the existing way of working as we see for any new feature when a customer asks for us we think six months is the development but they are seeing on the end to end like you have operational issues and by the time it launches into the field it is taking one and a half year if we continue to do that we are the survival is going to get challenged maybe not now immediately maybe maybe later of five years or ten years down the line if you have to make a shift then you have to do a radical change and that is what actually one of the trigger where we thought how can we increase our productivity and if within the same component structure and if we do the integration and if we do in this way will it work that is the reason we question on from the organization point of view from the execution point of view and from the people point of view so and that is where in the transformation and we move forward just to add to Venkat one of the key drivers was the business driver there in that customers wanted us to release faster we as Venkat mentioned we had like a six to twelve months depending upon the complexity of the requirements given by the customer we took about six to twelve months to deliver that feature and even a critical field issue would take about three to four weeks to deliver so we had to break that pattern we had to figure out a way to deliver faster and most of the customers who have joined us in our journey have looked at this as a great positive and saying that yes we you know two weeks you are getting a shippable code we want to be part of that journey so we are facing things quicker to us we can influence the journey itself so they are part of our journey in that they see our backlogs they prioritize with us the backlogs so this was some of the key drivers for us to take this transformation Hi my question is understood that pay TV must be considering of many projects and when you guys were transforming your approach to Aiskram was it a phase movement for some of the projects and others will follow or it was you know on a one single date all those projects that is where I showed you the batches like we created like one of the program we call it as evolution for that we were around 550 people were there and we have these many like 47 customer base was there so for that we created batches and each batch we slowly started with the higher priority customers which we need which doesn't have an impact on the immediate release plan so those homeworks were been done and the batches were been rolled out so like we started this journey somewhere around like last year march and we are right now in the sixth batch which we just finished the you know them onboarding onto the agile and we expect that by Q3 we complete all the you know batches so it was like a one year course of time or one to one like four to five backlogs it may have one feature, one product and two customer projects, something like that that is how we prioritize based on the without impacting the existing business and not impacting on the revenue that is how we have derived the plan Thank you How did you eliminate the integration so I mean yes I understand that components needed to be integrated together that's why you had an explicit integration team but with features also there needs a lot of integration between the features right so how did you completely eliminate that I'll take it so I'll give you an example I was part of way one and I handled as a product owner one of our profiles and the first thing that we did was to make stories vertical stories so the teams that picked up would deliver everything from the UI all the way down to the functionality and they were responsible for integrating it and delivering it on the main trunk so earlier what would happen is that you would have a UI team do the UI part I understand that so my point was mostly on the features so there is a feature one and feature two these features also need to be integrated interacting with each other at some point in time so how were we doing that that's part of your design first you decide a feature which is vertical feature you slice it up into stories that are vertical and can be delivered and deliver value and then as part of your grooming with your leadership so the leadership has the architect also involved in your team leadership one of the criteria is to see how you interact with other features and you sort of write your acceptance criteria to cover that interaction so it was being handled within the sprints it's not outside the sprints so if that particular feature have dependency on other vertical like feature delivering other vertical then how that was handled so we have the CI infrastructure that when get mentioned the test cases that go into it essentially are for the main features we have so if your team is delivering something into the main trunk there are automated test cases on the CI that we have built which will test the code for the sanity of the other features and that particular feature let me say only one customer has a feature and that platform is added to the CI infrastructure in such a way that when you deliver your feature or team may delivers it it doesn't break that particular feature which is only available for one customer that is from regression perspective but from the delivery perspective or the development perspective itself if you have dependency may I add go ahead so here say for example before it goes to the scrum team the product owner and architect and end to end architect they will groom the feature so granularly that within two weeks duration you can create a vertical slice which is demovable like one test scenario of that feature A with all the dependencies identified the grooming has to be applied first and in the grooming the dependencies will be identified like how many platforms should I execute it has relation with middleware or UI what are the dependencies are there so those dependencies should be identified and see that this backlog and the like if you have two scrum teams three scrum teams do they have the competency and by evaluating that they create the acceptance criteria in such a way that either I create a stub or a mock so that I can able to fulfill the functionality so that if that is going to take time that story will come like I do a part A of the story A.1 when they do it when the component is available that scrum team will take the response by removing the stub integrating it and doing the regression and performing it so that whoever the scrum team takes they are going to add delta on top of that so that is how one of the way it can be done when you moved from component teams to feature teams one of the major shifts is multiple feature teams touching the same component which is entirely different from a set of people touching the same set of components in the earlier days so this poses a lot of threat towards the architecture being kept intact so was it a situation for you how did you manage it so I think you saw my slides on the moderators I am just going there only on the moderators you saw it so that was one of the beginning of our journey that is one thing we realized in that we had experts at component level when we asked the teams to become cross functional we still had only experts at the component level right so we had a moderates the first thing we did was to make a guild of moderators because it from day one we couldn't have a vertical moderator so it was almost a guild which each scrum team would approach and say I am building this vertical feature I need a commitment from the guild to review this code and make sure the sanity is there and over time lot of this moderators who are part of that original guild are now vertical moderators which means you don't need two or three people reviewing your code your vertical code you can now have experts who can for the for that feature be the single point of moderation it is like an open source model your main trunk is open to all 550 developers who can check in and check out the code but once they check in gatekeeper who is having the component expertise earlier in pocket is since he is either part of the scrum team or he is part of any one of the scrum team so he becomes the gatekeeper for that feature area whichever the code comes he owns that so he gives his you know review comments on top of that unless until that is not in sync the developer cannot be able to complete the another way of working is when the developer goes into the sprint planning if he thinks this is the feature area I am going to get because in the look ahead we submit this then he calls that moderator into the planning meeting have a conversation with him when he bringing the tasks so that he is the moderator is involved from the day one before he writes the one line of the code so that within the sprint duration it helps him to because he has already said this is the approach I am going to follow and there is a mutual agreement about that day what happens is the review becomes faster so that he does not on the day five, day six when he submits the review time is like maybe half an hour or two hours they close the review so that within the sprint that story can be delivered I had a question on the product owner transformation right what is the how did you approach the overall product owner transformation because that is something which I have seen as a challenge in the past when you move from traditional teams into scrum product owners being central to the velocity of the teams right so could you please speak through that it's something that we didn't cover here so I had personally a very interesting journey I was part of wave one as a product owner currently I am a product manager so with your scrum agile your product owner interaction with the team is quite evident we have in our organization a separate product management organization I as a product manager interact with product owners okay so I define the portfolio take a particular set of box portfolio I would define the requirements that the market are demanding I would write the high level business epics then I sit with the product owner and we detail out the stories user stories at a high level that map onto this business epic we prioritize that I take back that user stories as what we call the agile commit and we go into the approval process saying this is what on behalf of the team I am bringing forward what I as a product manager and the product owner have sat together and agreed upon as what is going to go in as the prioritized list for that particular agile commit so that's the way we work the tool we are using today for our stories is rally I have one question thanks to both of you for sharing this experience you have the continuous integration build and finally when the build is ready how much time typically do you spend after that do you spend any time first of all on any of the manual testing how much time do you spend I will take that right now as currently our infrastructure say for example the product whatever I am working has 1700 test cases which need to be executed to get the confidence that it is good to go and deliver and deploy now the duration first thing is we didn't have enough automation infrastructure yet where the 1700 can be executed but at least the P1s whatever are there so that we want to ensure that regression is not in place so within 4 hours that execution completes beyond that what we take is we may spend like in the sprint that we have a test strategy how we planned was the CI gives us so we take day 1's baseline and we do a testing we know what are the check-ins actually went in then day 5 we change the build so that we do only the delta testing so that what happened is this entire 1700 test cases are been executed across 10 days from day 1 so that what happens is by day 9 when we come we know this is the delta which needs to be executed and we execute that and we deliver it that is how we have arranged so you can say the test effort required to execute that 1700 is spread across like in the form of 3 or 4 user stories across 10 days I have one leading question to this one may ask question is that let's suppose this is more from your more forecasting approach but let's suppose you are in a situation where you are having every infrastructure everything ready based on your experience still how much manual testing is required your experience to me if you have a robust automation infrastructure which can give you feedback maybe in like when I am doing a check-in if I can get one hour all the test execution completes I think you have to do only kind of if you have any acceptance test which you have agreed with your customer you should execute it and you should deliver it that's all and thanks for Agile India 2015 for giving this platform to us and thank you all and paying attention to our conversation and I really enjoyed it thank you