Software development used to follow the waterfall model for a long time before a group of people came together to create something better. This meeting happened in 2001 and it changed the world of software development forever. Agile has been the most popular method of software development for over two decades and it is showing no signs of slowing down but simply evolving to cater to even bigger challenges in software development.

In this week's talk, Amit and Rinat talk about Agile, what is it, why its so popular, what are the different agile principles/methodologies and a lot more!

Hi everyone. Welcome back to Tech Talk. Today we are going to talk about a much requested topic. Agile methodologies is a very popular or a very well implemented methodology when it comes to IT software development. So, as you guys know, for new listeners, you know, Amit and I we every week we pick a topic and we dive deep into that topic. Today. Usually it's a technology related topic. But today, because it was a topic we're going to talk about agile methodology, which is no directly tech topic, per say, but it is very close to software development and anyone who is in IT probably already knows about it or if not, they should know about it. So we thought it would be a good topic for us. To cover. So, yeah, I mean, you know, we are not in any way the sort of official sort of descriptor of agile methodologies but we've used it in in in various engagements in the past and a lot of the times we've also widened not strictly, you know, we use some sort of hybrid of agile methodologies tailored to the organization need. So we have, you know, maybe not academic expertise, but we certainly do have commercial and sort of practical real life implementation of agile methodologies. So, yeah, quite, quite exciting topic, quite a niche topic, and I feel like what we have experienced in our various job experiences would help the listeners and viewers understand the methodology and see the freedom it offers as opposed to some other ways of working in it. So thank you guys for listening. And thank you guys for coming along. Amit, do you want to start off with what do you think agile methodologies is?

Amit Sarkar 00:2:12

Yeah, thanks. Thanks a lot Rinat for the introduction. I think it was a it was a request from one of the listeners and we wanted to cover that topic. So Agile is not related to tech, but it's a process that people follow to deliver a software product especially in the technology industry. And it has been very popular because of the way things move in the software industry. We have to deliver things very fast. And that's why this methodology came. But we need to understand the history behind why this methodology came because prior to Agile delivery, we had a waterfall model and that used to follow an iterative I mean, not an iterative approach, but a serial approach, where you start with say, what are the requirements? What do I want to build in terms of software? And then you try to define all that. Then you start planning Okay, what do I need to build the software then you start building it. So you've done the planning, so now you do the development, and then you do some testing. And testing comes in the end. And that the problem with that was that because testing was at the end? It took a lot of time to find the defects. So suppose you start with the requirements in the first phase, planning and development and then testing it has taken up to three or four months so you have not actually tested or seen the product. And by the time you start giving feedback to the development team about how the product is and how it should be based on the requirements. You end up spending a lot of cost in fixing it so it's too late in the cycle. And once you test then you have to go and release it. So that used to be the earlier model where you used to start with the requirements planning, development. And testing and release. In between you also had the design phase where before the development or how the software should look how the software should work. Those things were also decided so that design part was also there. Then a couple of years, I mean, over a over a period of time people thought okay, we could do better. So there is a group of people and they came up with a Agile manifesto. And I mean we will not go too deep in the Agile Manifesto. People can Google it. But in principle, it was all about less documentation, less process, more about collaboration more about the working product. So if people didn't want to care about what is the documentation for the product, if the product is not working and it's not ready, then the documentation doesn't matter. And no matter how much process you follow, if you can't build it on time and deliver it to the customer, it doesn't matter. And then how do you collaborate? You should not have different teams and each team is working in silos for delivering a product. It's like you have to deliver a car, but everyone in the organization is working separately and they don't have the vision of the car. So everybody's working towards a common goal. So that's why people need to collaborate. So people from design team development team, the product team, the testing team, the release team, everyone needs to collaborate together to deliver the product, and that is what was important and that's one of the key features of the agile methodology, and what people currently are familiar with when we talk about a Agile Scrum. So, Scrum is one of the Agile methods. So it's one of the methods in which you can deliver software using the Agile methodology. Of course there are different methods in Agile and we will talk a bit about everything. But this is in essence the agile methodology.

