 We are here for this presentation, choosing the right agile methodology for your Drupal project. My name is Prabhat Sinha. And I'm here along with my colleague, Shani Mampi. So next slide is a simple introduction about us. I'll introduce Prabhat. Prabhat has been working in projects and projects for the past eight years. In his free time, he can be found jogging. And just socializing at the Lake Park. He lives in India in New Delhi with his wife and two kids. Yeah. And Shani has been managing product and project delivery since 1999, long while ago. And after work, you can find her on court, suiting hoops with a local Nepal league. Shani lives in a suburban city in Israel with her husband and four children. And it is a good thing that Shani has practiced a scrumman. She has been practicing since last three, four years. So she'll be able to give a more focus on all methodologies. So here is the simple agenda of this presentation. We will run you through what is agile, a simple intro, because we know all of you know about agile. Then we will run through agile frameworks, a scrumman. I think these three are widely used agile frameworks. And then we will also discuss about extreme programming, lean, and feature-driven development. And we'll see how we can also use this for triple projects. After that, we will do a simple comparison of all the frameworks, which we have included here. And last one would be the Cinefin framework, a popular decision-making framework. So first, what is agile? So as you all know, that agile brings more flexibility. It gives vetis to individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and receptive to change, responding to change as soon as possible. So here are the 12 principles of agile manifesto. And it is more about flexibility, team collaboration, sustainability. MVP is in the focus, like minimum viable product instead of documentation only. Simplicity, so this is all about it. And but as agile as a methodology only, you can't work with agile, because it doesn't give. So there are several agile project management frameworks which are being used in a triple ecosystem. Scrum, Kanban, Scrumvan, or as I said, are popularly used frameworks. Then we have extreme programming, lean development, and feature-driven development. So in the next few slides, we will discuss about all these frameworks. So it is over to Sani for Scrum. Thank you. Thank you for that. Hi, guys. So OK, we're not going to go into the details of what Scrum is. We're just going to take it from a high level beyond assuming that everybody knows. So the one thing I do like is that Scrum, the word Scrum, comes from rugby. And most of us know this. And this definition of it I found in the Oxford English dictionary. And it's just something that I really like about it. An ordered formation of players, I think, really represents the cross-functioning team and if the Scrum is used to restart play, correlates to the sprints that we have at each point, in which the forwards of a team form up with arms interlocked. And I see this as very much the Scrum team, the PO and the Scrum master, linking arms, going together and going forward, heads down, representing the no distractions that we have in Scrum, the objective to be that the team has no distractions, and to push forward. Scrum doesn't work unless the whole team is, well, it's gone. I don't know how to make it go back. It doesn't work Scrum if the whole team isn't on board and focused on going forward in the same direction. The part about an opposite side doesn't really take effect, but that's the definition of Scrum. Scrum in a nutshell. We have many processes and tools that we use to work through not just the sprint but all the preparation for the sprints. We have the sprint planning, the backlog refining, the demo, the retrospects to learn and to constantly maintain going forward. We have the product backlog, Scrum boards, different tools that can or cannot be used, it's optional, during the sprints. The team, product owner, essential part of the team. Without it, I do see Scrum as being a bit of a problem without a product owner. A Scrum master, as we know it's fairly debatable whether a Scrum master is actually required during a Scrum but the objective is to make that person irrelevant almost but a Scrum master especially to start off with and the team. Well trained, specialized, self-managing, communicative, ability to make decisions, common goal and self-improving. All the things that the team needs to have, again, putting together that common goal and achieving it. The requirements for a Scrum to have a clear vision. There is an ability to have adaptability during that clear vision but once the Scrum starts, sorry, once the sprint starts to stay on that goal, no distractions to the team during that time and to stay focused. It would help if you have a backlog for at least two sprints. That way, there's a constant life cycle and always moving forward. The objective being to have an MVP, sorry, a PSP or MMF for the end of each sprint something to show this is what the team did. I'm aware this is difficult at some points, especially at the beginning but always to work to that goal of having something to demo at the end of the sprint. When to choose Scrum, where the vision's clear, without, and I say this loosely, the vision has to be clear of where we're going, a long scale, like what is the objective in three, four months' time to get there. Flexibility along the way. Agile is designed to adapt for that flexibility. That is available in Scrum. Teams can be changes but once the team is in motion during the scrumps, during the sprint, leave them. We can make changes as we go along but not during the sprint. Just keep on going and the changes can come afterwards. Again, Scrum projects can change direction as long as the product backlog is maintained and groomed. So constant change, constant going forward. Those are the main things I see in a Scrum project. The team needs to be onboarded and committed. Stakeholders have to have the projects as a priority. It doesn't have to be their top priority but it does have to be in their schedule that they are able to answer questions, be available to think about the project and if there is a change to be done, to be available to give that change and give that feedback so that the team can continue to progress in the right direction even after a change. The team obviously has to have the skill set to manage the project. So it's an essential and communicative. I will add in here, we work in Accelerant and we are a remote team. I'm based in Israel. Prabhat is based in India. We have people in Tokyo. We have people in the UAE. We have people in the States and a few other places. So, what? Australia. Australia, Australia. So, communication is essential and doable. I'm not going to go into the tools. There are enough tools that the team can maintain. Communication, there's no reason that should stop for whatever reason, co-located or not co-located. Communication is a key and we have proved that it doesn't matter where you are, it can be done. The output is to show something at the end of every sprint, have something to take back to the client and say, the stakeholders, this is what we did. You don't like it, that's fine but this is what we did. The team gets a full sprint, this is what I mentioned before, without any interruptions, no distractions. All distractions, project backlogs, things like that, part of the schedule, but when it comes to the actual sprint work, no bugs to be fixed that aren't in the plan, no changes, it's a short period of time, we'll work it out afterwards. Anything can be subject to change and that's where Scrum really lives up to his name. Want to take Kanban? I think, oh, next one. Oh yeah, sorry, my mistake. Okay, when does Scrum turn into Kanban or Scranban? The sprint scope frequently changes, priorities change, emergency situations, clients not responsive, many different reasons. It's a sign that maybe Scrum isn't the right way to work. Maybe the team's okay with Scrum but the stakeholders might not be. They are a contributing factor when choosing the right framework for which agile framework and that is one of the things that is easily identifiable at the end of a sprint especially that maybe Scrum isn't working. The scope isn't clear or blocked. Again, the whole point is to be able to have a couple of weeks sprint backlog in the backlog and without that, it means there's no scope and we have no backlog, there's no scope. So we need to know as a Scrum master, you need to know what you're gonna be doing next. So one or two steps ahead of yourself. If you don't have that visibility, then Scrum might not be the right way to go. Basic Scrum rules aren't enforced, lack of communication, lack of retrospects, live and learn, learn what your mistakes are, improve each time. The team should become on together. I think a major part of Scrum is the ceremonies. And team is not dedicated actually. They're multitasking and you want them to focus on particular tasks or items. Yeah, that would happen, especially if things are blocked or the scope isn't clear, they get distracted. Nobody wants idle talents, sat around doing nothing because scope isn't ready and then they move on to another project, then their dedication, it fluctuates and then again, Scrum can fail. Release start to be, releases are ad hoc. You're just releasing whenever you feel like it, whenever you feel from a development perspective, it's relevant, that's not Scrum, okay? No clear distinctions between project and product. It's a conflict between the PO and the SM. There's a reason those two people are members of the team to have the different aspects, one coming from the business side, one on the project development. Doesn't mean the Scrum master can't also be a PO but not in the same project. Addressing maintenance and support work. Given that maintenance and support has different and changeable priorities, Scrum also won't work because it will affect the content of the sprint each time. Team dedication is erratic. When you set what you're doing for the sprint, it is what you need to accomplish, it's what the client is expecting at the end of the sprint. Without that, with the team not dedicated to achieving those things and that means they can work on other projects, they can work percentage wise but they have to have the dedication to the project in order for it to go forward. Thank you, Sunny. So I would introduce a word, Kanban. A bit Kanban, as the name suggests, it is a visual signal and basically it is a Japanese word which says that like card you can see. And Kanban was first introduced by Toyota for the just-in-time production lines in the 1950s. So the most important part of Kanban is this board. I think this is pretty simple to work upon and we can simply manage our tasks here. Like we can put our stories here in this column. We can also put some items in to-dos in progress. Important part is that we can limit work in progress items. Like in progress, we can limit like there may be three, four items. First we will finish those or move it to the next column and then we'll pick another stories from the product backlog. So that really helps even we are practicing it for our support project and accelerant and we are pretty happy with this process. So I'll move to the next slide. So Kanban in a nutshell, like citizens are same as a scrum, you can say like meetings on a daily basis. And basically for those who are converting from a scrum, they go for it, product backlog, the debt. So stories are here. You can pull from here. So you can see like which stories are available there and you can pull out from there. So that would be your product backlog tools. Kanban board, it is being used extensively as a tool and WIP limit as I talked about it during introduction. So limiting the amount of WIP really works in a prettiest manner. Like we can limit the things and we can ensure that things are first finished and then we are picking other items. And team basically, they are technical teams and as needed Kanban is also extensively used for support projects in Drupal ecosystem. So basically front end or back end developers who are required for that particular project are picked for it. And the project philosophy actually Kanban does not prohibit chins, but neither it prescribed for it. So it is not speaking about chins a lot, but yeah, it is receptive to it. If you want to make changes, if you want to adopt changes, then it is fine. Kanban encourages making incremental changes. Like you can make changes as and when required so that you can avoid drastic decrease in productivity. Similarly, small course corrections are also just easier than altering the complete process. And it focuses on the end-to-end project like vision is on the end project like how soon we can complete the project. So now when to choose Kanban. So basically Kanban as I said is used for support and maintenance project widely. Like whenever you are running support you can keep tickets and your backlog items. You can pull tickets from there. You can pull them into work in progress. You can then move it to the testing and so on. Or then continuous flow. Whenever we need a continuous flow of work items, we can pick Kanban as our product methodology. And when the project requires the maximum flexibility and frequent chains of priorities and scope, then again we can pick Kanban. Openness and like things are open. Everyone can see that board and which team member is working on which item. You can definitely look into that. Ad hoc release required. When release dates are not known actually. Basically for support projects you never know. Maybe one ticket takes two days for you. One ticket takes simply a few hours for you. So best upon that. Now it is time for a scramban. So it is a mix of scramban and Kanban. Okay, so scramban actually is one of my personal favorites because it takes a lot of the things that I like personally in scramb. And things that you have in Kanban and it equals scramban. This isn't officially defined anywhere. It's still unclear. But in my opinion, you're working in scramb. You need to adapt it scramban. You like certain parts of scramb. And you just want to have ad hoc releases or anything like that. Then this is your solution. So it's still in definition. It's in the definition stages. But it's gonna be anything you choose that isn't 100% Kanban and isn't 100% scramb. Okay, and this is actually not unique to software development. There is a lot of things about using scramban in the home with your children and things like that that actually has a lot of interesting ways of doing it. So scramban in a nutshell. Again, I really personally, well, I think it's very important, the communication. So a lot of times you'll keep things up like the stand-ups, daily communication, speaking to your team, knowing what they're working on. Technically, that makes it a scramban and not just Kanban. The retro to enforce self-improvement, team improvement and reviews. Again, we can do ad hoc reviews and that's cool. But you can also plan the reviews. I personally am working in a project that was pure scramb for about the first five sprints. And the last seven sprints, we moved over to scramban. We used a Kanban board to see where things are at. But we kept our demos with the client. But due to issues of response from the client to close all the UAT items before the end of the sprint, the client wasn't responsive. Getting clear information on that for the backlog, the client wasn't responsive. Blaming the client is their priorities. But this meant that we could no longer keep scramb. We kept having sprint two was still full of UAT tickets. So we were failing in scramb, but the team wasn't failing in progressing forward. And so we just moved it to scramban, adapting. That's the main thing with agile is just to keep in the name of adaptation, learning, and keep moving forward. So with the tools, I do use a Kanban board. In a few cases, I don't do ad hoc releases. We keep it structured in the same way that scramb is. But you can choose to do the Kanban way and ad have ad hoc releases. Continuous flow. Even though we do define when the sprint ends, because we have a demo in the code we have, we do say it's sprint 11, it's sprint 12, we do have that just for structure. But technically, we do work on a continuous flow. Sometimes we take less priority tickets due to high priority items not being blocked for whatever reasons. Again, unlike scramb, the team pulls the ticket. So that means although we didn't define it at the beginning of the sprint, they just pull the tickets when they need them. So again, contradicting to scramb where it's predefined at the beginning of the sprint, what are they going to work on? No, no. We do grooming ad hoc when the requirements come in, in the case I have in mind. There's no reason not to do planning. If you have the information and you can do a plan, even if you say, these are the next priority tickets, I would love to do planning in this project. You see, the problem with the way we don't define, we don't mark the end of the sprint by, yes, we have a demo, but the end of the sprint is on a start of a sprint is on a Monday. So we just start the week. Yes, guys, it was a new sprint. So any merge requests need to have the code so we know when it was done, but we just have priority. We don't have, unfortunately, in this case, we don't have the ability to groom them and be ready and say, this is what we're going to accomplish in this day. We don't even have that visibility. We're living hand-to-mouth with regards to development. So this allows the flexibility to do that. But personally, I would love to do some planning meetings. So that's, but you can. Again, there's no reason why you can't and choose your different reasons to choose that part of scrum yes, this part of Kanban yes, that part of scrum no, et cetera, et cetera. That's why it's not defined. And I wonder if it'll ever be defined because it's just take what you know of both and see how it works for your team, for your projects and move forward. Grooming on demand. We do grooming on demand again. This is a perfect example when, only when we get things unblocked by the client can we do the grooming. So we're stuck until then. Again, the team shouldn't be idle, so they pull the tickets that they can work on. Again, like scrum, it needs to have a cross functional team. I do see this as a, I didn't actually put it in. Oh yeah, it's here. I see the top part as the scrum and this is the ban, so scrum ban in most cases. But again, adapt it to what you need it to do. The project philosophy, again, it's the same agile philosophy. The roles, the work processes, the better flows and the flexibility and all under the title constant improvement. So as long as we're constantly improving and we're agile, then we're still working in the agile methodology. When to choose scrum ban. So when anything is unstable and you can't maintain scrum, basically, and you find the solution to not being able to maintain the scrum within Kanban. We have scrum ban. The project is not flexible, hard on that. When the project requires the maximum flexibility and frequent changes of priority. So client says they want one thing, the next day they want something else. With scrum, we would close the door and say no, talk to me in two weeks or three weeks. With scrum ban, we can stop. With Kanban, we can stop. Therefore with scrum ban, we can stop. The goals are not clearly defined. Again, not allowing us to plan. Constantly evolving of the product, which is great. This can actually, involving of the product can be also done in scrum quite easily. But if it evolves too quickly, then it will move out of scrum. And the sprint planning isn't happening. Another reason scrum would fail would be management not involved. The whole team could be working with scrum. But like I said, with the client or the stakeholders having it as a priority, if the project is a priority, if they don't scrum will fail. And we won't be able to close off sprints cold heart. We've finished it. The client agrees with it. There's no issues. And with scrum, you can pour it over to the next so-called sprint. Any Kanban project that you're working on that needs a slight bit more structure will also fall into scrum ban because you'll be doing the opposite. You'll be working in Kanban, but you need the planning. You need the daily stand-up. You need the retrospect. So technically that would be a scrum ban. And the team isn't focused. Scrum will also fail. If the team's not focused to do what they want to do, what they need to do for that sprint, then scrum won't help. Extreme programming. Yeah. So extreme programming is really a lesser-used framework for Drupal ecosystem at least. But yeah, let's discuss about it. So this is another agile development framework and it is focused more on software quality and responsiveness. It is a code-fast approach. So code is in the forefront and we also do testing. Testing is also on the forefront of extreme programming. It has also used a few software engineering methodologies like test-driven development has been used extensively for extreme programming. And there are a few other elements like peer programming, integration, collective ownership, and several other things. We will discuss on the next few slides. So moving to the next. So as I said, extreme programming is a code-fast approach to software delivery and emphasizes on four basic activities like coding, testing, listening, and designing. So here in the diagram, you can see coding is the main part of this. We first code, then we go for other things. We also do peer programming. We do refactoring of codes. So sometimes this is also said that probably extreme programming is not that popular because of this code-fast thing here. And again, as I said, that extreme programming brought testing at the forefront of delivery process, like test-driven development and automated test-driven development, and practices like automated testing, refactoring, continuous integration, test-driven development has been used extensively in extreme programming. So here are advantages and disadvantages of extreme programming. So advantages are peer programming under XP, helps in writing better code because two programmers are writing on the same piece of code. So definitely your code is going to be very much effective and productive with less bugs into that. Again, increased team accountability. So every code base is given to the team. And team is responsible for managing the quality on that. Similarly, extreme programming manages risks in a better way because we are working on the code in a better way. We are maintaining quality on that. We are also using test-driven development. And apart from that, we are also doing continuous integration. So iterations here are mostly of one week and it is integrated into the main code base. And it is easy to accommodate changes. So another advantage of extreme programming like it is very much receptive to changes. At any point of time, changes are accepted and they are integrated into the main development process. Now let's discuss about the disadvantages. So detailed planning is required since the inception due to changing scope. As I said, that it is very much receptive to changes. So at any point of time, if changes are coming, then we have to estimate how much extra time it would take. So right from the scratch, we have to plan in a way so that we can accommodate changes. Or maybe we can also let client know right since they start that whenever you will come with the GINs request, we will let you know about the estimations and all. Then XP does not have a set measurement plan or quality assurance for coding. So apart from all this software engineering method laws is like continuous integration and all, there is not a set measurement plan. So that is why sometimes extreme programming fails. Pair programming may lead to too much duplication of code and data. And apart from it, it also takes efforts. Like two programmers are working on the same piece of work. So it means we are spending more time and doing a piece of the work. So XP is more code-centric than design, which may cause UI-UX issues. As I said, that code is in the forefront. So UI-UX issues are usually ignored and which may create a chaos later on. So XP in a nutshell here, process and tools, pair programming. It is an important fact of XP, basically. Release plan, iteration plan is one plan which is used there, where we plan about iteration, the sort iteration, usually it is of one week. And we plan like what features or what items we will pick into that iteration. Then project velocity, it is measured at the end of the iteration, like how much velocity we can achieve. Then iteration, as I said, usually it is of one week long. Practices, we use test-driven development, continuous integration, collective code ownership. Team size, usually five or less. And team members are trackers. Customer is very much important here in extreme programming and it is equivalent to product owner in a scrum. So customer is the one who assigns tasks to team members. It is not like a scrum that team members are picking tasks their own as per their convenience. Rather, customer is assigning tasks to all team members. Then few other team members are programmer, tester, and coach. And again, as we discussed, the project philosophy is code first, refactoring has done so many times. Simple designs are used, because focus is more on code and spike solutions. So now when to use XP? So basically when we have reached up to a maturity, most of the time what happens is we have done most part of the coding and we have to move into the complicated part of coding where a lot of focus and quality is required. Then we can move into XP at that point of time. Similarly, when we require maximum flexibility and frequent chance of priorities. Then again, we can use XP. Multiple releases per week or per day. As I said, that iterations are very short and continuous integration is promoted here in extreme programming, so like that. Whenever we want to have multiple releases, we can use it. Have many unscheduled releases. Same, like when we don't know about the releases, we are just working on the tasks and items. And once it is done, maybe we can integrate it with the code. And when we have less cross-functional teams. So now it is over to Sani for lean development. OK. So lean development was adopted in 2000. There's books on it as there are on everything. The lean also works based on a kind of Kanban board with different emphasis. The emphasis changes to different priorities. There is still the objective to have sustainability and smart development and obviously success. But the main difference is that it's more focused on... Hold on, I'm pretty just going to... The values are ROI specifically. Yeah, it's very good for startups because you build less so to what you can do, but what will provide you the fastest and the best ROI. It's mainly spoken about for startups, but it can be applied whenever, whenever the focus is to get the ROI on what you're working on, and less priority on a whole product in the end. So it's a small increments of success, I think it would be a more fitting way to say it. Still works on the cross-functioning team. It doesn't have any best practices, technical practices defined for it. It's matrix, it's external matrices that what will give us the money back on what we're working on, not what can we resolve, what can we do, it's more from a business side. The business wants to see money coming back for the development that's done, and priorities will be according to that. In a nutshell, again, you can apply daily standard meetings, communication is just always essential in agile and reviews because so that we can learn and improve. The tools, the cumulative flow, excuse me, cumulative flow, diagrams, visual controls, and the Kanban board. The Kanban board, if we go back, it has different, you have the problem, you have the solution, you can have in the solution how much it's going to cost to do that solution. Obviously that is needed in order to measure the ROI, the key metrics, and the cost structure. So it's a different, the board looks the same, but the titles are different. Yeah, it is more business oriented. A lot more business oriented, coming from above. Iterations, again, can be according to what you're planning. There's no set rule, there's no three weeks, two weeks. As need be, it's also not ad hoc, as you want. The team needs to be well trained, specialized, again, all the things that agile has seems to be constant, well trained, self managing, and communicative. The key principles are that it eliminates waste, it creates knowledge, it defers commitments, fast delivery, and respects people. Respect people. And optimization as a whole. So that's basically leaning in a nutshell and over to Pradhat. So last one in the row, feature driven development. And it is basically a software development process which has feature in the forefront, like we do everything based upon feature. And feature driven development was introduced in the year 1999 in a book named Java Modeling in Color with UML. So as the name suggests, feature are an important aspect of feature driven development. And they are primary source, like similar to user stories in a scrum. We use feature to track things even in the product backlog or whatever backlog we make there. We use feature there. And feature is a small client valued function expressed in the form. This form is important like action, result, and object. So this is a simple diagram of feature driven development, how it works. Like initially, we develop an overall model, architecture-based framework. It shows here, and we build a feature list here, all list of features so that we can track on the basis of that. Here, once feature list is done, we plan by the feature, like which features we will include and which release cycle. And once planning is done, we go for design by feature, like we design, first design the feature architecture part of it and then build by feature. So I'll move quickly to the next slide. Advantages and disadvantages of feature driven development. So biggest advantage of feature driven development that it supports multiple teams working parallel because we can assign different teams on different features. They can work parallelly on their stuffs and later on it can be integrated into one part. All aspects of project tracked by feature. So as I said that you instead of user stories and scrum here in FDD, we use feature to track everything. So design by feature and build by feature aspects are easy to understand and adopt. So it is visibly convenient for all the team members. They can easily understand what they have to do and they can work accordingly. Similarly, it scales to large teams. So usually feature driven development supports large number of team. 50 is the normal size of a feature driven development project. You can go up to any number in that. So that is flexibility given by FDD. So disadvantages promotes individual code ownership as opposed to shared ownership. So it would happen because several teams are working parallelly on several stuffs. Then ownership would remain with one individual or maybe a few individuals. So that kind of shared ownership is not available here which actually as I does not promote and iterations are not as well defined by the process. So because we are working on features and we don't know exact time to complete those most of the times. So iterations are not fixed here like in other agile methodologies like in a scrum or can when or wherever. We have defined iterations but here we can't do that. Similarly the model centric aspect can have huge impacts when working on existing systems that have no models. So like if we are migrating from any other existing agile methodology to feature development then probably that may be problematic for us. So here FDD in a nutshell. So processes and tools are like as we discussed on the last slide we develop an overall model architecture and build a feature list plan by feature design by feature build by feature and practices are domain object modeling. High-level class diagram we make here so that things can be put there and we can track on the basis of that. Developing by feature, individual class ownership reporting visibility of reports. Team is wide spread here and there's no set team in feature development. Project managers, chief architect, development manager, chief programmer, domain experts, all kind of roles are there. There are several supporting roles too and project philosophers are like multiple teams working on the same project, tracking through features and model centric approach. So comparison table, Sany, maybe you can speak about it. Yeah. Okay, so in a nutshell, yeah. Okay, so just to summarize everything up over the different elements, there's a lot of similarities between Kanban and Scrumban and the Scrum seems to offer more structure and more refined rules. So when in the comparison, you can see the artifacts, you have many artifacts for Scrum, less so on the Kanban and Scrumban style, excuse me, frameworks. So that again, when you're making a decision what to choose, it's important to know what artifacts you're going to have because if you do have them all, then yes, you can take Scrum and if you don't, then you need to find what fits to you, whether it be the Kanban or the Scrumban. The board at the beginning of a sprint, your board or the end of a sprint, your board should be empty and you're starting anew with the sprints on Scrum but with Kanban and this was for me one of the major reasons why we moved to Scrumban. The board is in continuous use. So what you thought you would take on at the beginning of the sprint but you didn't until three sprints later, that's fine. That works for Scrumban and Kanban. With sprint, everything should be completed and clean slate and moving on. Ceremonies, again with Kanban and Scrumban, do what's good for you, do what you need but Scrum requires that you do the ceremonies in order to make the next sprint work. Teams and roles, most say you should have some kind of Scrummaster agile coach, something like that to lead the team through, not someone who's not technical or not necessarily technical. In Scrum, very clearly defined roles, product owner, without it things can get complicated. Scrummaster, although the objective is not to have one because everyone's self managing, at least for the start someone to give the structure to the sprint. For Kanban and Scrumban, this is optional. I do, it is recommended to have some agile coach, otherwise you just kind of have a board on a wall and a few people talking around it. So someone to give it some kind of structure. Iterations, sprints as we know and Kanban and Scrumban, again Kanban as you wish and Scrumban, like we do or I've chosen to do, is to have to maintain those iterations but with a lot of flexibility. Task assignment, Scrum, predefined, everyone gets what they need to do at the beginning of the sprint and with Kanban and Scrumban it's pulled and with Scrumban you can push and pull. Prioritization is part of the backlog grooming session, ceremony with the PO. With Kanban it's as you want and the backlog just needs priority. So as long as you know what's the main thing you want to work on, you're all right. But again, this has the challenge of always having the high priority items, groom, defined, estimated, whatever it needs to be in order for the developer to take it up and start working on it. There's many performance metrics that you can be used in Scrum, the burn down charge, velocity. I have actually kept velocity, like measurements, the capacity of the team. I think that helps when defining in Kanban and in Scrumban. Scrumban, it helps to know how much work in progress tickets they should have, what their limits should be and I luckily had that information from when working with Scrum and maintained it going over to Kanban and to Scrumban. So, and then Prabhat will do this one. Oh, really? Okay, so again, extreme programming. You have a release plan, an iteration plan. There's artifacts that features high-level diagrams for FTD and lean is again also like Kanban, more cumulative flow diagram, virtual Kanban board, not virtual Kanban board. Extreme programming like Scrum has a clean slate at the start of the sprint. FTD has a feature board and lean has the Kanban board. Ceremonies, as you wish, you know, there's no extreme programming has them in place but I think it's got the flexibility to do it as what fits to your team. I think that's going to be when choosing the right framework, it's what fits to your team and to your project objective that always has to be the forefront of your mind. Iterations are incremental. Iterations for FTD are feature-driven, hence the name. And for lean, it's a constant stream as business defines, really. Extreme programming, unlike any others, the task is assigned by the client or the customer and for the others, it's a pull. Majority of our job is actually a pull from the team member themselves to choose what they want to work on next. Obviously, having whatever the basis of the prioritization is, that is a clear indicator on the ticket, on the card, whatever, so they know not to take what's relevant, not just what they want. Prioritization is done by the client for extreme programming, hence them allocating the tickets makes the most logical sense. And for FTD, it's done by the project manager or architect, according to the feature that there's been worked on. And lean development is, again, by the business, what will provide the ROI? And very similar matrix, the burn down charts, the lean and cycle time and cumulative flow for both FTD and lean development. So these are the methodologies. Well, under agile methodology, these are the different frameworks. You know, the advantages and disadvantages. The question is, what is the right methodology for you? Papai is going to talk about Cinefen to help us go through a flow of how we can make that decision. Okay, yeah. So Cinefen is a very popular decision-making framework. It has been used by George Bush's administration, too, for analyzing policy and the impact of release and in process. So it describes problem, situation, and system with the help of research. And further, it explores relationship between context experience and the person to propose new approach to communication decision-making. So basically, it has been at operate recently for agile decision-making and picking right methodology as far as agile is concerned. There are five domains, obvious, complicated, complex, chaotic, and disorder. We will discuss about four of it one by one. So here is the picture, like in this picture, we can see about all the four domains which are in use, obvious, complicated, complex, and chaotic. Now here, obvious is where we can sense, categorize, and respond. So identifying problem. We can easily identify what is the problem, and we can also quickly pick what is the solution for that problem. So it may be simple support tickets where we know how we can fix it. So again, no analysis is required there because we know the best practices and we need to follow standard operating procedures. So here, we can use any framework, anything, whatever we are continuously using, we can go ahead with that. I don't think we need to make any further change into our processes there. Next comes to complicated, where we have to sense, analyze, and respond. So here, a problem we are able to understand about solution we have to sense, we have to think about it, and then we have to do analysis and respond. So in such cases, cause and effect are separated over time and space. It happens like sometimes, any solution work for us, but later on, when we try to repeat it, it didn't work for us. So maybe, in such cases, we have to do the analysis. We have to think about the present situation and how we can do in a better way. So here, we can use Kanban. Kanban is a good framework for this purpose where we can keep our tasks in the backlog items and we can pull from there and we can work upon that. Next one would be complex. Here, we have to probe, sense, and respond. So we have to think about the solutions. We have to think about the other situations. And we have to sense on the basis of that, like what would be the right solution. For example, in Scrum projects, we make decisions like this should be our back end part, this should be our front end part and how we can collaborate things together to provide a right solution. So again, cause and effect seen in retrospect and do not repeat. It is visible, but it doesn't repeat. It changes over the time. And we have to use emergent practices for it. So next, I will move to Kios. So here, we are not able to understand what would be the right solution. Act, sense, respond is the key there. Like we have to act, keep on acting. We have to keep on trying for the solution and respond on the basis of that. So extreme programming is one of the framework which we discussed about. We can use here for Kios domain of Senefin because we can keep on trying with the best practices where we can manage a better code quality and test ribbon development and think about the solution. So noble practices are discovered here. Every time we get a solution for it, that is noble and that is phenomenal for everyone. So this is the end of our presentation and if you have any question, then yeah. Okay, thank you. Thank you.