6 The Agile family: Group II

In addition to the Agile methods outlined in Module 5, there are two more primary methods that we will discuss here.

Extreme Programming: short work sprints, frequent iterations, constant collaboration

Extreme Programming (XP) was briefly introduced in Module 2. We’ll spend more time explaining this methodology here, because it is just as important to the Agile group as it is to  the uncertainty group of methodologies.  XP is defined as an Agile project management framework (also referred to as a software development framework). The aim of XP is to produce improved quality outcomes, including product outcomes, and the workflow and work culture of the project team (Wells 1999; Beck 2004; Blokdyk 2017; Smith 2019). Of the Agile frameworks, XP specifies more clearly the need for proper engineering practices along with the use of the Agile framework.

To apply XP, there are specific characteristics a project should have (Wells 1999):

• ongoing changes to requirements
• potential impact of risks associated with allocating fixed times, especially with innovative technology
• small teams who are co-located
• technology that allows for automation of functionality supported by testing.

Values

There are 5 primary values of XP project management (Wells 1999; Beck 2004):

1. Communication. A vital component in the process is transferring knowledge from team members to support the broader project objectives. There needs to be clear communication mechanisms. XP prefers face-to-face mechanisms.
2. Simplicity. This considers the minimum viable product or outcome. Therefore, the aim is to simplify the design and process as much as possible, to support the project outcomes, maintain momentum and revise and improve as needed.
3. Feedback. This needs to be obtained from clients, stakeholders, and team members at frequent intervals to understand what works and what does not. The aim is to improve and rework practices, and support designing simple outcomes.
4. Courage. This is defined by Beck (2004:20) as ‘effective action in face of fear’. Therefore, XP is based on taking actions to obtain results, based on the other values. These actions relate specifically to team effectiveness, reduction of waste and obtaining and using feedback.
5. Respect. There needs to be mutual respect between the team members as this will support open communication and working collectively to achieve outcomes.

Practices

There are many XP project management practices and they are all interconnected and support the successful delivery of a project (Wells 1999; Beck 2004; Blokdyk 2017; Smith 2019). There are 12 practices that fit within 4 categories:

1. Fine Scale Feedback

Pair programming: this requires 2 team members working collaboratively on one machine. The purpose behind this is that 4 eyes are better than 2, allowing for effective code review and problem-solving.

Planning game: per iteration the planning game is played. It is used to support delivery of outcomes. There are 2 parts:

•  Release planning – focus on what will be included in the next releases, and when they will be delivered. This includes the project team (developers) and customers. There are 3 phases within release planning:

Exploration – clients provide a list of requirements, documented on user story cards.

Commitment – developers will commit to developing the functionality within the next release.

Steering – plan may require adjustment, and new requirements can be added to the plan.

• Iteration planning –  this requires the planning of activities and tasks for the developers to complete. This is also divided into 3 phases:

Exploration – requirements are translated into tasks, which are recorded on task cards.

Commitment – tasks are assigned to the developers, along with a specified timeframe for completion.

Steering – tasks are completed and the results are tested against acceptance criteria.

Test-driven development: tests are completed to assure the functionality of outputs; these are determined before the outputs are delivered. This encourages the developers to consider the potential issues that could occur after the delivery of a task.

Whole team: the client needs to be a key part of the development of the project outcomes and testing; this ensures that the outputs are fit for purpose.

2. Continuous process

Continuous integration: the project team needs to be always working on the latest version or requirements of the outputs. This requires a clear process of version control and is especially relevant for software development and continuously updating code to meet the teams’ updates.

Design improvements: due to the aim for simple outputs, there is a need to complete ongoing maintenance during the project. This includes functional improvements or upgrades and the flow-on effect of different changes that occur during the project.

Small releases: frequent releases of outputs are completed to provide ongoing value to clients. This supports the idea of the client being a key part of the team, and the importance of feedback.

3. Shared understanding

Straightforward design: based on the simple is best model, this requires developers to consider if this is the simplest way to introduce a new function or requirement.

Coding standard: also referred to as design standards. This is where a set of rules are developed and agreed upon by the entire project team. These need to be adhered to, ensuring a consistent style and format.

Collective ownership: this refers to shared team ownership, where everyone is responsible for the outputs and outcomes. Therefore, anyone is allowed to make updates to code, and everyone is responsible for maintaining it.

Metaphors: this involves the development of a story or concept which everyone within the project understands and shares. This requires the developers to provide clear names and descriptions for functionality provided.

4. Programmer welfare

A realistic and sustainable pace: this is the idea that developers should work a maximum of 40 hours per week. Where overtime is required in one week, this should not follow onto the next week.

Within these principles there are a few additional components (Smith 2019):

Stories: provide a clear description of what the outcomes will be for the project, specifically describing what is meaningful or necessary for clients. These provide short descriptions of the work required.