Yes, absolutely. That's a really actually really good. Good sort of detailed explanation. Thank you Amit for that. But if I was to sort of going take a step back and see from what other methodologies there are, so one of the one of the another popular counter methodology there are is called waterfall technology. So another methodology, which is kind of encounter of agile methodologies, the waterfall method and what happens in water, the waterfall method as you as you just explained that what we're doing is we will have the design and the test and deployment etc. And one would come after the other we would finish one and then we would start the next one and then we'll deploy which is you know, kind of looks like waterfall as if you put it in a flowchart. Whereas the Agile is kind of like, you know, you take the feedback of, you know, sort of an MVP is one of the times, you know, minimum viable product, you basically just do the minimum customer requirements, meet them, put it in production, and then take feedback from customers and then go back and do a continuous iterative process. And that's what make makes Agile methodology. So, so sort of ideal for software development, I mean, waterfall methodologies is not necessarily a bad method, because there are projects which are very ideal for waterfall like for example, a construction project. You have to build floor by floor has to because you can't build a 10 storey building, you can't build the eighth, ninth and 10th before making were doing the foundation. So there are practical usage of different methods. But when it comes to software development, what we've seen is you know, there are bound to be bugs that are found. And then you know, the vision of the of the developer or of the project manager that how the software should be almost certainly will in some ways or another differ from the end user. And what we what's the ultimate objective to make the software product you know, usable or ideal or tailor made for the end user, they are our customers, they're the most important people to sort of cater for whatever we're working towards. So for that, agile methodologies kind of enables that in you know, kind of ingrained stuck in our working process and that's that way we could sort of come up with or continuously improve the software product. If we work in this way. That's why kind of agile methodologies have gained popularity as you know, software development has you know, became more and more commonplace in the last 20 years.

I think you hit some of the key points, which is like, responding to change and maybe delivery fast, because I think it's important in in the world where everything is changing so rapidly, you want to deliver software very fast. And if your competitor has launched a new product, you should be able to respond to that changes well quickly. You cannot take three months to respond to an advertisement or a price change. From a competitor you have to respond very quickly. So you have to build fast fail fast delivery to the customer. You cannot say oh I launch my product. In one year time or three months time, the customer will find some other product. So what you want to do is you want to release the website or any software product and then ask the customer for feedback and change that change the software based on that because sometimes what happens is people think they know what the customer wants. And we are trying to guess it and then we are trying to build it ourselves. And when we actually give it to the customer, the customer gives a totally different feedback that we never anticipated. And then you're like,Oh man !! we could have built the product in this way. Had we released it faster and got the feedback.

Yes….Now we have to go back and go through all of these processes of development UAT testing and deployment. So obviously that, you know, obviously delays the whole process.

Exactly. So it's like you want a login screen and you think about having a username and a password and lots of other things. But the customers start using it and they're like, Okay, I want single sign on I don't want this. And then you go back to the drawing board, you implement single sign on and then you release it the customers start using it more and more than they ask then you give them a new feature and they say no, I want this feature. Then you go back change it so I think it's that I iterative and respond quickly respond. So a change comes you respond to that. A feedback comes you respond to that. And every time you respond, you give a working product. You don't say oh it will come, Oh!! it will work that way. Currently it is not working but it will work that way. No customer wants a working product. Even if it is minimum, minimal functionality. They want a working product. They don't want something that works, oh!! it will work three months down the line. There is a button but it will not work now. So yeah.

Yeah, yeah, absolutely. And because of how customer focused it is, or, you know, sort of meeting the needs in real tower in good time. That's what makes this sort of working process so popular. So I mean, obviously, right, so. So yeah, we've talked about, you know, what Agile methodologies is on a high level, you know, to understand the overall sort of definition of it. But now, obviously, it's a lot more than just the definition. You know, there is a detailed working procedure with a lot of sort of different tools that make up the whole of the methodologies like a Kanban board, there are Sprint's and how each of the tickets are or each issue is handled and you know, how the work is allocated. So all of these things are quite, you know, detailed and all in a has their own sort of small flowcharts if you'd like or small working process that one needs to follow it. They aren't following agile methodologies. For me personally,

