What Agile Is — And What It Isn’t

13 September 2012

Michele Sliger
Sliger Consulting Inc.

This article was originally featured at ProjectsAtWork and is reprinted here with permission.

 

 

What is Agile? Agile is a philosophy of product development that uses organizational models based on people, collaboration, and shared values. The phrase “Agile” was coined in February 2001 at a summit held in Snowbird, Utah. Attending were people who had been practicing ways of developing software that took advantage of the collaborative and creative energies of teams and the quality that comes from building learning in as one progresses. During the summit these folks defined their commonalities and created an Agile Manifesto, which details their philosophy of product development and the principles that drive Agile teams. If you haven’t yet read the Agile Manifesto that came out of this gathering, you can find it here.

While the term “Agile” originally denoted a way to deliver software products, it has in more recent years been broadened to refer to a way to deliver any product, not just software. The philosophy around collaborative work in iterative environments where teams continuously reflect and refine is suitable for many types of product delivery.

Being agile means that teams are working in ways that allow for change in order to better work together and provide a more useful and meaningful product to the customer. It’s the ability to inspect and adapt, reflect and refine, and efficiently and effectively manage the changes that inevitably occur.

What Agile Is Not

Agile is NOT an excuse to stop producing documentation. It IS a reason to examine why you are producing the document to determine if it’s truly useful and valuable or if it’s simply what you’ve always done. In Agile we question the need for the document, and eliminate producing anything that doesn’t make sense, isn’t valuable, or isn’t useful.

Agile is NOT an opportunity to eliminate planning. It IS an opportunity to institute rolling wave planning, a practice that’s documented in the PMBOK. In Agile projects, we don’t stop planning —instead we plan all the time, with the appropriate amount of detail for the time horizon that we’re planning for. Our project plan is a high-level vision with several key features, our release plans are focused on more detailed product features, our iteration plans get down to the tasks required to implement these features, and our daily plans coordinate activities, raise issues, and identify roadblocks. We can and do provide projected dates of completion and cost, using top-down planning and gross-level estimation techniques.

Agile is NOT open season on scope creep. It IS an invitation to the customer to collaborate with the team. It IS an opening for the customer to have a way to painlessly change the requirements and for the team to react accordingly. It IS a way to prioritize valuable features and work them through to completion, because we realize that eventually we’ll run out of time or money, or both.

Agile is NOT about blindly following a set of “best” practices, whether or not they’re best for your project. Agile IS about doing what makes sense, based on the agile philosophy and the given situation. Please note that even the PMBOK says it contains “generally recognized good practices” – not “best.”

Why You Should Care

You should consider adopting agile for more reasons beyond the oft-quoted speed to market, increased ROI, reduction of waste, and other “faster-better-cheaper” explanations. You should consider adopting agile because it helps teams fulfill their moral duties and obligations as product developers.

Agile, because it is value-based, is a key driver in ethical behaviors. This is not to say that non-agile methods are unethical, nor is it to say that all agile teams are working ethically. Instead, this is about embracing a method that is value-driven — both in the #1 goal of providing value to the customers and in the agreement of the ways we choose to work together to provide that value.

Agile approaches provide a framework that enable frequent delivery of product increments or features that the customer needs, with as little waste as possible. And several of Agile’s 12 principles remind us that providing value to customers should not be at the expense of those doing the work, or those supporting the people doing the work. By creating and maintaining an environment that allows the team to do challenging and fulfilling work at a sustainable pace, we make sure that we are giving our best efforts — not clouded by exhaustion, despair or fear — at creating a valued and quality product. 

Adhering to a set of values that drive positive collaborative behaviors and result in frequent incremental product delivery helps us to work in an ethical manner. This is part of the foundation of what it means to be Agile.

Getting Started

As Agile has been around for more than 10 years there’s a wealth of information, much of it free, which will aid you in your learning. Start right here at ProjectsAtWork, where you can search an extensive archive of helpful articles and resources to guide you on your journey. Consider joining the PMI Agile Community of Practice and the local Agile chapters that can be found at the Agile Alliance and Scrum Alliance websites. Along the way, ask for recommendations on whose Twitter accounts to follow, which blogs to read, and what conferences are must-attends.

Finally, use an agile approach to learn about agile. Iteratively and incrementally build your knowledge base, starting with the most important topics first (philosophy and key concepts), and inspecting and adapting the list of topics you want to know more about as you discover more in your searches.

Good luck, and welcome to the agile community!

Michele Sliger is the co-author of the book The Software Project Manager’s Bridge to Agility, which focuses on helping PMI-trained project managers make the transition to Agile. Michele is a Certified Scrum Trainer (CST) and a certified Project Management Professional (PMP), and is the president of Sliger Consulting, Inc.

Article Rating

Current rating: 0 (0 ratings)

Comments

Han van Loon, CSP,CSM,CSPO, 9/24/2012 1:42:23 PM
Hi Michele, thanks for the article. I find the PMI approach to agile to be way too late and a repeat of the "let's harvest the (agile) community and relabel it under our own banner" as they did with PM practice in the PMBOK. As an (unattributed) Australian contributor to the original PMBOK (I smile when people quote the old QM section to me) in the distant past, I personally think practitioners should go direct to organizations like the Scrum Alliance. If PMs come to practical sites like Scrum Alliance as a result of your efforts and book, then this can only be better for the community. best regards. Han van Loon

You must Login or Signup to comment.