Weekly Cycle: forms an iterative period, where the project team collaborates on the first day to discuss progress, liaise with clients, determine the next set of requirements and discuss the next steps.

Quarterly Cycle: defined as the release period. The detailed work is completed as part of the weekly cycle; however, the work is planned in quarters to understand what the release will look like.

Slack: these are the low priority tasks within both weekly and quarterly cycles that can be cancelled if the work is falling behind.

Key roles and responsibilities

There are several specific roles that need to be established within the application of XP (Wells 1999; Beck 2004). The 4 most common include:

1. Client/customer – responsible for making business decisions regarding the project outcomes. This requires considering:

What does the system need to do?
What are the acceptance requirements?
How much do we want to spend?
What is next?

2. Developer – project team members are labelled developers. They are responsible for delivering work to the client. A developer can be anyone in the project team, and it is not limited specifically to skill sets.
3. Tracker – the person responsible for keeping track of the work underway to determine progress against plan.
4. Coach – commonly an outside consultant who supports the application of XP. They mentor the project team on the XP practices and support establishing healthy habits and behaviours.

Extreme programming life cycle

The life cycle can be broken down by both weekly and quarterly cycles and the steps below and within Figure 21 show the specific steps (Wells 1999; Beck 2004; Blokdyk 2017; Smith 2019).

_{Figure 21. XP life cycle, by Carmen Reaiche and Samantha Papavasiliou, licensed under CC BY (Attribution) 4.0}

Step 1. Liaising with clients. This step requires liaising with clients or customers to understand what their requirements are. This involves establishing stories, which are broken into timeframes and corresponding tasks. Value is also assigned to certain stories to understand their importance to stakeholders and clients.

Step 2. Planning. Planning begins for the next release; it is based on team agreement through the planning game. The first plan creates a roadmap for what will be completed within a release period. Planning considers the relative value of each story and determines linearity and dependencies between tasks. This will also be completed at the weekly cycle level – each week the team will get together to understand what work will be completed during that week. The stories are broken into achievable tasks and allocated.

Step 3. Linking. Links are made within the planning phase, where considerations are made to ensure that the planned work and stories are designed in a simple and straightforward manner.

Step 4. Coding and development. This phase requires the implementation of the design through creation of outputs. Within this phase there is a need for continuous improvement, where ongoing feedback and support is included in future designs. This phase also includes the principles of continuous integration and pair programming.

Step 5. Testing. Within this phase the project team goes through testing each of the new requirements developed. This ensures that the completed items meet the acceptance criteria and functionality checks established previously.

Step 6. Release. This requires handing over the completed components to the clients or users. These steps happen in cycles, and at both weekly and quarterly cycles the cycle will begin again.

Advantages of XP

There are advantages to applying XP project management, including:

• close working relationship with client
• avoiding unnecessary work
• stable outputs through continuous improvements and testing
• reducing errors through pair programming
• teams work at their own pace, with a focus on work–life balance
• flexibility in deliverables
• the code or supporting material is clear and easy to follow.

Disadvantages of XP

There are also disadvantages to applying XP project management, including:

• creation of additional work
• requires client participation
• requires large schedule or time investments
• usually costly
• version management can be complex
• self-discipline is necessary to practice XP properly.

In sum, XP project management requires ongoing management and understanding of client and customer requirements. The outputs of the project should be based on the specific customer needs and expectations, along with their ongoing feedback. Due to the flexible nature of these needs, XP includes continuous improvement. It has been defined as one of the most radical forms of agile project management and its application supports the project team to be creative, while also ensuring simple and straightforward designs.

Adaptive Project Framework

Adaptive project management (also referred to as Adaptive Project Framework or APF) is a structured approach. This project method requires the progressive improvements in decision-making processes, based on feedback obtained from previous phases in the project (Shenhar and Dvir 2007; Wysocki 2010; Silber 2017). The entire project team, along with the project manager should learn from, adapt to, and accept changes as they arise. This is especially important as the client is key to APF – they are at the centre and as a result need to be involved in the end-to-end management of the project.

The focus of APF is adapting to changing requirements, environments, and client and stakeholder needs. This is a unique project methodology, based on systematic client controls over the project details (Shenhar and Dvir 2007; Wysocki 2010; Silber 2017).

How it differs from other methods

Within traditional and sequential project management, the techniques are clear, static, and straightforward. The plan for the project is broken down into tasks, resources, and activities. The project manager and the plan keep the project team and project on track. However, the changing environment, market conditions, client expectations, and technological advances (Shenhar and Dvir 2007; Wysocki 2010; Silber 2017) have impacted project management. Specifically:

The way work is undertaken is constantly evolving, impacted by the advancement in technologies.

