Agile processes

Introduction

For a long time, the traditional project management approach has been questioned due to the large number of failing projects. Moreover, due to market globalization and related growing organizational and productive complexity, a need for adaptive continual change and team empowerment has emerged, which have led to more flexible and participatory management approaches (Bartle, 2007). Empowerment is regarded as providing a solution to the age-old problem of taylorized and bureaucratic workplaces, where creativity is stifled and workers become alienated, showing discontent through individual or collective means. This frequent reassessment strategy of agile projects fits naturally in the current portfolio and program management processes, thus suggesting a unifying approach for viewing and planning for the future all the way from the portfolio level to the project level. This paper, after a short introduction of the current state of the art in project, portfolio, and program management, explains how the agile management processes are in line with the portfolio and program management ones to the extent that an agile project can be seen as a sort of micro-program. A short analysis of commonalities and differences, mainly at the project and program levels, is carried out and assumptions are made about how considering an agile project a micro-program can be beneficial. Conclusions are drawn from this.

Traditional and Agile Approaches to Project Management

Traditional project management practices (TPM) were defined and later matured in the world of engineering and construction, where the project team expected, and got, a clear statement from clients as to what they wanted, when they wanted it, and how much they were willing to pay for it. TPM strongly relies on command and control management. Projects follow a very detailed plan that is built before any work is done on the project. Therefore, projects typically begin with a detailed planning phase. The plan is based on the assumption that the goal (i.e., the required deliverables) is clearly specified at the outset. The tasks necessary to execute the project are determined using techniques, such as work breakdown structure (WBS), and the work is organized using tools such as the critical path method (CPM) and Gantt charts. An estimate of how long the development will take is obtained by adding up detailed estimates of the individual steps involved. Once stakeholders have thoroughly reviewed the plan and provided their approvals, the team starts to work. Throughout the process, strict controls are placed on deviations from the plan to ensure that what is produced is actually what was expected. The success of this approach is based on the correct specification of goals during project definition and the initial scoping activities. Continuous monitoring and control activity on a triple constraints target, related to scope, time, and cost variables, is necessary. The project proceeds through a number of sequential phases, known as project life cycle. There is general agreement that the four broad, generic project phases in TPM are the following ones. Notice that common alternative terms are shown in parentheses.

• Definition (feasibility, development, demonstration, design prototype, quantification)
• Execution (implementation, realization, production and deployment, design/construct/commission, installation and test)
• Closeout (termination, including post-completion evaluation)

TPM life-cycle models are predictive and favor optimization over adaptability. They include:

• Waterfall, also known as linear ordering of the phases, can be strictly sequential or overlapping to some extent. No phase is normally repeated;
• Prototyping, which allows for functional requirements and physical design specifications to be generated simultaneously;
• Rapid application development (RAD), based on evolving prototypes that are not thrown away;
• Incremental build, based on the decomposition of a large development effort into a succession of smaller components;
• Spiral, which repeats the same set of life-cycle phases, such as plan, develop, build, and evaluate, until development is complete.

For a long time, the predictive TPM approaches have been questioned due to the large number of failing projects (i.e., substantially deviating from initial objectives: scope, time, cost, and quality). This is particularly true for software projects, but also for all knowledge-based projects, such as innovation or research ones. Some research (Koskela & Howell, 2002), starting from the fact that:

• TPM is heavily dependent on project plans and their continuous updates (management-as planning);
• execution is performed by dispatching planned tasks; and
• project progress is controlled by means of feedback methods like the ones used to control thermostats,

argues that:

• management-as-planning has a high likelihood of failing due to the impossibility to keep plans effectively updated;
• the separation between management and execution is unrealistic;
• the dispatching model for the execution of planned tasks is wrong since it assumes that both the inputs to a task and the resources to execute it are ready at the time of authorization and are in the actual conditions as expected.

