What is agile program management?

Agile program management is an approach to managing multiple related projects (a program) that relies on agile principles such as flexibility, collaboration, iterative development, prioritizing customer feedback and continuous improvement.

Agile is a philosophy with a set of principles more than a specific methodology. However, there are well-established agile methodologies that are often part of agile program management, including Scrum, extreme programming (XP) and Kanban. Agile program management was initially designed by and for the software industry to deliver greater value to customers more quickly, but it now has applications far beyond that industry.

Agile program management typically includes several related projects. Individual projects can be managed with an agile framework, but agile program management incorporates a set of projects into a single cohesive whole throughout the entire lifecycle. Moving up a level, a set of programs and underlying projects might be organized under a broader portfolio management strategy.

Agile project management focuses on a specific project, and the management of objectives, timelines, resources and teams related to that one project. Agile program management oversees a group of related projects and the strategy that unites these projects under broader organizational goals. These two disciplines share many of the same functions, but vary in scope, with agile program managers taking a broader role in program strategy, risk, stakeholder communication and more.

A quick, oversimplified way to think about it is that project management is more concerned with the tactical and timely execution of an individual project. Whereas program management takes a more strategic approach to coordinate the comprehensive success of separate projects under the program’s purview.

Project management as a discipline began to take shape in the United States in the 1950s. By the 1990s, a group of methods known as “waterfall” were formalized, in which each phase of a project must be completed before the entire team moves onto the following phase. But as software increased in vitality and complexity, the traditional project management and waterfall methods proved cumbersome and less than ideal for projects that move quickly and encounter frequent changes.

In 2001, a group of software developers created the Agile Manifesto for agile project management, which includes four key values and 12 principles. The key values are:

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

The preferred values do not require the abandonment of the nonpreferred. For example, agile philosophy does not forbid the use of a plan but instead places greater emphasis on responding to and preparing for inevitable change.

These agile principles became increasingly popular for the software development process, but the philosophy reaches far beyond agile software development. Agile principles are now employed in many different industries, from fashion to biotech to government.

What makes the agile approach different from prior methods such as waterfall is that agile methods are, from the beginning, designed to be iterative, cooperative and flexible. In an agile program management system, projects are created quickly and regularly reviewed, discussed and changed in response to team or customer response. It is assumed right at the start that plans and approaches will have to change, and that there will be no slavish adherence to initial planning. Individual team members are empowered to speak up, without as firm a hierarchy as in other approaches.

Because agile program management is a philosophy rather than a concrete methodology, the specifics of agile practices can vary dramatically from organization to organization, or from program to program. But there are some aspects that are commonly found within agile program management.

Agile program management includes multiple individual projects; both the whole and each individual project might be organized within an agile framework. Agile program management incorporates a holistic, big-picture view of a group of projects. It often includes elements not present in the management of individual projects, such as budgeting, overall strategy and long-term analysis.

Responding quickly to change is a core tenet of the agile philosophy. As such, agile program management embraces change as an opportunity to adjust course and make on-the-go improvements that deliver value to the customer. Breaking projects down into smaller increments for completion enables organizations to be more flexible and pivot more quickly

A key aspect of agile program management lies in an iterative approach. Individual projects within the program go through multiple versions, with product development teams discussing and improving upon the results each time. It’s vital to continually deliver working outputs, whether that’s a whole project or a single aspect. It's also important to refine the product with each iteration based on customer feedback, KPIs and changing requirements.

Agile’s prioritization prizes face-to-face conversation over protracted email or other text-based communication. While an email thread can take hours, days or even weeks, due to time constraints or missed emails, a face-to-face communication can accomplish the same task in minutes.

Agile program management, as an overarching view of a program, needs to maintain a focus on efficiency and removing unnecessary or cumbersome elements. Documentation is a means to an end, not the end itself, and should include only what is necessary.

Honesty and openness are key to a successful agile program. Conversations should enable all team members to speak up. In this management approach, everyone’s voice is valid and heard.

At the same time, it must be acceptable to filter out unworkable ideas without causing the progenitor of said idea to feel discouraged from speaking up in the future. The success of "retrospectives" (or "retros," which are postproject evaluations where feedback is gathered) also relies on team transparency.

