"Big Agile" and "little agile"

There are two types of Agile, "Big Agile" and "little agile." Big Agile is the philosophy; the business theory and perspective of how we want to work with others that supports why we would make this process change. If you truly intend to alter the way you think about why you do projects and how you do them, you cannot merely buy a toolkit, stick up a few Agile posters, or pay for an Agile course, and then automatically have an Agile team. What makes the things you do truly Agile is the way you do things and the reasons you have for doing them that way. In other words, you cannot "do" Agile, you have to "be" Agile.

Calling Agile "Big" and "little" is in no way related to relative value or success when used within a project. It is taken from the image that a large umbrella encompasses the philosophy and principles of Big Agile, which are more general and less decomposed into tools and techniques. Little agile refers to various approaches that are more specific to certain types of projects and industries, but which are still formed to fit under the big, overriding ideas.
So, Big Agile is the philosophy. Since Agile is intended to be modified and customized for each industry, organization, and small team need, we will never see a time where all the processes are the same and we can memorize them in clear steps, like we do now when studying for the PMP exam.

The group of practices that we call "little agile," on the other hand, do embrace a specific methodology to improve the success and quality of project outputs. These are the tools, techniques, and activities that people use to implement the big ideas. They are sometimes also referred to as "productized" processes. There are books written about the specific practices and the cyclical steps to take, for-profit classes that prepare you for certifications and carefully differentiated roles, and websites, associations, blogs, and webinars dedicated to this particular brand of little agile. The little agile process has become a product in and of itself.

Productized process sets are most frequently found in both software development and web development areas, although there are also specific techniques that have been adopted and customized through experience for manufacturing, as well as other more product-oriented industries. These approaches still provide for increased team flexibility, but within a standardized, repeatable set of guidelines that are driven under the hood by the Big Agile philosophy. Remember, despite the customization, the intent is that what you do on a daily basis is not as important as the changes in your thinking that drive the why of what you are doing.

With little agile, it is important to follow all of the steps, for example, the steps of a Scrum software development process. Picking and choosing only a part of the Scrum plan will negate the outstanding value that organizations using Scrum are gaining.

For now, let's discuss and understand the Big Agile concepts. Later, there is an overview of some of the little agile tools and practices you might encounter like SCRUM, Extreme Programming (XP), Dynamic Systems Development Method (DSDM) which is especially popular in Europe, Lean Manufacturing, Kanban, Crystal, TPS, Lean Software Development, Rational Unified Process (RUP), and Feature Driven Development (FDD), where there is great value to doing specific things in a cyclical order.

Since our goal is to find ways to integrate the best of the attitude shifts of Agile in our non-IT type projects, we will focus on the ideas that are encompassed in Big Agile, and then look at what we can borrow from the little agile skill sets to enhance our own projects.

So, when we talk about Agile, think about synonyms like "more flexible," "adjustable," "adaptable," "changeable", "quick", and "resourceful." The word Agile should evoke the image of an easily alterable process in which teams can quickly respond to change. They are able to adjust to changes in the project requirements, business environment, or regulatory changes, whether in the organization or in a merger environment. Today's teams need to provide fast responses to shifts, whether in customer fads or unexpected stock market adjustments.

When asked about the benefits of implementing Agile in a State of Agile Survey from Version One (2011), 84% of respondents said the number one advantage was the ability to manage changing priorities. The next most highly ranked value was in improved project visibility (77%), followed by 75% of those surveyed who found increased productivity was important to them. Improved team morale was reported by 72% of the respondents, while 71% said they saw a faster time to market as a result of changing to Agile. And, 68% found it gave them a better alignment between the project and its business objectives.1 Granted, these were software development implementations, but if these positive and enviable changes were found in this area of the organization, there have to be similar benefits in some amount for non-IT projects, too.

Project managers are chasing a shifting target due to constant changes in today's business environment. If any of you are hunters, servicemen or women, archers, or even if you only have the Paper Toss app on your iPhone where you try to toss a wadded up paper into a wastebasket, you know about trajectories. If you are trying to hit a moving target, whether with a bullet, an arrow, or a wadded up piece of electronic paper, you cannot aim straight in front of you where the target is now. You must adjust for the wind, and the speed of the target if it is moving, and aim your throw ahead to where it will be in the future.

Our job today is to point ourselves and our projects toward where we need to be in the future in order to hit the business targets. Not only do we have to change where we are headed, we have to lead the change. One change, most definitely, is toward a more flexible process to manage projects. We need to embrace the Agile philosophy and principles regardless of the department in the company where we lead projects.

Taken from : Agile Practices for Waterfall Projects: Shifting Processes for Competitive Advantage