I haven't you know, I, I have sort of studied the agile methodologies and with all of these details, but in reality I've, you know, worked in various engagements in past where developers have been using as their methodologies but what happens is depending on the individual organization, some large some medium and some small scale businesses they are doing software development, they are publishing products into the market. And it feels like or what happened in my experiences is that practical thing to do is sort of tailor make the agile methodologies principles, and sort of pick and choose the ones that works. best for your particular organizational needs. And not only pick and choose a lot of the times but also sometimes sort of tailor some of the processes somehow sometimes amend them slightly so it matches the needs of your organization and things like that. So for example, you know, and a lot of a lot of the times people do call it a hybrid methodology where they kind of take the agile methodology as a as a principle as the core of poor working structure, but then they also add and remove various things based on based on the particular needs and but I mean, some of these things that always prevails is you know, one time which is MVP, I mentioned earlier, minimum viable product. This is something so in the beginning of starting a project or even in an ongoing project, you basically identify the success criteria or the customer requirements that these are the things that absolutely needs to happen. In the deployment and then prioritize them based on you know, the importance of each of these, say bug fixes or code enhancements or features that the new product will have. And then make sure that MVP so while working towards the MVP is done. So you don't do too much more than the MVP and, you know, every iteration, MVP required, you know, the minimum viable product becomes better and better, but you still work towards making the minimum viable product and then the next iteration, you take the newer features, but you still go with minimum, but every time you deploy, the requirements would increase. So the minimum viable product will be better and better every iteration. But we'll still be working towards always very minimum viable product that way, we're always a lot faster in terms of deployment and going through the whole lifecycle of development.

You're right, you're right, because I think that minimum viable product has to be a working product. As I mentioned, if you deliver a website with a button, the button should be working. Otherwise don't deliver. Hide the button. So it should be a working product. A lot of a lot. A lot of time people think MVP or minimum viable product is something that we just released to the customer even if it's not working. No, it has to work for the customer. And there are a lot of diagrams and memes on what MVP means. What customer wants and what actually is delivered and what actually MVP means. So we will share those links with the people. But yeah, as you mentioned, Agile has lots of different methods. One of the most popular method is the scrum methodology. Then you have Kanban methodology. You have lean methodology. You have extreme programming, you have many other things. I think for today's talk, we will focus on Scrum and Kanban which are the most popular software development methodologies, followed by most organizations, especially aware they have adopted agile. As Rinat mentioned, there are organizations that still follow waterfall or hybrid where they do part waterfall in part agile and it works for them. And every organization has a different product cycle and release cycle etc. So they adapt these process to suit their delivery cycle. So it's important to know that okay, this will not solve all your problems, but you need to understand how it works. Specially for a small company. It can work for a large organization to move very fast. It can take a lot of I mean, you have a lot of inertia to go that fast. So you have to overcome that inertia and it can work in small projects but not at the whole organization level. So there is a new concept called Scaled Agile. So how do you scale the agile framework or the scrum methodology from a project level to a programme portfolio or even at directorate level at all the way till the organization level that is also quite getting quite popular. How do you move the whole organization in terms of process and delivery? Everything in Agile way?

Yes, absolutely. And that's quite interesting. Because you say that because, you know a lot of IT companies or like sort of tech companies nowadays, have this sort of, I don't want to say luxury or have this kind of benefit to become to being an IT company only and not have a lot of the regulatory requirements. That commercial or sort of baggage. Yeah, a lot of my engagements in the past were with financial institutions and one of the things that is that prevent you know, adopting to Scaled Agile is the regulatory requirement compliance requirement that is imposed upon by the government or various other regulatory board and that kind of prevents them but yeah, tech companies you know, they could sort of adopt to it much more easily with a lot less friction. Going back to one of the things you said about MVP, I just thought about it and I didn't want to. So I think the key word is viable. I think a lot of a lot of people sort of put the key word is minimum. So focus on you know, minimum but I think MVP has to be viable. That's that's the part

that a lot of people get that wrong and a lot of times they think that they're doing Agile, but they're actually doing waterfall. So I mean, let's let's start with Scrum. Because Scrum is the most popular Agile methodology and