Organisational strategies are becoming harder to develop, predict and adapt in response to changes in the market and environment.

The management of people has also changed, requiring increased collaboration between team members, and changing working environments.

Adaptive project framework

• Cyclical planning.
• Tasks and resources scheduled to each cycle.
• Client involvement ongoing.
• Future state clear.
• Prioritisation of tasks early on.

Traditional Project Management

• Planning completed at the start.
• Resources and tasks scheduled early.
• Client communication at planned intervals.
• Fixed outcomes.
• Prioritisation per requirement.

APF is designed to support the adaptive work culture, encouraging team members to improvise when issues arise and respond to them appropriately.

APF phases

There are 5 key steps or phases within the APF. Although it is defined as an iterative or cyclical approach, there is a sense of linearity within it. However, within this linearity, there is an in-built cycle, allowing for reviews, improvements, and updates (Shenhar and Dvir 2007; Wysocki 2010; Silber 2017). The phases are outlined in Figure 22 and described below.

_{Figure 22. Phases of APF, by Carmen Reaiche and Samantha Papavasiliou, licensed under CC BY (Attribution) 4.0}

Phase 1: Project scope. At the start of any project the first and crucial step is to identify the objectives of the project. This step should also consider what the customer or client requirements are, and how the project will encourage collaboration between clients, the project team and key stakeholders (Shenhar and Dvir 2007; Wysocki 2010; Silber 2017). Within the project scope there are 5 key components:

• Conditions of Satisfaction (CoS). The CoS needs to be identified, with input from stakeholders and the project team. This document should outline the requirements, goals, and desired outcomes. Therefore, a clear CoS would provide details on how to take steps towards the desired outcomes, support communication of work underway and completed, and provide approval or stage gates to proceed to the next project phase or requirement.
• Project overview Statement (PoS). This should be the outcome of the CoS. The PoS should outline the approved CoS, which is endorsed by all stakeholders. The document should be used to help the project manager evaluate the project. Following the APF, the PoS will be updated when CoS changes are required.
• Requirement prioritisation. Collaboration between stakeholders and the project team is required to create the end-to-end project scope. When prioritising requirements, there needs to be a clear order of tasks which support outcomes in a realistic manner. Consideration is needed to ensure that critical requirements or tasks are not missed and that the dependencies between tasks are documented.
• Work Breakdown Structure (WBS). Creating the WBS requires breaking down the different project requirements into tasks or activities which can be completed by an individual. Developing the WBS supports the estimation of budget and creation of schedule. Each task is allocated a duration, dependencies, sequencing, and resources to understand their criticality. The WBS is used to support conversations with stakeholders and set a baseline for the project progress.
• Scope triangle prioritisation. The final component of this phase is the evaluation of the scope triangle. The scope triangle is also referred to as the project management triangle or iron triangle (Atkinson 1999). The triangle is concerned with the constraints on quality, due to the impact of cost, scope, and schedule. Constraints identified within the evaluation are classified as adaptable, inflexible, or trade-off-possible.

Adaptable constraints can be changed or evolve to meet changing needs through negotiation.

Inflexible constraints are crucial and have no negotiation or room to change.

Trade-off-possible can be used to compensate for other constraints if or when issues or changes arise.

Phase 2: Cycle Schedule. As there is now clarity around the project scope, the end-to-end project is broken down into iterations/cycles (or mini projects). These iterations are planned according to their complexity, length, number of tasks and available resources. The cycle aims to produce deliverables (one or two) (Shenhar and Dvir 2007; Silber 2017; Wysocki 2010). There are 4 primary steps that should be followed to create the schedule:

1. Tasks within the WBS need to be defined

Activities that are required to be completed during the cycle need to be identified from the overarching WBS. The tasks should not exceed the planned cycle duration.  Where there are too many tasks , those non-critical items should be move to the next future cycle.

2. Task dependencies outlined

Through the WBS for the cycle, the dependencies should be identified and documented. This could follow the Critical Path Method or network diagrams to highlight task sequences. The dependencies should highlight critical tasks, along with resources required to complete tasks.

3. Tasks are grouped and assigned to project team members

Tasks should be assigned to a team member or group of members, based on the cycle’s WBS and dependencies. Where dependencies between tasks exist, there should be close working relationships between project team members responsible for their outcomes.

4. Effective work schedule is created

A timeline should be mapped and provide a view of the entire cycle and the tasks allocated to specific team members and groups. The schedule needs to provide details of the duration, resources, dependencies, assumptions, constraints, budget, and quality expectations. The schedule created should only include work that is achievable within the cycle’s allocated duration.

The project goal needs to remain in focus, priority towards tasks should be determined early, deadlines need to be set and linked to the dependencies.