Another important cause of failure is that TPM assumes linear processes, in which something changes or progresses straight from one stage to another, and has a starting point and an ending point. However, as another recent research program (Saynisch, 2010, pp 21, 22, 35) contends, “increased complexity in society, economics and technology requires a new and suitable organization and management.” This implies non-linear processes. The research found that “There needs to be a culture of trust, welcoming outsiders, embracing new ideas and promoting cooperation.” To similar conclusions came a group of seventeen software project management and development experts who in 2001 published the “Manifesto for Agile Software Development” and founded the Agile Alliance, a nonprofit organization that promotes software development according to the manifesto's principles. A bunch of adaptive life cycle models, also referred to as “agile,” which empower the development team with management actions, accept and embrace change during the development process and resist detailed planning, got momentum from such initiative and are becoming more and more popular, mainly in the software industry but not only. They include:

• Adaptive software development/ASD, consisting of mission driven, component based, iterative cycles, time boxed cycles, risk-driven, and change-tolerant.
• Extreme programming/XP, which requires teams with developers, managers, and users; programming done in pairs; iterative process, collective code ownership.
• Scrum, similar to above adaptive life cycle models with iterations called “sprints” that typically last no more than 4 weeks with defined functionality to be achieved in each sprint and active management role throughout.

Agile principles emphasize building working products that people can get their hands on quickly, versus spending a lot of time writing specifications up front. Agile development projects focuses on cross-functional teams empowered to make decisions, versus big hierarchies and heavy functional organizations. They focus on rapid iteration, with continuous customer input along the way.

TPM follows the classical Plan-Do-Check-Act (PDCA) quality paradigm. As pointed-out in (Casanova & Bellifemine, 2012), increased complexity of modern developments requires to enhance such paradigm by adding a learning stage and becoming Plan-Do-Check-Learn-Act (PDCLA). This paradigm is consistent with the one followed by agile developments as well as by portfolio and program management. By this continuous learning process the stakeholders can confirm or, if necessary, realign the vision based on results. The learning cycle consists of improved understanding of stakeholder expectations, prioritization of such expectations and development of viable options to enable choice.

Exhibit 1 depicts a typical agile life cycle and the learning enhanced PDCA cycle.

Exhibit 1 – The agile life cycle as applied in SCRUM and PDCLA cycle

In agile projects, stakeholder communication is based on information radiators, which are large visual representations of progress towards the deliverable, rather than status reports found in TPM. Burn-down or burn-up charts as well as Task or Kanban boards are some examples of such visual representations. The goal of the information radiators is to make it clear to everyone and anyone who is interested, exactly what is happening with the project.

Exhibit 2 summarizes the main differences between TPM and Agile approaches to Project Management (APM).

Exhibit 2 – Main differences between TPM and APM

For the TPM philosophy it is necessary that scope should never be changed, even at the expense of time, cost, and quality. A project is finished only when all the scope has been produced as planned, even if this affects its cost, duration, or quality. Plans can exceptionally change but require strict change control management with possible issues of new baselines. Such strategy is represented by means of the so called Iron-Triangle, which is shown in Exhibit 3 for both traditional and agile approaches to project management. In the Iron Triangle, each node represents a variable to be monitored and controlled during the project life cycle. For APM, the triangle is reversed upside-down, with time, cost, and quality that should never be changed, even at the expense of scope. In this approach, scope changes are expected to happen frequently and are welcome because they mean a more adequate outcome towards business value realization. However, it is fundamental that the project team be authorized to make scope change decisions both fast and continuously during the project execution.

Exhibit 3 – The iron triangle for traditional and agile approaches to project management

Although the top benefit derived from adopting agile is the ability to manage changing priorities, some surveys report that organizations mostly adopt agile to accelerate time-to-market (ESI, 2013, p. 4). This is a very limiting approach to the agile methods potentiality. Even in the case of TPM, a project needs to produce a business value, which is defined before it is started by means of a business plan and is achieved delivering customer satisfaction, which is the production of customer value. Does it make sense to deliver what has been agreed at project start if it does not produce customer satisfaction and hence business value for the performing organization? So if the answer is no, why does traditional project management regard scope change as an exception to be carefully controlled? The fact that agile is often used to accelerate time-to-market is the proof that providing incremental Minimal Marketable Product (MMP) is a sensible strategy.

