Agile is highly adaptive, so it's role based, but it is a framework. It's a framework that can be customized to meet the needs of the organizations. Agile is where the systems are developed using these incremental methods. We start off with a small version of our product, and the product rose in functionality as our iterations complete, and this whole time we are getting feedback from the customer. A few years back, and there is a date given here. This is the community's agreed date, accepted date. A document was written called The Agile Manifesto. A lot of these practices have existed for a long time, but they were never formally written down. The Agile Manifesto consists of values and it consists of principles. Right here are the values of The Agile Manifesto and they're written this way for a reason. We see right in the middle here, we see over, and this definitely is the middle. We have items here, on the left and items on the right. We value the items on the left a little more than the items on the right because the items here on the left, that is where we collaborate with our customer and we learn to deliver a better solution. The items here on the right are important, no question about it. I'm sure our customer cares deeply that we continue to work with these items here, but they don't help us in creating a great solution for our customer. Individuals and interactions, so that means working with not only our customer, but the teams that are supporting us and our team themselves and possibly other stakeholders. Learning how to build the best solution possible. Processes and tools. Maybe it's our time sheets, maybe it's some other tool. Very important, but again, won't help us build a great solution. Working software or a working solution, obviously, that is going to be a strong measure of progress. A strong measure that you understand what the customer needs. Comprehensive documentation. If we've ever been part of a project where the whole project was planned, maybe 12-18 months, maybe more, all milestones, all budgets, all teams. Then the project begins and then changes start to come in. That indicates that the comprehensive documentation was a lot of wasted work, and if we think about it, it requires a lot of business forecasting, and business forecasting is very difficult. There are people that get paid a lot of money to forecast the stock price of, you name it, Google, Bitcoin, Apple, and are they right all the time? Sometimes, yes, sometimes no. In fact, very infrequently are they correct. It just goes to show that nobody can really forecast the future too far ahead. It's much better to plan in shorter increments where we know the business environment, build a working solution, and then as we are entering the business environment, then manage the direction of the product. Customer collaboration. Obviously, this is highly important to discuss with the customer. Show the customer the working software, continue to interact, and also responding to change over following a plan. If the customer needs a change, if the business environment has changed, if there is any kind of crisis, we may not be able to proceed with our plan. Rather than following some plan that was written and a lot of estimations were put into it, let's respond to change immediately because that's what the customer needs.