Phase 3: Cycle build. Complete the work required within the iteration. Tasks are completed by team members based on their allocation, cycles are adjusted as required, and pending tasks can be moved or changed based on cycle needs (Shenhar and Dvir 2007; Silber 2017; Wysocki 2010). Cycle build requires following the plan set out in the schedule. This includes:

• undertaking agreed upon and scheduled work
• monitoring and controlling progress and adjusting as required
• completing the cycle at the scheduled date
• reallocating pending tasks or uncompleted tasks to the following cycle
• documenting feedback and considering improvements
• tracking problems and implementing solutions.

Supporting activities within the cycle build phase include:

• Developing a detailed schedule. This detailed schedule should outline the roles, responsibilities and work required of each individual project team member. There is no set format for how this is documented, it can be a to-do list or a formalised process.
• Critical tasks should have a clear path to completion. This will support succession planning in case of unexpected absences or planned leave, enabling work to continue.
• An issues register should document any issues or problems faced during a cycle. The register should include what the issue was, who raised it, who resolved it and how.
• A scope bank should be created for each cycle to document any potential changes required or tasks incomplete at the end of the cycle. This will enable the team to carry them over to the following cycle.
• Daily team meetings should be held to share progress updates, potential blockers, and the need for support and next steps.

Within the cycle build, where a deliverable is incomplete in a cycle the tasks are carried over to future cycles. The improvement or process changes are responded to within the process, and as a result communication with stakeholders is required throughout. Within the cycle build phase it is important to remember never to extend the cycle’s duration and not make changes during the cycle.

Phase 4: Client checkpoint. This is a vital step in the APF. Within this phase, feedback is provided by stakeholders around what was delivered in the previous cycle build. The client is given time and the opportunity to review the quality and functionality of the deliverable and provide improvements or feedback (Shenhar and Dvir 2007; Wysocki 2010; Silber 2017).

Through the completed analysis, project managers liaise with the clients and stakeholders to adjust the upcoming schedule or deliverables as needed. Where adjustments are made, any changes are documented and consideration is given to how quality will be assessed.

There is a cyclical relationship between phases 2, 3 and 4. These phases continue to repeat as part of a process, where the project manager and team update the plan/schedule, which impacts the cycle build and the review cycle. The cycles continue until the scheduled end date or the project is completed (whichever comes first). An overview of the requirements of phases 2 to 4 are outlined in Figure 23.

_{Figure 23. Phases 2 to 4 cyclical overview, by Carmen Reaiche and Samantha Papavasiliou, licensed under CC BY (Attribution) 4.0}

Phase 5: Final report. This report is used to evaluate the success of the project. This is a collaborative effort between the project team, stakeholders, and client (Shenhar and Dvir 2007; Wysocki 2010; Silber 2017), whereby all the potential successes and failures are documented, improvements are considered and experiences are shared. The final report should support future projects.

Benefits to APF

There are benefits documented to support applying APF, including:

• Client-focused: the project team aim is to deliver outcomes based on the needs outlined by the client, based on the documented scope.
• Client-driven: clients are included at each phase; they are meaningfully involved throughout and support the changes and progress.
• Change-focused: adapting to changes quickly is important, especially when they impact the solution or outcomes provided.
• Prioritisation of requirements: through the prioritisation of the different requirements, those key activities or tasks have been identified and can be completed. Whereas tasks deemed not critical can be held until time permits.
• Continuous feedback: open communication is crucial, and stakeholders, clients, and project team members can all provide feedback. This supports the delivery of results.

Disadvantages to APF

There are some potential disadvantages to applying APF, including:

• Ambiguity in process due to flexibility: unclear scope or tasks can cause issues in the planning, as not every detail has to be known as part of APF. Projects can fail due to the lack of clarity associated with the overarching end state.
• Following cycles causes difficulties. As cycles are not flexible, change requests need to wait to be completed until the following cycle. This wait time can cause frustration for clients and stakeholders who want to see results sooner.
• Scope creep occurs often. As there is no specific path to the completion of the project, there is an opportunity for scope creep. There is a risk of the budget running out before the requirements are completed, therefore APF requires a strong and experienced project manager to manage expectations.

When to use APF
There are certain situations where using APF may be appropriate for a project, most commonly when the project has a specific goal or outcome with no specific solution in mind. However, there is also a need for the project organisation and clients to meet certain characteristics. It must:

• be responsive and adaptive to change
• be innovative and willing to experiment
• encourage failure to spur iterative improvements.

In sum, APF is a non-traditional project management methodology that encourages ongoing change throughout. Using APF requires putting the client at the centre or focus of the project work, encouraging their feedback and input, making updates or iterative improvements as asked and learning from experience. It is a cyclical approach that requires planning at each iteration and heavily involves stakeholders and clients throughout. It can be a challenging form of project management to implement without experience, and it requires ongoing monitoring and controlling to support the achievement of outcomes.