In agile methods, the management functions are shared among the team members, and the project manager role becomes very narrow or even not necessary; mostly it is narrowed down to leadership, facilitation, and coaching. In Scrum, for example, there is no proper project manager and the leadership/coaching function is performed by the ScrumMaster, while the Product Owner is accountable for stakeholder engagement and product requirements definition and prioritization. There is no additional specific role, other than Team Members, although in some cases, an explicit Architect role is present. Some tend to associate the agile project manager function with the ScrumMaster, whereas others assert that the real agile project manager is the product owner. In some cases, the Product Manager can be a Costumer Representative, as typically in the case of outsources projects. In other methods, such as Extreme Programming, the project management function is split among Customer, Developer, and Tracker team roles. The Customer role is mostly equivalent to the Product owner in Scrum. But how much and how well can a Customer representative member produce Business Value for the performing organization in addition to Customer value? This is very important in the case of outsourced contract projects.

Project Program and Portfolio Management

Before the first edition of PMI's Standard for Program Management (PMI, 2006), a program was mostly considered a large project with many subprojects. There was no appreciable distinction between a project manager and a program manager, other than the different level of competence in the profession. Moreover, it was not very clear whether programs and project portfolios could be both considered the same thing from a conceptual point of view and deserved a unique standard. The discussion among volunteers of the standardization team, including myself, came to the conclusion that a project portfolio is conceptually different than a program. We agreed that a portfolio is a way to set a tighter link between organizational strategy and investment initiatives to maximize the strategy realization at the lowest possible cost. On the other hand, we defined a program, a strategic initiative consisting of “a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually” (PMI, 2006, p. 4). This definition has been slightly improved with later versions of the standard (PMI, 2012, p. 6) but remains substantially valid. A benefit is “an outcome of actions, behaviors, products or services that provides utility to the sponsoring organization, as well as to the program's intended beneficiaries” (PMI, 2012, p. 164). We also agreed that traditional projects are tactical initiatives whose main purpose is the delivery of the planned outputs, with no specific consideration by the project team for the utility produced by the prescribed outputs for the organization and project beneficiaries, because such utility should be primarily addressed in other contexts, such as, for example, the program in which possibly the project is included. As already discussed in the previous session, in a traditional project, change that affects the planned deliverables is not admitted and must follow a very strict change control strategy. It should be clear now why a program cannot be considered a large project made of several subprojects, nor a program manager can be considered a senior project manager. The strategic role of a program requires the delivery of benefits as expected by both the strategic plan and the Business Case. The latter includes the program goals, their expected realization cost and the return on investment (ROI) information for the program. This information is mostly synthesized in the Program Charter. Having to deliver benefits, instead of just products and services, is a very important difference that affects management practices. Change is inherent in program management, since it is often needed to adjust the program scope according to the requirements of the strategy realization plans, at the expected cost, time, and quality. From this point of view programs, as agile projects do, carry-on an adaptive process, though they refer to a Program Plan and a Roadmap. Programs adopt an iterative life cycle in order to continuously check the validity of both mandate strategic goals and actual goal realization. They require a constant involvement of the relevant stakeholder in order to take sensible, useful, and timely change decisions.

The latest versions of both the Program and Portfolio Management standards have made the concept of Business Value explicit as the final target for portfolio, program, and project management. They state that business value is “the entire value of the business” and its “realization begins with comprehensive strategic planning and management” (PMI, 2012, p. 13). Exhibit 4 presents a generic simplified view of both the organizational strategy planning and the business value realization approach. Organizational Strategy Planning begins with the definition of the organization's vision and mission. It provides directions for development and growth, stating any performance metrics for success. Such strategy is reviewed regularly, mostly once a year, and is affected by any emerging change driver such as competition, regulatory, economics, financial, and innovation issues.

