A PM’s Guide to Agile Software Development


agile software development

Everybody’s talking about agile software development these days: project managers, software developers, IT directors, small startups and big corporations. You know it’s a hot topic and if you haven’t started exploring it, you may be feeling left behind.

To get you a bit caught up on the topic, I’ve pulled together an introduction to give you an overview of the background and philosophy, along with a few of the most popular styles of Agile.

Read on, and learn what everyone is talking about.


What is Agile Software Development?

Agile software development is an approach that promotes delivering value quickly to the customer. Agile teams prioritize collaboration, adaptability and working software.  Continuous innovation and improvement are regular practices.


Software Development and a Ski Trip

It came about during a ski trip in 2001. Seventeen guys gathered at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah. From the description, it sounds as if it were meant to be a recreational trip, but during that trip these guys also developed the Manifesto for Agile Software Development.

This group of guys recognized a need for a more adaptive alternative to the regimented, documentation-driven software development process.

As a result, these men laid out a set of beliefs and principles that make up the Agile Manifesto.

They identified the following 4 values promoted in Agile software development:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Source: Manifesto for Agile Software Development,


Working software, collaboration, and responding to change are valued more highly than process, documentation, and following a rigid plan. So when you’re developing software to solve business problems, you want to get it out as soon as possible so that your customers can begin to realize value sooner. These are the drivers behind adopting agile software development practices.


For an easy-to-understand tutorial on software development, check out my post:  SDLC Tutorial for the Software Development Lifecycle

Agile Principles

In addition to the 4 values of Agile, there are 12 Principles that make up the foundation for Agile:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Source: Manifesto for Agile Software Development


Mindset is an important component of Agile software development. Adopting an Agile mindset and knowing the drivers behind the practice can help if you do decide to adopt agile practices on your team.


The Need for A Different Software Development Approach

Today both technology and the marketplace can change quickly. Traditional waterfall planning and execution can lock down budgets and team resources on a set plan that might not deliver value for 18 months. At that point the deliverable could be outdated or miss the mark.

In contrast, agile software development allows organizations to succeed in the midst of volatility and uncertainty. An agile approach gives teams flexibility to respond to changing needs, even in the midst of developing the software solution.


The Benefits of Agile Software Development

Albeit, agile isn’t a magic bullet and might not be right for all teams or projects.  But there are many benefits to using an agile approach for software development. This Forbes article “The Benefits Of Using Agile Software Development” lists quite a few. The following benefits stand out:

  • Fast Feedback: I’ve seen situations where the customer changed their minds at the end of a well-planned and well-executed project. The customer signed off on requirements, tested, and agreed that the team delivered exactly what they asked for, but now that they’ve seen it, they changed their minds. When you use an Agile approach, you can show a prototype or working software to the customer at the end of a sprint.  Customers have an opportunity to give early feedback on development for any change in direction, well before the end of a long project delivery time.
  • Delivering Value Earlier: Because you can deliver value – in the form of working software – to your customer earlier – they can get the benefit earlier.
  • Adaptable Prioritization: Priorities can change through the course of a project. By using an agile software development approach, teams benefit from the ability to adjust as needed. When a team determines that a set of features needs to be prioritized and delivered faster than originally expected, the team can adjust as needed.
  • Allowing for Change: As you execute a software project, you will likely run into unexpected changes. Agile allows for variability throughout the implementation. This keeps your team from continuing down an undesirable path. This approach has the built-in flexibility to make adjustments as needed.

Certainly organizations need to be able to adapt to change. Innovation happens quickly these days, and teams need to be able to adjust. Agile supports the need to respond quickly to a fast-changing marketplace.


Different Styles of Agile Software Development

Organizations practice various styles of Agile software development. Here’s a brief rundown of the different types you might have heard of.



Scrum is the most widely used lightweight Agile framework. It uses an iterative software development approach with a goal of delivering capabilities every 2-4 weeks. Scrum provides high-level visibility to the work being done, as well as ongoing progress. You’ve likely heard of scrum activities that help provide visibility and ongoing improvement. For instance, regular planning sessions, daily scrum meetings, sprint reviews and retrospectives, and the use of the product backlog are terms you may have heard before.
The team can adjust quickly to change through the use of standard “inspect and adapt” practices.
Breaking work down into smaller increments and using short sprints allows the team to not only deliver smaller pieces of working software to the user more frequently, but to adapt quickly to unexpected variables along the way.

