 Welcome everyone to the session, Experience the Power of Poll System by Kiran Kashyap. Just a short introduction about Kiran that Kiran is a proud Scrum Master. As a Scrum Master, he has taught agility to his team and is involved in exploring the way of teaching and practicing agility with a unique flavor of his own. In his leisure time, he has been playing badminton and he loves reading. Let's get started. Over to you, Kiran. Hey, thanks for the introduction, Karthik. So, hi all. Good evening, good morning, good afternoon from wherever you are. So, this is the topic, Experience the Power of Poll Systems. So, before going there, I just want to thank Ajay Lindya and team for giving me an opportunity to talk at Ajay Lindya. And yeah, so before going into the topic, I'll just quickly introduce myself. Myself, Kiran, and I have been in this industry for close to nine years. And apart from work, I've been an open source contributor and I've been blogger. And I've also co-authored a book on metrics for agile product teams. And I'm also a volunteer at Tech Code Circle, which will help Scrum Master project managers to become a more techie. And for them, we help on the concepts like technical agility and stuff related to that. So, and I also love playing badminton and I love reading history and philosophy. So, yes, enough about me. Let's start. So, before going to discuss how to create a pull system. So, let us first try to understand what is a push system and what is a pull system. A push system is something where the work is being pushed to people without considering their capacity. So, that is on a high level push system. And what is a pull system? It is a system where work is being pulled by person based on their capacity. Here, the work is not being pushed onto the person or people. Rather, the work is being pulled by them whenever they have the capacity. If you have not understood it fully, that's okay. You'll understand this more as we talk about other things. But we can again discuss in this Q&A session as well if you want to know more about this. So, I'll try to explain how we created a pull system in our team in the form of story. So, in that story, let us assume we have this team and the team is called as Avengers. And we have developers, tester and product owners, three developers, two testers and a product owner. Here, the team assigns tasks to themselves. Nobody tells the team members, okay, you pick this work or you pick this work. Here, the team assigns tasks to themselves. Generally, this is where we think that we have created a pull system. And this is the board they are currently using. This is their team board. They have this backlog and they have their development column, peer review column testing. And this is the column they are using. So, do we have a pull system here? It's my first question. We obviously know this is not a pull system. But if you think, why is it not a pull system? If any of you have an answer, you can just ping in the chat. Why do you think it's not a pull system? I'll just give few seconds of time. If you have some answer, you can ping. Otherwise, I'll explain to you why is it a pull system or why it is not. So, I hope my question is clear. So, my question is, this is the current board the team is using. Is this a pull system? If not, why is it not a pull system? If you have a simple short answer, feel free to ping it in the chat. I'll just wait for few seconds. If I don't get any answer, then I'll proceed with it. Yes, we have an answer. It does not have the limits. It's not a pull system. Okay. Yes, it's not a pull system. Why is it not a pull system? Because if you see here, the tester doesn't have the right to say no. So, in pull system, what happens? Here, the team or a person pulls the work to himself. Or he gets a work only when he or she has the capacity to take the new work. Otherwise, if the work is being pushed on that person, it's a push system. Let me go back to the board and explain to you how I'm... So let's say here, the developer finished a couple of tasks and pushed to peer review. And here, once the peer review is done, it's again pushed to the testing column. So when the task is being pushed onto the testing column, this person is not concerned whether the tester is available to take work or not. Continuously, the work is being pushed to the tester. So this particular person is not worried whether the tester is able to take work or not. It is being continuously pushed. The work is being piled one by one to the tester. And that is why here, the tester is shouting that I do not have the right to say no. And that's why this is not a pull system. So one conclusion I'm trying to tell you is in a typical pull system, everybody has the ability to say no. When I say ability to say no is not yet, I can take it after I get free. So that's what I meant. Now, how do we solve this problem? Any answers, anyone? How can we give the team the ability to say no? Any answers, anyone? If you have some answers, you can, you know, bring it to self-managed teams, okay? Any other answer? How can we empower the team, you know, the ability to say no? How can we bring it, you know, into the system? Now the teams is self-managed, but still there is some pull the task from peer review column. Yes, now also the dev column before the test column that holds card, okay? The tester pulls the task from the peer review column. Yes, the tester pulls the task, but you cannot stop the peer review guy once he finishes the task. You cannot stop the guy, you know, for him to push the work once he finishes to the testing column. All right. So what did we do? I think we already got that answer from one of the person before. So we added work in progress limits, right? What is work in progress limit? It is nothing. It is just a simple limit which we put in each of the column. So let's say we have, we have here different columns here, you know, we have development peer review testing and for each of the columns, we are defining a number, you know, above which we will not do. So let's say at a time we are developing only three items. We are not taking more than three items in the developing column. So that is the limit we have put in the developing column. Similarly, two is the limit we have put to the peer review column. And similarly for testing, we have put a limit of two, right? Now you may ask the question, how do we come up with this number three, two and two. So it is just experiment. You guys can experiment with your own teams in order to come up with that number. We initially started with this three because we have three developers. And so we went ahead and experimented with number three. And later, if it doesn't work out, we can always change based on the new learnings. Yeah, how do you I hope I answered your question and you can put these questions in the Q&A column as well. Later, you know, we'll take these questions. Now, now we solved the now, now our initial problem was the developers, the tester doesn't have the have the ability to say no. Right. So do we have we given the tester the ability to say no, no. Yes. Right. Because here, if you see the WIP limit for testing is two. That means once there are two work items here, two cards here, the card here cannot move here because there is already a limit which is two. So now this board, the system itself will tell that. You know, we will tell the ability for the people working in each column to say no. Now, did we create the proper perfect pool system? Or yes or no. Anyone just yes or no. Do you think we have created a pool system now? Yes or no. Okay. One yes. All right. Now, we have solved a problem where we where the team can have the ability to say no, but. But it has created another problem. No. Earlier. Now the developers started shouting. I we have the right to say no, but I'm not getting the credit for the work I have finished. How did this happen? Right. Now, let me go back to the board again. Now what happened developer has three items working parallelly. He has finished all his items. He wants to get, you know, move this card to the peer review column and he has to and he decided he or she has decided, you know, to pick up the new item from the backlog. Now that cannot be done because the peer review already has two items working on it. And if I go to the testing column and why peer review, the two columns, the two cards is stuck because the tester is already stuck with two items which he is working on from a long time. The tester is stuck, maybe because there is some environment issue, maybe because he's waiting for some information from different team. Now, since tester is stuck here, the whole work before the testing column is also stuck. Right. Now, because of which the developer is telling I have finished my work and I am not able to finish it and management is asking developer as well. Why are you holding these three items from a long time. Now this has created a lot of confusion now developer goes back to tester and starts adding pressure on to the tester like because of you we all are stuck and everybody is questioning me whether I have completed my work or not. Now the big problem is because of adding the wip limits, we have created even more problems. Right. So this is one of the main learnings we had. So whenever we hear about Kanban and you know, pull system, the first option that comes to mind is adding wip limits, but just adding wip limits may cause a lot of other problems. Now, how did we solve this problem? We just split each column into two two columns. So development we did it doing done similarly peer review doing done and we just add doing done now developer has the know whenever the developer has finished some items. It is going to done and now the developer knows that whatever he has finished it is done and whoever comes to the board and sees let's say it's manager or anyone. But this this particular person has finished his task and they can go directly and see where it is exactly being you know blocked. So let's say here also it is done and here also it is done. So yeah right here it is the testing work that is stuck all the three items or whatever it is and that's how we can identify this blockers. Now developer instead of going and blaming the tester the developer can go and help the tester to move the things to done because it is blocking his work also right and once that culture is formed instead of people blaming each other. Now everybody can work as a team now now developer need not worry about you know what people will think whether he's finished his work and you know whether it is visible to other management everybody. And he's not worried about that he knows that he has completed his item all he has to do is he can go back and help the tester or help the peer review column to move the things you know ahead. And and yeah and and and so and this is not the perfect pull system again it can again improve the goal is we always you know need to continuously improve identify wherever we can improve the system as a whole and we have to improve the system as a whole. Right not only just development column or each work center we have to see if we are doing some changes in some column is it affecting to the whole system. And and yeah this is how we implemented you know a pull system this may not be the perfect one but it always has the you know room to improve. And now everybody is happy there is no you know pressure on developer tester product or everybody is happy because everybody is being everybody is pulling items only when they have work and and yeah. And and if you ask me even you know even more if you ask me this is not a perfect full system I would agree with that because here in the backlog if you see the product owner can keep adding items here. Right and and that sort of make create a you know psychological push to the whole system know the people keep seeing there is a lot of items continuously being added here and what do we do so we can add a implement in the backlog as well. So only few items are visible to the whole team. And that that also can be another improvement. Right. So what did we discuss till now I'll just explain the advantages of pull system, which we already discussed. One is quickly adapt to changes like we saw the we immediately identified okay this is where you know the bottleneck is and we have to change something we may have to add more testers to the team because every time the testers is is getting blocked right that is where the the work is getting bottlenecked always. That is, we can quickly adapt to whatever change we want to change and identify bottlenecks like I told so we easily know where in which work center exactly the bottlenecks is happening and we can take action on them. And shared ownership of items like I explained instead of developer blaming the tester one for not finishing things quickly. Now the developer can go to the tester and work with him or her and then push the items to the next stage and improve predictability. Now since since everybody's focus is to move the items to the next stage continuously. And now the overall flow improves now the lead time improves when I say lead time it is the time taken from if in our board from backlog till done. That is the lead time and and the lead time predictability will include you know sometimes what happens. There are some items which you know we suddenly finish in just half a day and there are some work items which takes like two weeks to finish. And now these kind of items also we can sort of improve that that gap we can reduce. And then of course improve quality since we are adding working progress limit people are working only at a time they're at maximum working one item or two item at a time. So their focus is only on that and this will significantly improve the quality. Yeah, so to summarize we discussed what is a pull system and what is a push system and how did we implement this in in our teams and and because of adding whip limits what challenges we faced. In fact it went even worse than what it was before and then how did we correct it right we added doing done column in each of the columns and and yeah and also we discussed what are the advantages and and yeah that's it. Any questions here and I see one question by Eddie Bush in Q&A that this still isn't a complete pole system is anything that you would like to share on those lines. I think that was asked before. Before I was explaining but but yeah I agree with that statement it still isn't a pole system, we still have to. There is always room for improvement, but do you have any idea do you think any anything can be improved in this final stage to make it a pole system I'm happy to hear. John Wilson does it make sense to throttle the bottleneck. Yeah I agree with you. I was just trying to explain we can identify bottlenecks and take decisions based on that it is just helps us identify the bottleneck but but yeah I agree with you there. Thank you so much for your time today. Thanks again for giving me the opportunity and and and please everyone if you can connect me on LinkedIn could be great. And if you have any feedback, please feel free to ping me on LinkedIn. I'm happy. I'm always happy to receive a feedback. Thanks.