Exhibit 4 – Organizational strategy planning and business value realization

A strategic plan points out clear strategic objectives and organizational requirements, which affect operations, investments with related initiatives, technology, resources, and quality. Ultimately, business value is produced by on-going operations, which strongly rely on the business value production capabilities of the organization. Such capabilities can be increased by means of strategic investment initiatives, which are implemented by portfolio, program, and project management. Portfolios are essential in order to align investment initiatives to the organizational strategy. They allow the organization to have view and control on how the strategic goals are reflected in the portfolio. Through appropriate governance actions, the optimal allocation of resources with respect to expected performance and benefits, can be authorized.

Agile Projects as Micro-programs

Although even TPM projects are always started to achieve strategic benefits, they are conducted to produce just outputs, whereas agile projects are conducted to produce outcomes, as is the case for programs. There is a difference between outputs and outcomes. According to the Concise Oxford Dictionary, output is the “product of a process,” whereas outcome is defined as a “result” or a “visible effect”; hence, for both programs and agile projects, the final mission is business value realization by delivering outcomes supplying capabilities and benefits to the organization deriving from their mission and vision and, ultimately, from the organizational strategy. For such a reason, this approach is sometimes classified as Outcomes Management, in contrast to the TPM philosophy. However, when business value realization is the final objective, a proper way to adapt must be allowed during the agile project life cycle, though respecting the business case constraints, which might refer to expected scope variability, or duration/cost tolerance, or a combination of them. As explained before, this adaptability is normal for programs and portfolios and is a first conceptual alignment of project management to program and portfolio management.

Another important factor that affects modern project management is growing complexity, which gives rise to high uncertainty and ambiguity, requiring a more flexible and rapid decision-making model, in contrast with the traditional rational one (Thiry, 2012b, ¶2). Uncertainty refers to the inadequate knowledge we might have at project start about future situations and related requirements. It implies risks and it decreases as we move throughout the project, due to continuous knowledge increment about the project. Uncertainty can be reduced by decomposing the project into smaller chunks and managing risks. Ambiguity refers to possible alternative situations from which to choose. While reducing uncertainty is achieved linearly in time, reducing ambiguity is a matter of iterating various times. For example, when we ask a question, the answer temporarily reduces ambiguity. However, answering one question leads to more questions. We ask more questions, get more answers, and each answer reduces the ambiguity related only to that specific question. As Thiry points out, in an ambiguous environment, decisions have to be made before the full impacts are known, and much of what we know is learned through retrospection. Thiry underlines that the combination of the level of uncertainty and ambiguity determines the level of adaptability of the method used in producing the value (Thiry, 2012b, ¶2).

As for programs, agile projects are aware of the initial uncertainty about both direction and outcomes; and they are carried out in a way that a decision can be taken at its best, given all ambiguity factors. Agile projects, like programs, do not commit to a very precise schedule at inception, but do elaborate, clarify, and adjust scope and directions continuously. This is a second common characteristic of agile projects and programs.

In order to analyse in depth the similarities between Program Management and Agile approaches to Project Management we need to start from the Program Management domains as defined in (PMI, 2012, p.17), which are:

• Program Strategy Alignment;
• Program Benefits Management;
• Program Stakeholder Engagement;
• Program Governance;
• Program Life Cycle Management

Agile Project Strategy Alignment

Even the outcomes of projects managed with enough proficiency to meet budgetary and scheduling expectations do not necessarily translate into business value (Symons, 2009, p. 1). As pointed out before, all projects, whether traditional or agile ones, should aim at realizing the business value stated in their business case and in the project charter. A project implementation should always be part of the organizational strategy realization and related business. This should be true for contracted project implementation too, where the organizational value to realize is officially the customer's one but indirectly, the contractor's one too. Although in my experience, particularly in small medium enterprises, I've often seen a lack of proper strategic planning and projects started with some kind of definition of requirements, duration, and budget but without a proper business case or even a project charter, it is obvious this never makes sense and it is often one of the reasons for project failure.