The main roles in a scrum team are the following:
  • Scrum master – The scrum master removes impediments, facilitates team meetings, and makes sure the process runs as it should. The scrum master also works with the product owner to ensure the backlog is ready for the next sprint. The scrum master has no formal authority over the team, but rather facilitates the ceremonies (such as daily scrum and retrospectives) to keep things running smoothly and strive for continuous improvement.
  • Product owner – The product owner must fully understand what the initiative is delivering and have a vision for the product. She must be able to communicate that vision to the team. The product owner is heavily involved throughout the course of the initiative, and is responsible for defining and prioritizing work as changes occur through the course of the implementation. According to this description on the Mountain Goad Software site, “communication is a large part of the product owner responsibilities.”  She must work “closely with key stakeholders throughout the organization and beyond” and “must be able to communicate different messages to different people about the project at any given time.”
  • Team Members – According to Scrum Alliance, “A typical Scrum team consists of five to nine people and generally includes the typical functional roles required to complete the project. In software development, that means architects, testers, developers, and designers….” The Product Owner determines the focus of the work in each sprint, but the team can determine how they will execute the work to achieve those goals. For example, testing the code can be conducted by someone who is not a traditional tester, if that works best for the team.  Once a team starts the work in the sprint, they stay dedicated to that work until that sprint is complete.



Lean software development was originally developed by Mary and Tom Poppendieck, in their book Lean Software Development: An Agile Toolkit. They took lean manufacturing principles and applied them to software development. In this book, they identify seven fundamental lean principles that eliminate waste and increase the speed and efficiency of development.
Hacker Chick Abby Fichtner explains a bit more in her article Agile vs Lean: Yeah Yeah, What’s the Difference.

She lists the following seven lean principles:
1. Eliminate Waste
2. Build Quality In
3. Create Knowledge
4. Defer Commitment
5. Deliver Fast
6. Respect People
7. Optimize the Whole

In her article, Abby states that “Lean says to relentlessly eliminate anything that isn’t adding value and only work on what we absolutely need to be doing at this moment in time. Eliminating waste means eliminating useless meetings, tasks and documentation.”



Kanban is an approach that allows the team to visualize their work as it moves through various stages, and limits the amount of work that is in progress at any one time.

The team’s work is displayed on a board so that they can clearly see what’s underway and the current status at all times. The team can create a physical board and write the work on cards, and move them forward  as the work progresses. Or the team can use a digital tool that displays multiple columns representing different steps in the workflow. This gives the team visibility to what’s underway, where there might be bottlenecks, and keeps the team from working on too many things at once.

As a matter of fact, you can adapt a Kansan approach for different situations. I use a Kanban board for my individual work, and sometimes create one for my daughter’s chores.

(You can read how I use my Kanban board here: I’ve Traded My To-Do List for a Kanban Board


Extreme programming (XP)

Kent Beck formed the XP approach, and wrote the book “Extreme Programming Explained: Embrace Change.” This Techtarget definition of Extreme Programming explains that in XP, code comes first. Since code is top priority, you want to know that your code is successful. For this reason, you “write a test for it first so that you will know when your code succeeds.” He also introduced the idea of pair programming, in which the code is “written by pairs of programmers, forcing the main programmer to describe the code to the other programmer and perhaps to stimulate further ideas.”

Beck advanced the idea that if you know a practice is good, then doing it more is better. If testing code is good, write your tests first and run tests automatically as you code, since continuous testing is better. If peer reviews are good, then constant peer review, or “pair programming” is better. Good practices, taken to an “extreme.”

The Techtarget article explains that “Rather than specialize, all team members write code, test, analyze, design, and continually integrate code as the project develops. Because there is much face-to-face communication, the need for documentation is minimized.”

If you want to know more about extreme programming, the article “Extreme Programming: A Gentle Introduction” also gives more in-depth information.



Agile software development is not a set methodology, but a set of principles and different approaches. They all represent a complete mindset shift from the standard waterfall approach. Understanding the philosophies behind the approach gives you insight into why it can be valuable. If you decide to explore further, and perhaps even give it a try, keep the principles in mind as you move forward.

Discuss the various approaches and see if one specific approach fits your needs, or if a blend of the approaches serves you best.

Adopting Agile software development takes buy-in and support from the team. Having discussions on the benefits, and why you want to try it, will help as you adopt the practices. And don’t expect to be perfect. Keep in mind that it’s a path of continuous improvement, and adopt a learning and growth mindset, and you’ll have much more success.


For more information on the difference between Agile and Waterfall, an example, and the pros and cons of each, read this post: Agile vs Waterfall Methodology.  Then dazzle everyone with your deeper understanding!



Leave a Reply