scrum has a lot of ceremonies. So we call them scrum ceremonies. And those ceremonies are important for delivery and we have ceremonies. You have a product okay. So say you have a product I want to build a website and that website will have a login functionality. It will have a shopping cart it will have payments. It will have user my account it will have a shop for it where you can go and browse without logging. In, etc. And all these are different features for the website. And I would build this website so there is a product owner and the product owner decides how the product should work based on

customer surveys. Organizational needs what the organization wants to sell, design, etc. And the product owner then comes up with stories or features. Okay, my website should do this. So when a user goes to the website, they should be able to see this when they log in. They should be logged in with the username and password. Once they're logged in, they should be able to add something to the cart and checkout with their personal details. If they're not logged in, do this do that. So that's a feature and he breaks it down he or she breaks it down into multiple stories. Stories that become popular or issues have become popular with JIRA, which is a very popular agile tool for delivering software. So a lot of companies now use JIRA for delivering software in an agile way. So the product features have been defined. So that's in the product backlog. No one is doing any design, no one is doing any development. Nobody's doing any testing. So once that product backlog is created with a lot of features, then you go into sprint, so sprint is a short period, select sprinting for a race, you run very fast for a very short period. So similarly you develop very fast for one to four weeks maximum ideal spot is two to four weeks, one week is not enough. So two to four weeks is the ideal spot. So where you have development, now two to four weeks doesn't mean or I will design first then I will develop then I will test so then it becomes waterfall. So you have to ask that when the feature is ready, you test give it back to the developer. So coming back to the sprint. So you have the product backlog with all the features and everything and then you have the sprint. So what goes into the spirit. So you have a time boxed period. So it is fixed. You cannot go beyond two weeks. So you have to create the minimum viable product in two weeks time or four weeks time. So in order to create that you can only commit to stories that are feasible. So you ask for people's opinion. Okay. Developer, okay. Business Analyst. Okay. Tester, how much time do you think it will take to build this? Okay. business analysts will say first in order for me to define it for the developer it will take two days. developer will say to me for me to create it, it will take half an hour, tester will say but because I have to test it on multiple platforms, it will take me another two days. So this feature which you think should be done in one day, will actually take four days. Okay. So that story point estimation and now people are collaborating. It's not like developer will say give an estimate tester will give an estimate later when the testing cycle comes and a business analyst will give a separate estimate. So I mean, so you have the product backlog and you have people who have estimating. So you have the business analysts estimating you have the developers estimating and the testers estimating and they are all test estimating at the same time. It's not like in waterfall, that okay, when you come to development, then you estimate when you come to testing, then you estimate and we don't know how much time it will take. So now everybody is collaborating, everyone is working together and everyone is telling okay, this is how much time it will take. And that there is a scrum master. And lot of people confuse scrum master as to what is the role of a scrum master. I'll explain it a bit later. But okay, so you have the product backlog and you have a sprint. For the sprint you need to have a backlog and what backlog means is features that need to be developed. Okay, so those features need to be developed in a way that can fit in a sprint. So I in some sprints, I'll have 10 stories in some sprints. I'll have five stories because they are bigger in size. Okay. And all the stories will lead to a MVP in the end. So, so you have the product backlog which is the main product then for every sprint you have some backlog and you feed those stories into the sprint you add it to the sprint then you start a sprint. Wherever the sprint runs, you have a scrum meeting every day a daily scrum. So what it is everyone is talking. What did you do yesterday? What are you going to do today? Simple as that.

Okay, so that means that whatever you have the work that you've done yesterday, you are going to tell to the team and the work that you're going to do today you're going to tell to the team and if there are any blockers you tell to the team, and then there will be people who will help you guide you fix it. So that's a scrum ceremony once you finish the sprint, so two week or four week period is over. Then you have a sprint review. What have you delivered? Let's review that. What have you built? Let's review that you said you will build a MVP? Have you actually built an MVP? Let's review that. So that's a sprint review. And then every sprint retrospective, that retrospective is nothing but okay. What went well? What did we do good, what went bad? What we could have done better? Things like that. Okay. So that's the whole this encompasses all the scrum ceremonies. So when people talk about the daily scrum meetings, the sprint retrospective, the sprint review the sprint planning etc. So when we are estimating that it's called Sprint Planning, so you plan how much stories will come home a story points will it take etc. And all that comes into the planning phase, and then you start the sprint? Then you finish the sprint with the retrospective and then you start the next sprint. So next set of MVP’s and that's how sprint or Agile Scrum works.