Although agile approaches to project management mostly do not explicitly refer to strategic plans and strategy alignment, agile projects are conducted in a way to produce the maximum business value at the minimum cost and time. As for programs, agile projects are carried-out using an on-going, dynamic approach to oversight as the initiative unfolds. It is not the capabilities alone to be delivered for the expected cost in the expected time, but the capabilities that most suit the benefits required by the business plan, which in a mature organization should derive from its strategy and should help implement its vision and mission.

The way strategic planning should be integrated into agile planning is described in Collabnet (2012), where a five-level planning model is proposed for Scrum as shown in Exhibit 5.

Exhibit 5– Five levels of agile planning

As in the case of programs, an agile project vision describes the long-term directions of the project and its future state. However, here, the term Vision really corresponds to a Project Strategic Plan, since, in addition to the Project Vision, it should encompass also Mission and Goals/Objectives; that is, requirements. This Project Strategic Plan is equivalent to what is defined as Program Plan (PMI, 2012 p. 28). When the project is part of either a Program or a Portfolio, its Vision is not a subset of its Program/Portfolio Vision, but should contribute to it and, ultimately, to the Organizational Strategic Vision and Mission. A Project Roadmap is equivalent to a Program Roadmap and is analogous in the way it is used, when you change Program Components with Project Components.

Agile Project Benefits Management

PMI's The Standard for Program Management (PMI, 2012, p. 34) states that Benefit Management is made of the following processes, applied iteratively:

• Benefit Identification;
• Benefit Analysis and Planning;
• Benefits Delivery;
• Benefit Transition;
• Benefits Sustainment.

Similar processes are applied iteratively in agile projects under responsibility of the Product Owner or whoever is responsible for the business in the team. In the case of programs, initial benefits identification is made during the Initiation Phase with the contribution of the program manager selected by the program sponsor as the only person belonging to the program team allocated to the program in this phase. Program justification, vision, strategic fit and boundaries, benefit strategy, risks, timeline, resources requirement, stakeholder considerations, assumptions, and constraints are defined. Key benefits are identified as outcomes. All this information is documented in the Program Charter and a Program Roadmap is prepared. Although agile methods mostly do not explicitly address this initiation phase, agile projects are initiated in a similar way, and their charter states expected benefits and outcomes, as for programs. The way the project benefits are analyzed and planned is conceptually equivalent to what happens to programs, though less bureaucratic.

Both program and agile approaches to project management develop final outcomes in a cyclic, iterative way, with continuous realignment based on measured transitional results, to ensure stakeholder value is properly delivered. Both put a great focus on prioritization of effort and understanding of requirements, which is definitely a value management approach. As Michel Thiry underlines in one of his articles (Thiry, 2012a, ¶8), the issue with both agile and program initiatives is that development occurs in parallel with delivery, which is not the case for traditional project management. The article goes on: “value is the balance between the satisfaction of the needs and the resources used to achieve this satisfaction: the greater the satisfaction and the lower the resources used to satisfy them, the higher the value. In a project it translates by achieving the highest possible scope and quality within the lowest possible time and cost”. In order to do so and produce the planned benefits, it is necessary that change becomes opportunity rather than risk. Moreover, as pointed out by Henry Mintzberg (Mintzberg, 1994, p. 176) changes can be disruptive if they do not happen as increments “at the margin” with respect to the planned strategy, because they produce comprehensive reorientation. These change opportunities can be realized if stakeholders, such as Project Sponsors or final users’ representatives, are continuously involved with timely decisions, as the initiative evolves and formal change authorization is required for important changes. This is what happens to Programs by means of program governance boards or program steering committees and change control boards. As described further, agile approaches to project management use similar control mechanisms, though in a simpler and more immediate way.

