 My name is Vinu. I work for Exiles of Sri Lanka and this is my second time at a Jai India conference And I have been enjoying the sessions always and I have I hope that you all have been enjoying it too at least so far So the project that I'm going to talk to you all about today is the project that I have been working on for the last four years Which is the warehouse management system see all might be thinking why do I call it alien domains when it's a warehouse management system? So first of all, let me get into that and explain it to you all what are the complexities that we have here This is one of the automated equipments that is used by our customers Which is called the auto stove the complexity that you have here is that you see a big grid at the top You have a lot of beans stored stacked on tea on top of each other And there are some robots at the top who will pick these beans and bring it to the user So actually the concept is that in a normal warehouse management system The user will walk around to get goods that he needs in here We call that concept as the good to man concept We are the robot will bring the goods to the person and the user can stand on these ports at the edge of the grid So if we get into the complexity that we had to handle here is to make these two Two parts of this auto store to make make them work more efficiently One is the user who is standing here has to be more very efficient when he's doing his work as the robots at the top When they bring the goods to the user, they also have to be more efficient That is one of the complexities that we had to tackle in this equipment And there are some other equipments that we use that is called the lifts and some voice systems that we had to handle in our project So if we all to get a glimpse of what auto store is about, let me go into the next slide Need to make more out of that my employees and miles a day to get the goods I could place the shelves closer to one another I need a totally new way of thinking This is it Bins on top of one another inside this grid leaving nearly no space unused Robots could fetch the bins and transport them to the picking ports. My employees would get the goods without even moving Even less the half space More efficient secure and reliable Better use of manpower. This is not just an illusion The future of warehousing auto store is as real as you are The goods to man's strategy should be standard in any modern warehouse Auto store will realize this at a speed and space efficient way. You never thought possible Auto store store goods in bins stacked on top of one another in a self-supporting Aluminium grid the grid will align the bins and also function as tracks for the auto store robots Radio controlled and battery powered the robots handle the bins on the grid to and from the auto store Ports the port is where the goods are taken in and out of auto store bins Controlled by the warehouse management system Auto store control system schedules the picking lists transferred from the warehouse management system The thoroughly tested control system plans and controls the robot traffic Control over the auto store robots bins and ports at any time in real time When new goods arrive to the warehouse goods that are to be stored in auto store are transported to the auto store receiving ports This is where the food away is done We are going to go through right now The first thing is of course the new domain and the domain was huge because this warehouse management system has been installed And different customers who operate with different products and so on So for this what they had to do is they have to customize the features that will fit into each customer's context So that added a lot of complexity to our domain Apart from this the key factor that our customer is like being the very leading person in the warehouse management system is that they make the system very efficient in a way that they don't lose time When the users are working with the warehouse Apart from this for us to understand this domain There were no such documentation that was available for the existing system that they are having and Apart from that they had a lot very limited resource from their customer sign who can actually give us some Classifications when we needed to clarify requirements. They were very limited people who are available. So that added more complexity for us Apart from this they were they were having a legacy system which was installed in their customer signs already So whatever the new features that we build has to be compatible with the existing system that they were running We will not be able to do a big-band release where we convert all the legacy application to a new system And then do the release because they are new customers are waiting for new features and the time to mark a factor play the big role in this And the legacy code they say like the doc the best documentation that you can find is the code But for us to understand this legacy code It was not properly structured in a way that we could go through the code and understand what they have implemented and If we say we spent a lot of effort and trying to understand this domain and document this in some way that we could do that There was no one in the customer side who was available to go through this documentation and validate the other understanding was correct and On top of all these things the custom had no agile experience where we had to handle this project by Educating the customer first Okay, the six million dollar question that we have now is from where we start this project If you take a look at the two parties that are involved in this project the customer and exile soft Customer knows a lot about their house management system, but they do not have any experience with agile practices If you take a look at exile soft, we have a lot of experience in managing agile projects But we don't know anything about a warehouse management system So in order for us to start this project and work together the first thing that we need to do is Share these knowledge that we had between these two parties So that is what we did as the zero sprint in our project What we did is our project officer to share our who was supposed to be my co-presenter here Unfortunately, she was not able to make it. So we they had a we plan for an on-site business We are she visits the customer side Go there study their business context and see how we can implement agile in their context The next thing that we did is the product owner who was very familiar with the domain from their side came to our office And trade us like they have like they do a new installation at a customer side We took up like a blank database. We filled in all the things that they need We created equipments that they need so maybe we went through this workshop in order for us to get an understanding about the warehouse management system and Apart from this, we did another thing the you the team that we had here needs to actually see how these users Operate with these automated equipments for us to understand it better. So we plan for a field trip where we go and visit one of the automated warehouse management Environment where we can get that understanding then the next thing to tackle is the contract type How are we going to come up with a contract type for a project like this? As I said like the domain was so huge We were not able to understand so we will not be able to come up with an estimate and see okay This is the budget for this project So when they agree we are going to come up with another model where the customer will pay us on monthly basis for a dedicated Team that we are going to have an excel software them that was some kind of a In both ways it was kind of a win-win situation We are we don't have to estimate on something that we don't know and for the customer They are willing they had the freedom that they can stop the project when they see that we don't deal with anything No, we are still continuing the same model The thing is we work on Like feature-based releases where whenever new customer comes in we will work on that feature and release that So the model that we came up with even fits in now for us even though that we are familiar with the domain now It's not a risk that we don't know the domain and we might not be able to estimate it whole up front But still we need to do features on release basis Say we do some features now and release it to an one customer Then another customer might request the same feature in a different way So we have to redesign and re-engineer to fit that context So the still still even though we are familiar with the domain the same things that we have come up with still is valid for us No, we have still The legacy application that they had was already running in a Safe environment they had the source control. They had their real server set up They had tools and techniques that they were using so we thought of sharing all that with us and we didn't do any setup at all Let's see how we evolved through these four years We are the switch from like it evolved in a way that we don't do the exact textbook A giant practices and we do some things that fit into our project First of all the team model. We have a highly integrated team structure where we have developers from the customer side developers from Exiles of working together and we have two from masters from both things Where it was before we thought that it will be easier for having two scrum masters who can coordinate things internally with each team But think that we do differently when you have two teams you generally have two scrum meetings They stand ups and then you have some of stuff. We don't do that. We have singles from meeting We are the entire team from our side and the other side get together and discuss on what we have been doing each day And the other thing that we did is if you all haven't gone for the session that we had on enterprise experiments yesterday, we find out I practice this pink balloon strategy that What does it talking about what we do is when we add a new team member to the team We try to see whether this team member will fit into Not only whether he has a number of experience or number of a giant experience not only that When I say that we really see that there is that person will fit into the team We don't consider only the local team that we have in Sri Lanka, but we consider that On-site team as well. So we have two discussions one will be done internally We are our team gets together and have a discussion with the team. We arrange for another discussion with the customer We are they will be able to talk to this person before this person is added to the team This gave us a very comfortable Already know the person that we are going to work with the customer was very comfortable in working with the team like that the other thing as I explained like The thing that we do is we build features for different customers who are going to use this warehouse management system So when we develop something for one customer, then other customer who is going to buy this product might want it in a different way So we have to redesign the feature that we have done for to fit it to the next person as well So what we did a decide is okay? We do enough design upfront We don't think of all the complexities that is going to come up because we don't know them what we do is we do whatever we know based on that we design and Everyone involved has the understanding that this design will evolve. So with this understanding we were able to come up with this structure The sprint we evolve the design we restructure we refactor do a lot of changes to the design that we are doing even within this Print then the other thing that we had to tackle is the multiple customer releases that we have We do we have like planned releases for two different customers where we have to do DvLiver to set up features to two different people. So what we thought is okay? We are going to have a split in the team We are one set of team works on one customer's features the other set of team works on the other customer's features But this was done not done very like a fixed way It was a very dynamic way that we adopted what we do is in the morning we come to work Okay, I'm working on this print Do I have any pending work to be done if I don't have anything in my sprint I switch to the other sprint and do some task on that sprint So in that way we were able to parallely work on two sprints and have multiple releases within the same time period The other thing that we did differently is the sprint planning at the initial stage We also thought that the product owner has to be in our sprint planning meetings and we try to do that But the problem was the product owner from the customer side was the only person who know the legacy system Thoroughly so what whenever they get a production issue from their existing customer this product owner had to spend his time on those Fixing those bugs. So we were not able to get him for an hour our based Planning meetings. So then what we decided is okay? If we can't get him to a huge number of hours for us to have the planning meeting Maybe we can divide this then we came up with another planning approach is the The pre-planning meetings what we do is when we are working on the current release We plan for the next really a sprint that we are going to have and get the product owner Maybe half a half half an hour or 45 minutes time durations Where we can get him these segments and plan for the next release that we are going to have So that was something that he was able to commit to rather than having a lengthy planning meeting So this is something that we do even now we have Like parts of a planning meetings and we come up with mock-ups We come up with scenarios we document that and then internally we have the planning meeting with the team again Even the planning in the planning meeting. We are having internally if we have some Clarifications or something again a 10 minutes call to the product owner. We clarify that and finish off. Yes Because during these pre-planning sessions We were not able to get the entire team into the planning meeting Which means they have to stop their current sprint work and come to the pre-planning meetings So what we do is whoever is working on those related features We get them to the pre-planning meetings with the product owner where I act as the proxy product owner So once we get this in when we are having the planning meeting I act as the proxy product owner going through this Features that we are going to develop but something that we have not discussed in the pre-planning meetings come up We call the product owner again have that life right then and there Only internally like we have like new team members coming in so they don't know even the things that the current team knows So I act as only internally providing clarifications and things for things that we have already done But if there is a new feature something that has to be Implemented in the product that kind of a decision still the product owner makes that call because they know they are customers very well Then what we know about them? The other thing is the continuous communication. We have development teams working in two different places without this continuous Communication we will not be able to be successful at all So we have daily scrum meetings as we do in scrum But apart from that we have quick chance whenever we need that whenever we see that there is a necessary We have ad hoc meetings We have Skype chance that then that we copy the Skype chat and put some place that we can refer to we use confluence for that So we coordinate things internally a lot and with the customer whenever we need said there is a Communication needed we don't like wait for the scrum meeting to come up Then the test was something that we actually needed in our project rather than saying that we use tests We depend on when we develop something for one customer and we re-engineer that for another customer We need to make sure that the first customer's features are still working So we depend a lot on test for this we came up with this celebration then when we reached the 2000 test and How we did this is we can't write test for each and every functionality with the high coverage So we decided what are the co-functionalities in the system? We write 80 percentage to 80 percentage of a test to cover that the 80-20 rule basically and whatever is not that Complexed or not that important for the system. We write less tests The code reviews of course is another factor when you have a big code base like what we have So what we have to do is like Time-to-time we had these planned code reviews on top of that What we do is whenever we are working on some methods that we are fine That it is going to get complaints or this might affect another feature that the customer side is developing We have a like a 10 minutes code review with only the people who are involved in developing those features The testing process of course as I said we have a lot of automated equipments Which we don't have in our local environment that we can test with so what we do is we use Simulators to test when we do the development and with the simulators We will be able to come up to a level then we give that Work working and software to the customer where they have some sample installations done in their environment So they test based on that Then then only we will put this working software to the end customers test environment Then they will be able to do some testing before putting this to production The work distribution of course when we started we were not that familiar with the domains So the domain part of the work was handled by the onsite team and we did a lot of presenter work That caused us some problem where we can't test anything that until it's fully done So now we are in a situation that we can also work with the business domain So we split now verticals when we are working with the features Then the most important thing is the trust between the team members We have been able to build this with a lot of transparency that we have been Putting some effort to have whenever we have a technical problem We have developers from their side also So we open this technical problem to them and have an open communication with this The same way from their side whenever they have a problem with the release or so on They were able to communicate this to us and ask us to put some extra effort or something Which will help them with their customers The next thing that we came up with is the technical depth Whenever we are working with a customer release, which is to be released by next week and we see some problem We need to give a quick fix even though that we know that is not the proper way of solving this bug We are working on a product. So having a clear code with a proper functionality is very important to us So we will not be able to give all these standard fixes Which is a perfect fixers for us when we are working with these releases So what we do is whenever we are working with the urgent release we give still a quick fix on that But what we do is we develop we created a component called the technical depth and whenever we come through a situation like this We add a new task to the technical depth that we need to handle at a later stage After this urgent release is done. So once this release is done We get some bugs from the production environment that settles down Then we go to this technical depth and handle what the problem that we solve quickly We handle it in a proper way at that point Then if you let take a look at today's success There are three entities that we are working with Exile soft our customer and the end user if you take a look at this the success that we have been having is All three parties are happy with our team structure today the end user one of the biggest company in Norway called Bertel Nostin who is the Soul agents for Mercedes Benz. They are using the warehouse management developed by us and they have given the Open invitation to our customer that they are so happy with the system that if our customer has any potential customers They can bring them to their warehouse to demonstrate how this product is working there And our customer has extended that to us because we are part of that success And we can take any customer that we have to their warehouse and see this is the product that we have developed And this is the team that I'm talking about to make sure that we have not changed into aliens So that's about it. And I think I'm running Have run out of time. So if you all have any questions, I would like to take it. Yes It was actually first when we decided If we can have the normal way you have a play a sprint you complete that and then you start with another The end users that were supposed to get these features have to go in a Like a sequence. We can't have parallel releases to them They were not willing to wait for these things So what we had to do is at the beginning what we thought is we don't split this team in a way that we Have done at this point, but at the morning we come okay Check on what are the critical things that are coming up in releases and take on that That was not that successful because when you're working with the customer You know need to know the environment that you're going to put this feature into because each customer's environment is so different That you need to understand that so on daily basis switching was not that productive So what we decided, okay, we'll have a split, but whenever we see that there is nothing to be done here Then we switch Yes Even though we work split when we when we are taking up task in two different sprints We split the planning meeting is done with entire team because whenever you run out of tasks. You're supposed to pick from there Because of Our sprints are not time boxed We go based on the releases that we have and the sprints that we are working on currently is not time boxed We see what are the features that needs to go into 7.3 and what are the features that needs to go into 7.4? So based on the features that we are planning for 7.3 we plan what are the customers who are going to get that and What are the so backlog is actually for 7.3? You have a backlog and 7.4 you have a backlog, but until 7.3 backlog is done and it released to the customer We don't concentrate on the 7.4 backlog These sprint backlogs are actually customer features which will be released to that customer. So once this print is done and No one backlog one backlog for one customer sprint release Sorry We try to have them In one sprint at the moment But when we finish that we switch which means we don't have a resource who is going to always support this end user That person will switch from sprint to sprint Based on the release that we are planning say there are two customers that we are targeting for Based on that we split but there is no person who will always be the supporting person for this end customer We try to have them In one sprint at the moment, but when we finish that we switch Which means we don't have a resource who is going to always support this end user that person will switch from sprint to sprint Based on the release that we are planning say there are two customers that we are targeting for Based on that we split but there is no person who will always be the supporting person for this end customer So we are running short time for the next session You