Right, right. Okay, that's actually a lot of information a lot. Of sort of a lot of jargon. So let's review what we just said. So there in terms of roles, there are a product owner, the scrum master. And then there are

the development team which is the which consists of the business analyst sometimes, or the product owner acts as a business analyst. Then you have the developers then you have the testers. They're all worls there is a development team. Right? You can call it

so product owner and then there is a business sort of sort of, I usually came across the term more SME, like subject matter expert.

So normally what happens is the development team and the testing team, they are more technical. And the product team is more feature oriented so they don't understand the technology and the people who understand technology. They don't understand the feature. They just said okay, I want to build this what is the requirement? So someone else translate those things, so someone takes the feature, and then tells how it should be actually delivered in terms of the technology so I want to create a user, a user should be able to log into the website. So it means I need to have a username, I need to have a password. I need to store that password and username in a database. I need to store the password as a hash. So if the database gets hacked, they don't get the actual password. So all these technical requirements will not be written by a product owner. So someone else translate that so that's where the business analyst comes. They will say, Okay, fine. Okay, you want someone to log in, but behind that login, you have to do all these things. You have to create a database you have to store the username, you have to store the password, you have to ask the people to change the password frequently the password should match certain criteria’s etc. If you enter the wrong password, you should get this error message etc, etc. So all those technical things will be then passed on to a developer and the developer will then follow that and then build it in a story you will also have an acceptance criteria, that this is something that has to work and a tester will then verify or validate whether the product that has been developed or the story that has been developed meets the acceptance criteria. So a product owner will say, okay, user should be able to log in user should get an error message, user should be able to log out. That's the acceptance criteria. tester will verify all that and then he they will do exploratory of okay. What is beyond this? Can I actually log in without entering the username and password? Can I just enter the username, press enter without a password can I log in? So those kinds of exploratory things, so those are addition on top of the acceptance criteria? But the acceptance criteria has to be there.

Right ….Right….Right…. Okay, so that's, that's, that's another piece of the puzzle as well. So in terms of in terms of role if you've kind of said who are you know, how many roles there are and who does what in a role and then we moved on to the each individual tasks and which were kind of managing in a sprint. So if we review that part, so there is a main product backlog, and then there is a like a weekly sprint,

maybe weekly, or bi weekly or two weeks or fortnightly or say a four week monthly Sprint's

depend depends Yeah, yeah. So on that period, you have picked out you know, you have prioritized list of tasks that are in the in, you know, that are sort of in the left hand column if you'd like and then the development team you know, takes on each of them they're sort of assesses how long they will take estimates, you know, the tester, the developer all estimates, and then it moves on to from column by column, and I think this is where the term Kanban board comes in. This is the board itself sort of holds all the stories and tracks the progress of

So Kanban actually has just three columns scrum in Scrum, you can have multiple columns. So let's finish about Scrum because I missed one of the roles which is the Scrum Master.

Yes,

that is which is something that people get confused with a lot. So Scrum Master is basically telling people to follow the agile methodology. That's it,

Right.

Are we following the Agile methodology of delivering software. That is the role of a scrum master. Scrum Master is not telling you Okay, deliver that feature, but develop that feature? No. Are you following the agile methodology? Have you do you have a product backlog? Are there enough stories in the backlog? Do you have a sprint backlog? Are there enough stories in the sprint backlog? You said that you will deliver it in two weeks time? Are you on track to deliver it in two weeks time? Do we have to change it from two weeks to four weeks then? Are you doing the sprint reviews? Are you doing the Sprint Retrospective so Scrum Master has to enforce people to use the scrum methodology.

Right Right…