Agile project requirements are never stated in a very detailed way. At project start, enough modelling is made just to understand the requirements at a high level. Requirements are detailed and made more precise as they are needed on a just-in time basis. Also, requirements are mostly elicited by means of user stories, which really are about situations and needs rather than precise expected behaviour, like in use cases for traditional software development. The difference is such that developers are left with a degree of freedom in delivering what best suits both situations and needs described by the user story. In addition, when for some reason a user story needs to be changed/cancelled or a new user story needs to be added, due to either additional knowledge gathered or new situations and needs arose, agile change readiness philosophy allows for making fast decisions because of the continuous support of some user/customer representative, such as the Product Owner in Scrum. In Scrum, Project Sponsor, Product Owner and ScrumMaster together can make fast and important change decisions consistently with both expected strategic alignment and customer value. This is equivalent to having a sort of change control board and even a project steering committee, as in the case for Programs, though in agile projects, such boards are always active and can make very rapid decisions. Naturally, when an agile project is part of a program, then the program manager should be involved as needed in important project decisions that might affect the planned strategy.

Benefit realization is difficult to measure and in many cases it cannot be measured and controlled without real application of the outcomes produced by the project. The continuous support of a customer/user representative, the iterative development approach, and the continuous deployment strategy of agile projects are very effective ways to measure and control incremental benefit realization by means of timely feedbacks by all relevant stakeholders.

Agile Project Stakeholder Engagement

