There are 12 agile principles outlined in The Agile Manifesto in addition to the 4 agile values. These 12 principles for agile software development help establish the tenets of the agile mindset. They are not a set of rules for practicing agile, but a handful of principles to help instill agile thinking. Show
Below we will review each of the 12 agile principles and describe how they may be practiced. Agile Principle 1“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”The best ways to ensure you make customers happy while continuously delivering valuable software are to ship early, iterate frequently, and listen to your market continually. Unlike traditional approaches to product development, which have notoriously long development cycles, agile principles encourage minimizing the time between ideation and launch. The idea is to get a working product in the hands of customers as soon as possible. Doing this successfully means product managers are able to quickly get a minimum viable product (MVP) out and into the world and use it to get feedback from real customers. This feedback is then fed back into the product development process and used to inform future releases.
Agile Principle 2“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”In the world around us, change is the only constant. Agile principles and values support responding to these changes rather than moving forward in spite of them. Previous approaches to product development were often change adverse; detailed, well-documented plans were made before development began and were set in stone regardless of new findings. Agile principles support observing changing markets, customer needs, and competitive threats and changing course when necessary. How it looks in practice:
Agile Principle 3“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”Agile philosophy favors breaking a product’s development into smaller components and “shipping” those components frequently. Using an agile approach, therefore — and building in more frequent mini-releases of your product— can speed the product’s overall development. This agile approach, with short-term development cycles of smaller portions of the product, results in less time spent drafting and poring over the large amounts of documentation that characterizes Waterfall product development. More importantly, this frequent-release approach creates more opportunities for you and your teams to validate your product ideas and strategies from the qualified constituencies who see each new release. How it looks in practice:
Agile Principle 4“Business people and developers must work together daily throughout the project.”Communication is a critical component of any project or team’s success, and agile principles essentially mandate that it’s a daily event. It takes a village to raise a child they say, and that applies to product as well. A successful product requires insight from the business and technical sides of an organization which can only happen if these two teams work together consistently. Regular communication between business people and developers helps improve alignment across the organization by building trust and transparency. How it looks in practice:
Agile Principle 5“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”A key part of the agile philosophy is empowering individuals and teams through trust and autonomy. The agile team needs to be carefully built to include the right people and skill sets to get the job done, and responsibilities need to be clearly defined before the beginning of a project. Once the work has begun, however, there’s no place in agile for micromanagement or hand holding. How it looks in practice:
Agile Principle 6“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”With so many distributed or remote development teams these days, this principle gets a bit of critique. But at the root of it, effective communication with developers means getting these conversations out of Slack and email and favoring more human interaction (even if done by video conference calls). The overall objective behind this principle is to encourage product people and developers to truly communicate in real time about the product, requirements, and the high-level strategy driving those things. How it looks in practice: Agile Principle 7“Working software is the primary measure of progress.”Proponents of the agile philosophy are quick to remind us that we’re in the business of building software, and that’s where our time should be spent. Perfect, detailed documentation is secondary to working software. This mentality pushes to get products to the market quickly rather than let documentation or an “it’s not done until it’s perfect” mentality become a bottleneck. The ultimate measure for success is a working product that customers love. How it looks in practice:
Agile Principle 8“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”Keeping up with a demanding, rapid release schedule can be taxing on a team. Especially if expectations are set too high. Agile principles encourage us to be mindful of this and set realistic, clear expectations. The idea is to keep morale high and improve work-life balance to prevent burnout and turnover among members of cross functional teams. How it looks in practice:
Agile Principle 9“Continuous attention to technical excellence and good design enhances agility.”While the agile philosophy encourages shorter cycles and frequent releases, it also puts emphasis on the importance of keeping things neat and tidy so they don’t cause problems in the future. Product managers often forget about this aspect of development because they mostly don’t spend their days wading through their products’ codebases, but it is still of the utmost importance to them. How it looks in practice:
Agile Principle 10“Simplicity—the art of maximizing the amount of work not done—is essential.”You’ve probably heard of the 80/20 rule—the concept that you can usually get 80% of your intended results with just 20% of the work. Agile principles encourage thinking this way; doing the things that can have the most impact. In a product management context this means having a laser sharp focus on organizational objectives and making some cutthroat prioritization decisions. Agile principles discourage building merely for the sake of building by emphasizing the importance of being strategic and building with purpose. How it looks in practice:
Agile Principle 11“The best architectures, requirements, and designs emerge from self-organizing teams.”In traditional software development methodologies, you’ll often see pyramid shaped teams where management makes key decisions for contributors. Agile principles suggest the use of self-organizing teams which work with a more “flat” management style where decisions are made as a group rather than by a singular manager or management team. The concept ties into agile’s value of teams and interactions over processes and tools, and the intent behind the concept is to empower teams to work together as they need to. How it looks in practice:
Learn more about managing complex requirements in an agile world in the webinar below.
Agile Principle 12“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”If you’re truly living by agile principles, there is no place for “we can’t change because we’ve always done it this way.” Just like we’re always learning new things about our customers and markets, we’re also learning from the processes we’re using to learn those things. Agile is not about following a strictly-defined process for every sprint and release, it’s about continuous improvement. And that continuous improvement must also extend to processes and teams. How it looks in practice:
|