So here are the foundation development values the group of developers started with. First, individuals and interactions over process and tools. Now I like this view the best. It often seemed the project plan was the priority, with the critical path and its waterfall-based project mentality. Agile puts people and interactions first, which is immediately empowering for all team members, not just the project manager. Second, working software over comprehensive documentation. So, this is great from an outcome perspective as it puts the result first. The reason we are building this application, getting the service out there, is the priority for the project. In effect, this means we tend to iterate in development cycles rather than launching one big release, where everything, including the documentation is supposed to be complete. Now this appeals to many of us, but of course, it opens up some questions about what is the final outcome, how do we manage quality, etc., and we'll address those. Third, customer collaboration over contract negotiation. So this is a different view, right, suggesting a collaboration over a contract negotiation. Okay, so this could be seen as being a little ideal as at the end of the day, customers need to know the cost of things and developers need to get paid, right? Fourth, responding to change over following a plan. Now this is the most important difference in my view. Our traditional approach to project management was to agree a project plan, a timeline, and therefore a budget. Then, the developers would be begin working sequentially through developing code functions to deliver their overall solution. If there was a change to the scope of the project, or most likely, when we came across a specific challenge that required a change to the scope, the project's critical path would be impacted. Change was seen as a bad thing, as if the critical path of the project was impacted, the project will appear to be failing. 

With Agile, we encourage and revel in change. The premise of change is welcomed rather than discouraged. So the Agile principles are simply guidelines, inferred rather than explicit, in how we work day-to-day in an Agile process. And you don't need to know each of the principles by heart to work in an Agile way. The benefit of these principles is that when used right, they can empower individuals and teams and this can turn into and accelerate development projects. So the manifesto for Agile software development is based on 12 principles. 

Customer satisfaction by early and continuous delivery of valuable software. Welcoming change environments. Working software is delivered frequently. Projects are built around motivated individuals. Working software is the primary measure of success. Sustainable development. Continuous attention to technical excellence and good design. Simplicity. Best architectures, requirements and designs emerge from self-organizing teams. And regularly, the team reflects on how to become more effective and adjust accordingly. So here's how Agile can benefit us. First of all, we're focusing our effort on the important components. More focus on user interactions, more focus on activities and more focus on results. 

The customer is more involved in the cycles and so they see more results. We prioritize stories, estimate the time required to do them and assign them to small, incremental pieces of work. Doing this enables us to apply effort where effort is needed. Testing starts immediately. Now with short iterations, testing can be implied immediately, and that means the quality improves immediately, as there's less chance of arriving at the end of a project and finding there is something inherently wrong. So risk is reduced because there is immediate and continuous feedback. Stakeholders generally feel more involved and they're less likely to experience bill shock at the end of the project. So, Agile is another way to get projects done. It's potentially more action-orientated than top-down aligned. Team members are empowered to act on tasks within the project, rather than on the instruction of a project manager. And tasks can happen all at the same time, rather than incrementally. Rather than one critical path, we have a series of epics and an epic is essentially a narrative or story about doing or achieving something with this proposed service. 

It's defined from a user's perspective. So in essence, an epic is quite similar to a user requirement, but it's more user-centric. So far, so good, right? It is how the epic is quantified and scheduled that is inherently different. So some of the foundation stones of Agile include the following. First, self-organization. The team knows best how to deliver the work based on the resources and constraints they have available. Two, prioritization. Deliver work based on the value to the business. Three, empiricism. So the ability to perform, reflect, improve and continue in a step-by-step process to increase productivity. Four, time-boxing. The team is required to complete an assigned task within a defined timeline, which inherently brings more rigor. And fifth, collaboration. The team commits to delivering the final products within the given timeframes, which encourages cross-team collaboration and ultimately inspires people to come up with innovative ways of completing a task.