Principles of Agile
The course is part of these learning paths
Module 1 – Introduction to Agile & Scrum
This Module will look at the basics of what Agile and Scrum are, including the Agile principles and values, and the Scrum principles and Values.
Hi, everyone. Having four Agile values to change the mindset of the team is great, but how do we work in a more Agile way? In this video, we're gonna discuss the 12 Agile Principles which are based on the Manifesto and why they are so important. If you haven't read the Agile Manifesto yet, be sure to check it out. You can find it in the resources or just by searching for it online.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Have you ever worked in a project that only delivered a product or service to your customer after months, or even years of development, only to discover it doesn't really do everything you hoped it would? Delivering a fantastic service or product can take a lot of time, but all that clients really care about is that they get that product or service as soon as possible and it delivers what they need. Deliver only what your client needs as quickly as possible, then incrementally add improvements to create more value for your customers.
Welcome changing requirements, even late in development. Harness change for the customer's competitive advantage. For many people, changing requirements, especially late in development, can create difficulties between them and their customers. We need to see changing requirements as a good thing, though. Imagine your customer has received a few increments of the product or service and has been using it, and they discover something that could give them a competitive edge. This discovery will very likely lead to changing requirements. In fact, change is almost always inevitable. If we plan for change in requirements, we can always deliver exactly what our customer needs.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. In the past, a product or service would be delivered after months or years of the requirements gathering, design, production, and marketing. Working in an agile way means we need to get our product to our customers as soon as possible. We can iterate with every increment and continually update it, but we need to get it to them as soon as possible.
Business people and developers must work together daily throughout the project. Collaboration is key to successful projects. We need to make sure that everyone involved in a project with their different roles and responsibilities are on the same page. The only way to do this is to work together.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. In Agile environments, we need to give our most motivated people a space to shine by making sure they have the environment, funding, and trust of the organization. If our teams have this freedom to self-organize, and take the initiative to produce the product or deliver the service in the way they want to, they will deliver the best possible version of that thing.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. We need to try and communicate face-to-face whenever possible, even if this is via webcam. Written comms can be ambiguous and time-consuming to read and write.
Working software is the primary measure of progress. Coming up with ideas, planning, designing, creating and delivering products or services are all part of development. But customers don't care about any of these things. They care about a working product or service that helps them to do what they need to do. This means the best possible way to measure progress is by how much of the product or service is with our customers working and being used.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Just because agile processes help you deliver services or products to your customers on a more frequent basis doesn't mean that the team delivering it should be working overtime and weekends every week to do so. We should be able to consistently deliver value for our organization indefinitely.
Continuous attention to technical excellence and good design enhances agility. Once we've delivered the basics of our product or service to the customer, we need to make sure that every iteration gets better and better. Our customers want the core of the service or product, and that's why they bought it. But if using it feels bad or time-consuming or limiting, they may not keep on using it. Take on feedback and improve.
Simplicity, the art of maximizing the amount of work not done, is essential. Cut out necessary work, and streamline our workforce. The more time that we have to focus on delivering a product or service to our customer, the more quickly we will be able to do so. This principle is not about doing less work. Instead, it's about doing the right work and cutting out work that isn't really adding value.
The best architectures, requirements, and designs emerge from self-organizing teams. Self-organizing teams can take on work in the way they choose, dividing up responsibilities for the different tasks that need to be done to get the next alteration to the client. If we self-organize, we can create great products or services because we have the freedom to collaborate, experiment, share ideas and work however we want.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. As a project goes on, we'll learn new things about the requirement, and how we've been working. If we have regular meetings to discuss these, we can evolve as a team and improve the product. That's it for this video. On a last note, when you think about your team, do you think working in an agile way would help you to be more or less productive? Write down your answers and come back to them as you move through this course.
Paul Williams is a Senior Learning Consultant for QA, based in Manchester, UK. He is a member of the Agile, Lean & DevOps Trainer Team.