So, essentially, it is a high-level set of rules and a mindset that you want to have when you're building out an application, and as important as it is to have that mindset, we also need to now take it a little bit further.

We need to go more low-level and see what does it look like to manage a project using agile methodologies, and so to do that, we're going to analyze two of the most popular implementations. They are more of real-world day-to-day practices that you're going to use. One is called Scrum and the other is called Kanban.

Both of these approaches are very extensive with all kinds of rules and best practices, so there's no way that we could go over all of them in a short video, and in fact, there are specific certifications where you could spend months learning each one of these approaches.

So, the goal of this guide is simply going to be to give a high-level overview so that when you hear about them in the future if you want to go into project management, then you'll know how they work.

Let's start with Scrum. Scrum is a project management methodology that has a few key unique characteristics. So, for one thing, a Scrum approach means that you break down your new features into what are called sprints. Now, these sprints are usually two to three-week iterations, so the entire team will focus on a new feature that you want to implement.

So, say that you're building out some kind of social media application and the next feature is to have the ability to follow friends such as on Facebook or Instagram. In a Scrum approach, the entire team would be focused for those two weeks for that entire sprint to take that feature all the way from the idea to where it's deployed in the application.

Now, a key with Scrum is that by the end of that sprint, there is a fully functioning feature. Another concept that is very popular when you're building out a project and using the Scrum methodology is to have what are called stand-ups.

So, remember with agile and the agile management process, communication is one of the biggest keys. Well, with Scrum, you have what is called a daily stand-up, which means that at the very beginning of the day, so right when you get in office usually, the entire team gets around, and everyone talks about a few key concepts.

They talk about what they did yesterday for the feature, they talk about what they're going to do today, and then they also bring up any problems that they might have had.

Now, I find this approach incredibly helpful because, one, it keeps everybody honest. So, if somebody did not work every well the day before, if they were lazy, it's going to become very apparent to everyone else that they didn't do any work, so it keeps everyone going and motivated to work. The other thing I really like about this is it helps identify problems and bugs very quickly.

So, one thing that I've seen happen quite a bit in projects that didn't use Scrum or this kind of process is that if they have some piece of data they need, maybe it's communicating with an outside server, if they go a few days without asking for access to that server, then the entire two weeks could go by, and then at the very end, everyone gets in trouble because they didn't finish the feature because they were waiting for permission to access that server or access that third-party API.

With Scrum, in these daily stand-ups, what happens is on day one, whenever that developer needs access to that data, at the very end of their little meeting, they say, "Okay. This is what I did yesterday. This is what I'm doing today. By the way, I can't keep working unless I get access to that data." So, right away, the project manager can go out and get them that access, and it doesn't slow down the rest of the project.

So, now that we've talked about a few key characteristics of Scrum, now let's talk about Kanban. Now, Kanban is a project development process. It was popularized by a number of Japanese and Asian companies that were trying to make their manufacturing processes more efficient, and so the software development people took those concepts and applied them to being able to manage a software application process.

In Kanban, you don't have two-week sprints. Instead, you take each individual feature, and you assign it to a developer, and you have them take it through stages, so they will have what is called a backlog, which means that it's a feature that needs to be built, but it has not been started yet. That will get assigned to a developer, they will take a card, they will move it into a work in progress. It's also called W.I.P for short. It takes it to the work in progress stage.

From there, after it's completed, the developer will say, "It is completed. It's now ready for QA testing, for Quality Assurance testing." After the QA team member has gone through the entire feature and they ensure that it's working properly, then they will move it to completed, and so that is the standard Kanban process.

Through the years, I've utilized both of these approaches on various projects. I don't really think that one is better than the other. I've had success and failures using both. It really comes down to, at the end of the day, how well they're implemented, how closely the developers are following those processes, and once again, how clear the communication is between all of the team members.