once a scrum team is capable enough the Scrum Masters role is not needed. They move on to a different scrum team. That's the role

I see….okay, I didn't realize that actually. That's actually quite good to know. So Scrum Master is also the person who would lead this daily stand up call so the huddle

They don't have to lead. It's all about people collaborating. There is no leader. There is no project manager there is. It's about us, not about him or her. It's about we. So when Scrum Master says Scrum Master is actually not leading the call the scrum master is just telling people okay, are you following this methodology? You actually need to come and together and then ask questions. Okay. Let's agree that we will meet and so and so this time of the day, and let's agree that on this time of the day we will talk about these things and it should not take more than 10 minutes or 15 minutes so we don't waste everyone's time in large discussions. So that's what and if it takes more than 30 minutes a scrum master will say guys, we said that we will discuss it for 15 minutes. Now you're taking 30 minutes. Do you think it's a good use of your time? That's what the scrum master is there. The scrum master there is an observer to see whether you're following those principles, or are you just wasting time?

I see. Okay. Okay. That's, that's a good way to look at things. Really good perspective, because of course, yeah. You don't want to, you know, when developing, you know, when working on a creative project, we don't want to be sort of burdened by micromanagement, but it should always be like a collaborative, you know,

exactly.

Where there is a lot of sort of internal sort of incentive or motivation rather than….

It’s like a bird's eye view of the whole project and whether it's working the way we want it to work, because lot of times people don't have a bird's eye view and the scrum has a bird's eye view of what everything is happening behind the scenes. And then in the scrum, when we deliver the sprint, the sprint can have multiple columns. So when you talk about columns, actually, it's which stage of the delivery it is, so it could be in progress. It could be in backlog, it could be blocked, it could be code review, it could be testing in QA, it could be it could be done. So there are multiple stages. So that's what defines the columns, the work, you move it across different stages. In Kanban, you have just three stages to do in progress….Done…. And you can name it whatever you want, but you have just three columns. So it means you have to turn those columns quickly. So in Kanban, you always so the scrum board will be a different from Kanban board in this way. A scrum board will have multiple columns. It can be 23456…10. Maybe, of course it's not ideal, but yeah. And then in Kanban board, you will have just three columns in progress, to do, done….sorry to do, in progress, done. what is there to do? Okay, can we move some stories into progress, so yes, let's move them and if the progress is done, has it been tested? Has it been verified, done. So there is no in between of code review this that it's all very simple and straightforward. So that's Kanban.

Right….So what would have what would be in the additional columns in the scrum board?

As I mentioned, so you will have code reviews you will have in QA. You will have done the stories done. So instead in progress, so in progress would be for developer then the progress would say Okay, let's go to Code Review. Then let's go to in QA, so or to QA, it could be also blocked. The story needs some more information or the story needs some more data input from product owners or it can't be done etc. So, Blocked. then you have done. it is done. So you can release it. So things like that. So you have multiple columns. And you have based on the project, you can define the columns, those are flexible. And when we are talking about all these columns, they are very specific to JIRA Software. So let's just clarify it for people who are there are listening, that JIRA is the most widely used Agile Scrum or Kanban tool in the world. And they use multiple columns. Of course, there are different tools and they also use but we're talking about columns Trello. Trello is quite popular. So a lot of people use Trello. It's all completely web based and you can have multiple columns and it's it works on the same principle you can manage, not just software delivery, some people use Trello for the day to day life as well and activities. So

Right…okay...I was gonna mention Trello actually. Oh, yeah, yeah. So yeah, I mean, I was gonna mention Trello myself as you were talking, it is such an amazing tool and it's free. So for the for the audience, who doesn't know already trello.com I think or trello.com is a free Kanban board webpage. And they have all kinds of feature all available for free. And for any of your personal projects or even if you're, you know what, you know, starting up as an entrepreneur with a new sort of tech company or, or an idea that you want to sort of track the progress of that is a really good piece of website that you would really enjoy doing the Kanban board on. And it's not just because it's kind of on board but it's a really good tracker of your progress and all the things that you have to do it could just be used as a task list to do lists in for your own personal things that you did. So yeah, I'm not sponsored by them because they are free. But do to do check. Check that website out is a powerful website.

