If you've never heard of what Agile is, it is essentially a set of values and beliefs on how to effectively manage software projects. One of the main goals of Agile and for teams that follow Agile is that the processes that it allows for should allow a team to make more effective decisions as they manage and build out their applications.

That may seem like common sense; however for years before Agile came around, software teams used all kinds of various project management processes. Many of them used the wrong kind of approach, they focused on the wrong topics and they spent too much time that really ended up wasted. And so what Agile came around to do was to provide a high level framework for how projects should be managed.

Now we said in the beginning that Agile is a set of values and beliefs about how to manage a project. That actually comes from the Agile Manifesto that is their official definition.

Let's walk through what each one of those Agile values are because that's going to help you understand the entire process. The first Agile value is that we value individuals and communication over processes and tools.

All that really means is that many times in organizations they spend so much time and resources on trying to build out these tools and these various processes, and they actually ignore if their team doesn't like using a certain set of tools.

I've come across this many times in different projects that I've worked on, where a team really didn't like using a set of software tools, whether it's a project management tool or something like that and it made them less efficient.

If you're really following Agile, you would get rid of that software or whatever process it is that's inhibiting the team, because you're valuing the team as a whole and those individuals, and you want to make it as efficient as possible for them to communicate.

The next value is that we prioritize working code over comprehensive documentation. There have been so many projects I've seen where their resources go into writing all of this complex documentation. What usually ends up happening is the system has to change so much that they are constantly updating that documentation and that becomes more of a priority as opposed to simply having a working application.

You still need to have proper documentation and a set of instructions for either how to set up or work with a software system. But you should never lose sight of the goal, that the most important thing is that the application works properly.

The third value is customer collaboration over contract negotiation. Years ago what the process was, whenever you were building out software, is you needed to spend an extensive period of time building out the full set of requirements. Then you would go back and forth with the client until they agreed to the exact specifications that you outlined.

The problem with that though is that there were always items that got missed. The process that I saw happen all too often was that you'd spend all this time up front planning out the project, listing all the requirements, and then as soon as something needed to change, then there would be a lot of wasted time where you'd have to go back and forth with the customer and say, "Okay, this wasn't in the original contract. How are we going to do it? How much money are you going to have to pay us in order to update it?", and things like that.

Whereas in the Agile approach, contract negotiation is less important, whereas customer collaboration is more important. You're going back constantly, usually on a weekly or every other week basis to ensure that the system is being built properly.

The fourth Agile value is responding to change over sticking to a plan. What that means is as you go out and you build these applications, I can promise you because I've been doing this for over 15 years; I have never had one application where we got all of the requirements perfectly set up in the very beginning.

Software systems need to change on a dynamic basis. This is one of the key reasons why Agile was created, was because people years ago tried to set up all the requirements from day one and then it'd become incredibly frustrating because the application would need to change.

The customer would realize that they forgot a really important set of features that was not put in place there in the very beginning. Then it would become very difficult to change the system because everything was already locked in place from the beginning.

What Agile does is it allows you to be much more dynamic. That's really where the name comes from, it allows you to be agile. So as you're building out the software system, you're able to make more dynamic changes and you're able to be more flexible as you build it out.