In program management, Stakeholder Engagement is a very important activity delegated to the program manager. It is conceptually aligned with the TMP Stakeholder Management processes and is conducted in a similar way. Managing stakeholders is not always possible, of course, and it is not the purpose of this management activity. Therefore, here, more properly, we talk of Stakeholder Engagement to actually mean the management of Stakeholder Engagement and the engagement activities too. This is all about the correct communication with all key program stakeholders, so that they can be continuously informed about the program progress and kept aligned. But it is not only about communication. It encompasses relational aspects and negotiation. It starts identifying both the program stakeholders and how the program will affect them (e.g., the organization's culture, current major issues, resistance, or barriers to change, etc.). Then a communication strategy to engage the affected stakeholders is developed, their expectations are managed, and their acceptance of the objectives of the program, are improved. In the project/program management world, needs and expectations are considered as two separate issues. A need is typically defined as an explicit requirement, whereas typically, expectations are undefined requirements. Agile management, like program management and TPM, cannot afford to consider only existing and declared needs, but must also strive to uncover undeclared and potential needs, usually labeled as expectations. Stakeholder Engagement, in both traditional and agile contexts, builds on this concept by involving customer in the whole process of decision making to ensure that not only needs but also expectations are met. Only a sound stakeholder engagement process will enable the identification and realization of significant benefits, those that matter. In traditional management a stakeholder management plan, combined with the communication plan, delivers accurate, consistent, and timely information that reaches all relevant stakeholders as part of the communication process to facilitate a clear understanding of the issues. Communication planning and execution should focus on the proactive and targeted development and delivery of key messages, and engagement of key stakeholders at the right time and in the right manner.

In agile projects, stakeholder engagement is even more important and it is accomplished much the same way. However, a less bureaucratic approach is taken. In APM, as in the case of TPM, at program start, Stakeholder Identification is accomplished producing a stakeholder register and a stakeholder engagement plan is defined, which drives the kind of effort to be spent to keep stakeholders engaged and how to do it with each stakeholder. Team collaboration is required in analyzing stakeholder engagement requirements, using similar techniques as those for TPM and Program Management. In particular, at project start, a Stakeholder Map and a very simple Stakeholder Management Plan is collectively built by the team, defining stakeholder priorities, engagement needs, and required engagement actions. In some cases, stakeholder engagement is not limited to planned communication alone, but requires direct and continuous involvement of some stakeholder category, such as final users and customer representatives. As for any agile plan, this stakeholder management plan is continuously adapted as needed in the development cycles.

Agile Project Governance

Project and program governance is the process of developing, communicating, implementing, monitoring, and assuring the policies, procedures, organizational structures, and practices associated with a given project or program. The result is a framework for efficient and effective decision making and delivery management focused on achieving project/program goals in a consistent manner, addressing appropriate risks and stakeholder requirements.

As we explained earlier, traditional governance style is very bureaucratic and assumes both formal base-lined up-front planning and strict change control. Agile methodologies are taught so as to assume some sort of taskforce teams, which are temporary projectized multifunctional organizations, where people are uniquely allocated to the project team during the entire project execution and cannot be shared. But the intention is to have self-managed task forces without a head. Normally this produces a kind of fracture with the rest of the organizational context in which the agile project belongs, which is still hierarchical and managed in a command and control fashion. In this situation (i.e., until the agile philosophy will not have imbued all the chain of control upward), a kind of junction role between the upper part of the chain and the agile part is likely to be needed, particularly in more complex situations, such as the case of a large agile project with several agile teams or large traditional projects with some agile subprojects or even agile work packages, which is the case in large infrastructure projects or in projects where software is a commodity. The point is that delegating does not imply losing control. For delegation to properly work, it is essential that everybody in the team understands boundaries and constraints around decisions. It is essential to make clear who make the decision and when and watch over the respect of rules. In general, an agile project manager should be less involved with the team's day-to-day work and concentrate more on the big picture and on his or her leadership and coaching influence. Therefore, Agile Governance assumes a different adaptable and flexible management style and is based on trust and empowerment of the project/program team. As it will be more clear later, this governance style is conceptually very close to the program governance style, although less bureaucratic.

Agile Project Life Cycle

As for TPM, agile projects are activated inside a strategic business context. Exhibit 6 shows such a context. We have already pointed out that even in the case strategic planning is not carried out, at least a business case, and a project charter is needed at project initiation. In Exhibit 5 we showed how strategy should affect agile planning at the highest levels. From a general standpoint, the project Agile Life Cycle is the same as for TPM and is the one shown at the lowest level in the figure below. However, in the agile context, the philosophy under which each phase is executed is different at various degrees, from the command and control process of TPM. The “carrying out the work” project phase is the one with the most relevant difference.

The correspondence between the program versus project phases can be deduced as follows.

Due to the fact that agile phases, as the corresponding program ones, are outcomes oriented rather than outputs oriented, for agile projects the correspondence with program phases in not only structural as is the case for TPM.

Exhibit 6 – Integrated portfolio, program, and project view

In particular, an agile “Carrying Out the Work” phase is iterative and develops in a way that project outcomes can be realized incrementally, applying those changes that are needed to the goals realization, just as “Program Benefit Delivery” for Programs. The processes followed by each corresponding phase is not exactly the same, of course, but similar and conceptually equivalent. In particular, agile phases are necessarily less bureaucratic, simpler and stress team empowerment more than program phases do. Both the Project Starting Phase and the Program Formulation one are ultimately meant to produce a Charter. Program and Project Charter are very similar, expressing, among the other things, initiative justifications, objectives, and requirements. For an agile project, requirements are expressed as expected high level project outcomes, which are the starting point for initial backlog definition. This will be later decomposed in order to define required features using a Feature Breakdown Structure similar to the TPM's Work Breakdown Structure. In agile development, a feature is a chunk of functionality that delivers business value. At the highest level, this backlog is conceptually equivalent to the program Benefits Register. As for the latter, features are organized, described, ranked, and related to business goals. Agile project governance is much less bureaucratic and much more collaborative and sense-making than program and portfolio governance but both management styles are outcomes oriented, incremental and change enabled. After all, there is little conceptual difference between a program and an agile project and this supports the idea that, like in the past a program could be considered a large project, when outcomes management style is applied, an (agile) project can be considered a sort of micro program.

Unifying the Project, Program and Portfolio Approaches

The discussion so far has been made to point out that agile approaches to project management are essentially executed with the same principles of programs. We are not going to discuss in-depth Portfolio Management, but even such level of management belongs to the outcomes management category and shares important commonalities with agile management. However, we have seen that there is normally a very significant fracture between the higher level of traditional governance, such as Organizational, Portfolio and Program Governance, and the lower level, Agile Project Governance. Currently, agile projects are mainly small IT initiatives that are able to use a single multifunctional team made of up to 7 to 8 people. Many upper-level governance tasks requiring traditional bureaucracy, interfere with the agile approach and with its “sense-making” decisional mechanism, as pointed out by Michel Thiry (Thiry, 2012c) with the following schema that harmonizes predictive and adaptive governance. After all, a traditional project manager macro-manages the projects results according to a predictive baseline, while the agile team micro-manages iterative development cycles according to adaptive planning. This approach constraints agile methods for just development and does contain all the disadvantages of TPM. For example, how can a traditional project manager control project progress without slowing down agile cycles and related decisions? How can it be possible to reconcile up-front plans with agile cycles without flexibility in such an up-front plan?

Exhibit 7 – Predictive and adaptive harmonization

If an agile project is managed as a micro-program, then the predictive layer can be changed with a more appropriate flexible layer that uses a value-oriented plan and a roadmap to take care of the project adaptive cycles and to ensure successful delivery of the project vision. In addition, a project could not be limited to a single team development but could include more than one agile team and even traditional subprojects. Some small adaptation of the program, portfolio and agile governance could be needed for a smooth integration but this does not seem necessary. Currently there are various proposals to scale up agile development to multiple teams and to upper levels of project management, such as programs and portfolios (Leffingwell, 2013). Such proposals are conceptually in line with this approach, though more difficult to implement and manage, since they actually scale the agile process upwards. They are not something that can be relegated to the software development context alone and would retain all the current contractual problems of agile projects.

Conclusions

It is obvious that all characteristics that align program management processes to agile approaches to project management processes, discussed earlier, promote the idea that a project, if seen as a sort of integration infrastructure for agile and traditional subprojects, can be conceptually considered a micro-program and managed as such, scaling down its program governance requirements as needed by its dimension and criticality. In this assumption, the role of a project manager becomes equivalent to the program manager's; hence, it gathers new value and consideration, after it has been seriously questioned by agilist gurus. This approach is important also to allow for agile applicability in context where up-front planning is mandatory, such as public administration, defense, and public tenders.

Agile is not a methodology but rather a philosophy strongly relying on empowerment and trust of people: a very positive world, where everybody is stimulated by common achievement. It is a social approach, where the interest of a single person must be in tune with the interest of the working community and the organization cannot survive without a true consideration for the single employee, because every employee is an essential part in efficiently realizing the business goals. The appropriate consideration of people, the way they feel and are able to make other people feel, are already regarded as a very important factor for business success and is becoming even more important in agile contexts. However, with agile philosophy such “emotional intelligence” goes much further, since team members are accountable for project direction and success. Each member is singularly and collectively responsible for such comprehensive business value realization and being able to capture and correctly interpret and positively manage their emotional behavior is the real challenge for future leaders. In the agile approach, management is a team task whose quality depends on the leadership quality. All this looks like an ideological approach, and perhaps, it is such for some part. The mental switch to be used in order to make this philosophy work across the whole organization is very critical, risky, and requires time. Agile approaches to project management are only a very small part of it; indeed, agility cannot be relegated to projects alone, because a project is never organizationally isolated. To make agile management work, it needs to imbue the whole organization, which looks a bit too difficult since at its extreme it would possibly lend itself to anarchical management. Indeed, some proposal are already available on how this could be accomplished (Leffingwell, 2013) and they look quite interesting. I am not sure, though, that scaling up agile methods to produce comprehensive agile organizations can be achieved in a short period with success. On the other hand, as we say in Italy, you will never get an anywhere without starting.