Agile program management, as a philosophy, does not require the use of any particular framework. But many project management frameworks, including Scrum and Kanban, have become closely associated with the agile philosophy. Here are a few of the most popular frameworks.

Scrum is a framework for collaborative team project work. The name, though it seems similar to an acronym, actually comes from the sport of rugby, in which a scrum finds players locking arms together for a collaborative push into their opponents. It’s a sort of cavalry charge, without the horses.

In agile, a scrum team includes three roles:

• Project manager: This is the liaison between the scrum team and stakeholders, which could be users, customers or a parent company. The project manager is responsible for communicating external factors such as budget, staffing and feedback to the scrum team, while communicating the team’s progress to the stakeholders.
  
  
• Scrum master: The scrum master is less a traditional “boss” than a teacher of the scrum method, a conductor, facilitating guidance, communication and problem solving. Scrum masters are not typically responsible for hiring and firing.
  
  
• Developers or team members: This term can differ in cases where, for example, the scrum team is in an industry outside of software. Whether this role is called a developer, team member or staff member, this role has no hierarchy. Ideally the team is somewhere between three and nine members in size; larger groups tend to be trickier for a scrum master to guide. This can also include self-organizing teams, in which individuals decide exactly who and what the team needs to succeed without excessive planning from management.

Scrum has a few specific concepts that separate it from other team-based organizational models. The product backlog is a repository of all the tasks, ideas, requirements, deliverables and resources that the team might require during the scrum. It can (and really should) be constantly updated and monitored by the team to help ensure its efficiency and completeness.

In a scrum, work is separated into sprints, typically lasting between one and four weeks. In the sprint, team members work to achieve a specific, deliverable goal. That goal might be a working model, a mockup, a prototype or even just one function or element of the finished product or solution.

During the sprint, team members meet once per day in a “daily scrum,” or a “stand-up.” These meetings are, according to the principles of scrum, to be extremely high level. No longer than 15 minutes in length, the daily scrum finds team members briefly announcing their progress and any blockers that are hindering their work, in as little detail as possible. Sometimes, certain team members might break off into a post-daily-scrum meeting to further discuss something announced in the daily scrum.

At the end of a sprint, the entire team—team members, scrum master and project manager—will meet to review and discuss what has been built. The project manager can convey any changes from stakeholders such as users or the larger organization, and after discussion, the team can incorporate those changes into the next sprint.

Kanban is a visual system for managing and tracking projects. Kanban boards present a visual representation of a team’s progress on a project, in which individual subtasks are filed into one of a few categories. Those categories usually include:

• Backlog: All tasks that have not yet been moved into another category; at the start of the project, all tasks will be in the backlog
  
  
• Doing: Tasks that are in progress
  
  
• In review: Tasks for which the initial completion stage has been reached, that are being assessed by someone else
  
  
• Done: Tasks that are completed.

“Kanban” comes from the combination of Japanese words for sign (“kan”) and board (“ban”), together meaning something similar to a billboard or message board. Kanban can be made in both analog and digital forms. In the analog form, physical Post-it notes are often used for individual tasks, which are then moved from column to column as they’re completed.

There are also many digital versions of kanban boards, which can be especially useful for project teams in which some or all members are remote workers.

Extreme programming, or XP, is an agile methodology originally designed for software engineers to improve software quality, responsiveness and speed. The basic concept is a form of agile, relying on even smaller bursts of testable creation timelines.

In XP, each individual element of an overall project is repeatedly testing, sometimes even bombarded with tests intended to break it. Those individual aspects are then tested together, often weekly, to help ensure maximal compatibility.

In communication, XP relies on simplicity to the extreme. Documentation is intended to be as minimal as possible for other team members to understand, with simple language, concepts and metaphors. This simplicity also extends to the actual design of the task; XP projects are often designed without considering extra features down the road, viewing those as extraneous to the project’s release. This is sometimes known as YAGNI, or You Aren’t Gonna Need It.

XP is not the right fit for every project; it’s important to just use XP for projects that won’t need scalability or significant reworking.

SAFe is a set of principles and practices based around the lean-agile development method, DevOps and systems thinking. The Scaled Agile Framework (SAFe) is designed (as the name implies) for scaling agile frameworks across large organizations to align multiple projects and help ensure cross-functionality and interoperability. This is primarily done through a structure that includes Planning Increment (PI) roadmaps.

