PRINCIPLES BEHIND THE AGILE MANIFESTO

On February 11-13, 2001, at The Lodge at Snowbird ski resort, overlooking the Wasatch mountains of Utah, seventeen independent thinkers, self-described as “The Agile Alliance,” met to talk, ski, relax, and try to find common ground.

Representatives included those with backgrounds in #ExtremeProgramming, #Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation heavy software development processes.

What emerged was the Agile ‘Software Development’ Manifesto, a set of values (seen in this image) and the “12 principles of Agile Software”.

While I have written other articles discussing some of these principles in detail and examining their validity in today’s world, the intent of this article is to simply provide a quick “101” on how I have seen these followed with the best intentions.

Principle #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Focus on those things that are most important to your customers and deliver them quickly.

Too often organizations become too focused on those things that they want to deliver, that they value, and that they see as worthy of their effort. They prioritize their pet-projects over the needs of the customers.

Instead focus on those things which will satisfy your customers’ needs. If your customers have a problem or need, and you cannot solve it in a timely manner they will go somewhere else, and there is plenty of elsewhere to go. Remove wasted efforts on things your customers never asked for or may no longer want. Lean out your processes to help drive down lead times while focusing on your most valuable asset, your customers.

Principle #2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Understand that the customer does not always know what they want, and they may need something different before we are done building it. As designs emerge and features are created, we generate a better understanding for what may solve our needs. We preview the work accomplished thus far and realize that what we see and likely asked for may no longer be desired. We change our minds.

When we spend days, weeks, and even months negotiating contracts with our customers we are wasting value time. Oftentimes, our requirements and/or problems we are trying to solve have already changed by the time we begin. Fix as little up front as possible and let the solution emerge over time.

Principle #3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Deliver working software, not defect/bug ridden software that must be regularly fixed. Deliver it often. Break it down into smaller chunks so that we can demonstrate its capabilities, receive feedback, and adapt to any necessary changes. The smaller we can break down a solution, while still providing value to our customers, the faster we can deliver it, and the faster we and our customers can extract value from it.

Principle #4: Businesspeople and developers must work together daily throughout the project.

We need to bring together those closest to the customer with those developing the things our customers want. In doing so, we become more aligned to our customers desires and the solutions that can solve their problems.

This does not mean our developers should sit with a company’s executives daily, rather that those managing our customers needs, the project, program, and product managers need to be accessible, often communicative, collaborative, and provide customer feedback as timely as possible. We often see this done in an Agile environment by introducing a Product Owner onto the development team.

Principle #5: Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

Autonomy. Self-organization. Self-management. Allow those who are eager to do the work to do it. Build an organizational culture that motivates individuals and where people want to work. Provide an environment that is fun and exciting to work in, provides the necessary tools and support needed to thrive, and then get out of their way. Decentralize decisions down to the lowest level so that the organization does not build in processes, procedures, and policies that will impede their progress. When we do this, amazing things will happen, and fast.

Principle #6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Face-to-face communication is arguably the most effective and efficient means to communicate. We can actively listen, quickly clarify, and respond to inquiry. We can hear tone, sarcasms, and read body language. Verbal, face-to-face communication is fast and understood, far more effective than email, which are commonly misunderstood and can cause wasteful wait times for a response.

Principle #7: Working software is the primary measure of progress.

It is not about how much we can “get done”. It is not about how much effort we put into our tasks, or how many points we were able to accomplish. It is about delivering working solutions to our customers, free of defects and bugs. If the valuable thing we are delivering works, and works as designed and requested, we have progressed. If those things we complete are not deliverable, not demonstratable and valuable to our customers, not evaluable, they are likely not complete.

Principle #8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Using agile processes provides for the flexibility to shift quickly and adapt to changing circumstances. When we understand our true capacity, plan to that, and not overwhelm ourselves with expectations that stretch us out and stress us to our limits, we build agility in. As developers become more predictable in their delivery, everyone from team members through to the organization’s customers can set more realistic expectations. These expectations are what provide for a more sustainable and maintainable pace of delivery.

Principle #9: Continuous attention to technical excellence and good design enhances agility.

We need to be technically excellent – that is, we need to pay attention to the details, build things right the first time, and not gold-plate the things we build. Keeping things simple and repeatable adds increased speed and agility into the team’s processes, and over time, builds trust within the team that extends to your stakeholders.

Designs should be simple, flexible, and easily understood. Good design is when we build things in a way that does not create a significant amount of rework or technical debt. Good designs are repeatable in whole or in part, and shareable due to their simplicity and communicable nature. This enhances team’s agility.

Principle #10: Simplicity–the art of maximizing the amount of work not done–is essential.

KISS – Keep it Simple Stupid. “Simplicity”, or simple things, are easily understood, and straightforward to implement. Simplicity does not cost a lot of time (or money) to implement and therefore makes software easier and less painful to revert. There are many areas that can be simplified and are “essential” to agile delivery such as architecture, development, testing, and standards and practices.

Maximizing the amount of work not done implies that agility is about rethinking processes, practices, and steps that where “necessary” in traditional waterfall development. This is where we focus on reducing waste and creating a leaner process. Any effort that can be avoided, while still producing the same end-value, can be classified as waste.

Principle #11: The best architectures, requirements, and designs emerge from self-organizing teams.

To be agile, we must embrace the fact that those performing the work are highly intelligent. We must accept that our knowledge workers understand the work best and given the autonomy and decentralized decision making to do so, will deliver far better things than if we require them to build everything to extremely specific specs.

Great teams will emerge architecture and design over time, balancing it with the more intentional scalable architectural requirements provided by the larger system. While some requirements may be fixed early in the process, allowing divergence during development more often leads to better design and greater options. Developers can then converge on ideas based on customer feedback and deliver a higher quality, more valuable product.

Principle #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Retrospect! Continuously and relentlessly improve.

We must build in a cadence to continuously look at ourselves and reflect on how we are doing. We must consider all the great things we were able to accomplish and how that happened, as well as all those things we could not quite accomplish, quality concerns, and process challenges. We must look closely at ourselves and realize we will never be perfect and that there will always be other companies that can provide our products to our customers. We must look to relentlessly improve.

This means we must not only identify the problems and challenges we are having, but fully invest in solving them. We must spend sufficient time to understand the problem fully, determine the best solutions, and act on them. We must build time into our commitments to act and solve the challenges we most certainly will face regularly.