Agile Philosophy

Reading time ~5 minutes

When discussing the topic of Agile I believe it is important to set a common understanding of what it is and isn’t. This helps clear out some of the misconceptions and problems people too quickly blame on it.

In the shortest possible terms, Agile is a project management philosophy. Nothing more. It is not a process, a plan, a set of rules, or anything more concrete. Scrum and Kanban are processes, Project Management Plan (and all the sub-plans that go into it) are plans, CMMI is a set of rules…Agile is not. The basic concept of Agile is the Agile Manifesto and the 12 principles best as seen at Agile Manifesto.org (see below as well).

All of that is good information, but it doesn’t tell a development team when/how to prioritize work, how to estimate the amount of work needed, how to quantify metrics, or anything substantial, because it isn’t supposed to. Instead use Agile as a guiding way to look at the world. It is the tint of pink sunglasses glasses that colors everything in a rosy hue.

Why should people care about Agile as a philosophy? Philosophies without practical application aren’t very useful. But on the other hand, project management methodologies (Scrum, Kanban, XP, etc.) work better when you have a better mindset, guiding principle, or philosophy to frame them in. It is a way to double check that what you are trying to do fits with your overall goals.

Let’s take a step back and define some terms. “Waterfall” is the older school of thought for projects that has you planning everything (including timelines, risks, the entire scope & requirements) before acting, and when you do act it is to the plan as closely as possible. It is the standard project management style you learn and is extremely useful for building a building or such. Another way to describe it is a Predictive project management style.

Agile, was developed when people started realizing two major flaws of waterfall for software development: Changing requirements and bad time estimates. It turns out writing software was not like building a house. Development activities, and other technical work, often uses time to imagine how to solve the problem. Construction workers building a house don’t have to figure out how they will install drywall, they just do the manual work. Conversely, to fix a software defect a developer may have to spend hours pouring through code, running tests, talking it out, thinking, etc. just to find where a one-line change should occur. In addition, when building a house major changes are made to be difficult to enact for good reason. If the homeowners decided they wanted an extra bedroom after the first floor had already been built a lot of things will need to be changed to accommodate this. In software changes, like new features, often don’t cause such huge reworks and it has become standard that the customer changes their mind on the software functionality. These difference, and the acceptance of them, led people to begin searching for ways to better plan nebulous projects.

In predictive project management a project manager attempts to predict what events might occur that could throw the project off schedule or budget. Those events are called Risks. This includes estimating the wrong amount of time a task will need or someone changing the requirements. Risk is something every project (no matter the style) must deal with. Agile is a solution to deal with the risk of time estimates being wrong and the risk of requirements being changed by trying to adapt to both of those risks as they happen.

If Agile isn’t a methodology, what is Scrum, Feature Driven Development, Extreme Programming (XP), Large Scale Scrum (LeSS), Kanban, or all of the other things you hear about? First, Kanban follows the Lean principles (another post on Lean vs. Agile), but really all of them are just project methodologies that lend themselves better to the Agile way of thinking than Waterfall does. Each one handles the risks of bad time estimates and requirement changing in their own way, by focusing on different facets of Agile and project management.

Scrum, for example, deals with bad time estimating by instead estimating complexity with story points. With Scrum, you can easily hit each of the 12 principles, but you can also run Scrum without being Agile; abandoning most of the principles and all of the manifesto.

Personally, I feel that Agile guides a team how to better communicate. Notice that three out of the four lines in the manifesto directly deals with communication (both interpersonal and formal): Interactions, documentation, collaboration. As well the fourth, responding to change, requires more/better communication to be successful. If the team, and their supporting management, tries to view their work, projects, product, customer, and everything with the Agile mindset, I believe, they are more likely to succeed as they are better equipped with adaptive skills.

At the end of it all, if I would attempt to make a definitive definition of Agile I would say it is:

To help everyone remember here is the Agile Manifesto:

Keep in mind that you prioritize the left over the right, but you aren’t discarding the right.

Additionally, you can look at the 12 principles as being loosely connected to one of the manifesto points:

Originally published at https://agileaxiom.com.