Yes. So yeah, so we talked about the scrum methodology and we talked about Kanban and those are the two main one popular there are other mix. Other methods are hybrid method. Bimodal where you have Waterfall and Agile so you have first part waterfall, second part agile. Then in hybrid, you have waterfall and say I mean, it's a mixture basically hybrid. So you can you can understand like okay, there are different methodologies and different ways to deliver so that and you can deliver it. So I think that's the essence of agile, they move fast, they fail early. Have a minimum viable product, make a working product for the customer and don't, I mean, you have to document things. It's not like don't document but the working product is more important than process and collaboration is key. And I think that's what the agile methodology is all about. And that's what Agile is all about and the word agile means be quick,

adaptable. More efficient. Yeah, absolutely. What you said is absolutely correct. And one of the thing is, I mean, this reminds me one of the way kind of I kind of made a hybrid model based on you know, project I was working in instead of Kanban board I had created just to like, sort of tracker in Excel, where I had four different work streams. So it wasn't I had to, rather than creating four Kanban boards and tracking everything separately because there was a lot of resources or people working on it. Were kind of interchangeable to these different projects. So I sort of created four different work streams in an Excel file. And you know, the main thing about it is accountability, right. So you know, whoever is given whichever story or task to do, they take ownership of that and I've sort of just, you know, listed out the tasks and listed out the status of them rather than going column by column just go in the state you know, in the Status just having a rag status red, amber green and kind of like a deadline column, etc. So, yeah, you can absolutely make any, you know, the key thing is to have visibility, transparency, you know, of what you're doing to your team members. So all of everyone can see what everyone else is doing. That way no one loses vision of the final product. And another key thing is accountability. So you know, you don't have to be pushed by the management or your senior manager or whoever is so he won't be micromanage, but you will have accountability to the rest of the team. So that gives you more of an incentive that yeah, this is my task and I want to do it in my deadline because otherwise everyone else is seeing and also, there'll be people waiting for you to finish your tasks. For example, the developer has to develop before the tester can test so these things are all kind of comes together. So as long as these key requirements are met, you can design your own Kanban board for all intents and purposes, but yeah, can when was designed one or the scrum board is that is a very popular established method of tracking tasks. So yeah, designing if you absolutely have to, but there is a very working effective model that you can follow, which is the Kanban board. So yeah, that's a lot of information. And Amit, you've taught me quite some things as well. I you know, I had gaps and pockets of unknown information in this but it was it was actually good to listen to you cover a lot of sets. And yeah, I feel like I have, you know, have more of a structured or a more fulfilled knowledge on this methodology. And hopefully our audience has the same sort of impression.

Yes, I think. I mean, thanks a lot for selecting this topic. And thanks to the audience who requested for this. We would have not thought about talking about this topic, but thanks to you guys. We actually decided to talk about it and enlighten our viewers and listeners. And the important thing is to realize to take back from this talk is that it's all about delivering something. And in order to deliver something, you need to have some tasks and people need to work on this task. And how you work on this task is all about organizing yourself. And Agile is one way to organize within an organization and you can organize yourselves in different ways. And this seems to be a very good and fast way. Currently, and in the future we might come up with even a better way. We talked about robotic process automation so all these processes that we keep talking about, we can automate that. So in the future of software delivery, you can we can have better methods but as of now, this is one of the best methods to deliver something quickly. And that's what is transforming the software world. So it's very good to know about this.

Yes, absolutely. So yeah, I thank you guys, the audience for listening in. We had a lot of fun and I've learned a lot from this talk. Hopefully you guys did too. I hope to see you guys again in our next talk. And please do feel free to reach out to us in various methods in you know, listed in the description. Tell us what you would like us to talk about next or any feedback or suggestions from all the talks that we've done in the past. If you'd like us to reach out to any particular sort of, you know, tech, notable person, do let us know and we'll reach out to them and hopefully can bring them as guests. So, yeah, thanks again for listening in. And that's all for today. Hope to see you guys next week.

Thank you, everyone. Bye

bye.