Tasks within these roadmaps are referred to in various ways to help identify them from a bird’s-eye view. Identifications include “enablers” (dependencies of other tasks), “epics” (larger initiatives designed for a specific business need) and “stories” (desired functionality, either from a user or a business perspective).

Disciplined agile is considered a set of principles, promises and guidelines rather than a full methodology. It is a lightweight, minimal and hybrid approach to program management with a great deal of freedom for individual team members.

Some agile frameworks, such as Scrum and SAFe, include prescriptive methodologies and steps. This specificity can be great for certain projects, but DA aims to provide more freedom and agility for team members. The basic concept enables individuals to pick and choose which concepts and frameworks are ideal for their particular workflow. Scrum might work for some, but not others, especially within a larger program outlook. DA places a great deal of power in the hands of individuals, which makes it a best fit for projects with team members who are highly knowledgeable, independent and already familiar with basic agile concepts.

Large-Scale Scrum, commonly known as LeSS, is a version of Scrum designed specifically for larger teams, or groups of teams, than Scrum was built to handle. While LeSS still involves sprints, daily scrum meetings and reviews, it has a few extra guidelines to ensure that larger teams accomplish their goals by scaling agile without losing its soul.

In LeSS, all teams work on a common sprint, rather than, as in agile project management, individual sprints planned by individual teams. There is also a shared backlog, complete with all tasks needed for the entire program. And planning for the sprint involves two types of meetings: an overall planning meeting for all teams, and then individual sprint planning meetings for individual teams.

Nexus is a framework that is similar to Scrum, with a few additions, subtractions and alterations. The major difference is the addition of the Nexus Integration Team, a separate group of team members who function as coaches. The NIT often includes members from the Scrum teams, and is responsible for addressing blockages, supplying assistance and coaching the teams through agile processes. The NIT has its own meetings, separate from the daily Scrum.

While Scrum is a phenomenal concept for specific projects within agile project management, when we’re discussing agile program management, we’re really discussing teams of teams. That’s where Scrum@Scale comes in.

In Scrum@Scale, all agile team members are considered part of an interchangeable Scrum team, enabling cross-discipline collaboration. To help with the challenges presented by a larger program in real time, there are a few new team members. The Chief Product Owner (CPO) creates a single backlog for all scrums, and coordinates with the individual product owners. A similar role is the Scrum of Scrums Master, who coordinates efforts between and among Scrum Masters.

Lean is a methodology aimed at reducing inefficiencies and creating continuous improvements to the quality of deliverables. It is often considered to be under the agile umbrella. But while agile is a philosophy, lean is a methodology, with more specific tools and guidelines. Lean is most concerned with minimizing inefficiency and waste, while agile focuses primarily on iteration, feedback and flexibility.

Lean has five main principles:

• Identify value: Essentially, figure out exactly what the goal is, and eliminate anything that does not add value.
  
  
• Map value stream: Use a management tool such as Kanban boards to visualize the product roadmap. Essentially, visualizing the project plan from start to finish.
  
  
• Create workflow: Build out the production process with specific steps, looking for any conceivable obstacles. The goal is to build as fluid a workflow as possible.
  
  
• Establish pull system: A pull system relies on only creating new tasks due to customer demand, and only when team members are ready for more work. This is often done with a task queue.
  
  
• Continuously improve: Use a variety of techniques to continuously create value and improve the product. These might include methodologies and philosophies such as Lean Six Sigma and Kaizen or structured frameworks such as Scrum, which encourage persistent testing and beneficial feedback loops.

Agile program management, with its associated methodologies, provides many ways to improve project delivery.

• Specificity: By continually iterating, agile teams can narrow in on exactly what the customer wants, rather than attempting to blindly improve the entire project.
  
  
• Efficiency: Agile program management includes tenets aimed at reducing waste, documentation and bureaucracy.
  
  
• Versatility: With quick turnarounds in response to customer feedback, versatility is a fundamental part of agile program management. Agile teams know, before a project even starts, that changes will be made during the process.
  
  
• Team morale: Agile program management encourages openness, transparency and empowering individual team members to speak up. Hierarchy is less important than honesty and dedicated teamwork.