What is the Agile concept?

Agile methodologies versus traditional approaches

New business realities and the current VUCA (Volatility, Uncertainty, Complexity, and Ambiguity) environment is prompting organizations to explore new ways of working, embrace continuous learning, increase responsiveness, adopt shorter cycles, and emphasize better internal collaboration.

Traditional project management approaches rely on predictive analyses of what customers want and make detailed planning before developing and testing.

They follow a sequential approach starting with collecting requirements, then following up by designing a solution, developing it, testing it, and concluding with the implementation of a finalized and complete product.

In reality, customers keep changing their minds as the market constantly evolves. The final product is not likely to meet all the changing needs of the customers, and unexpected requests or events can disrupt neatly planned processes. A rigid project framework or organization structure with fixed roles, rigid planning, complex processes, and lengthy policies can be cumbersome when business requirements are changing fast.

In contrast to traditional approaches, Agile frameworks rely on an adaptive method focusing on limiting upfront planning and on having a series of working deliverables brought to customers regularly (incremental approach) to understand their needs and use their feedback to constantly improve and add new functionalities.

Agile teams are cross-functional and self-organize with the help of a facilitator (Agile coach /scrum master) to deliver solutions answering the needs of the stakeholders represented by a product owner.

Applying Agile to HR management

HR, and more specifically global mobility management, can lend itself to Agile approaches.

HR business partners are already playing the role of interface with the business – a role not unlike the one of a product owner in an Agile project.

Global mobility teams include specialists from different fields (e.g. tax, compensation, relocation, HR technology), and a multidisciplinary team is exactly what an Agile team should be.

Furthermore, pressure is mounting on HR to adopt an Agile approach as other departments are also implementing it. HR cycles are shortening: assignee deployment time has to be faster to respond to new business realities.

Expectations of employees and especially the new generations are evolving: they strive for faster career development and more frequent performance and salary reviews. More generally, both assignees and line management are asking for more flexibility in the way HR is operating.

In response to these changes, Agile frameworks can be introduced to:

• Reorganize the whole HR function and the way it delivers value to the business. For example, break down part or all of the HR department into multidisciplinary teams to increase speed and adaptation and bring down barriers between teams. (Think about bridging the traditional gap between talent management and mobility teams.)
• Improve the responsiveness and flexibility of the global mobility team and especially the way projects are managed (e.g. development of new policies, technology implementation, and large relocation exercises).
• Expand the toolbox and responsiveness of HR teams by introducing elements of Agility in their daily practices.

Original Agile Manifesto (IT focused) and possible interpretation for HR

Agile encourages…

Individuals and interactions over processes and tools

The focus is on ensuring that team members work effectively together rather than on establishing formal roles and processes.

• Avoiding siloed teams.
• Fostering a collaborative approach and positioning mobility professionals as internal consultants to the business rather as a part of a rigid structure.

Working software over comprehensive documentation

Highly detailed documentation is not sufficient if it is not supporting a fully functional solution that meets the customer’s needs.

• Stressing that successful talent deployment is the mark of success and not long policies.
• Avoiding the traditional disconnection between official speech/policies and the realities of mobility in practice.

Customer collaboration over contract negotiation

Contracts and written agreements are important, but they don’t replace on-going collaboration between stakeholders and customers.

• Establishing a relation of confidence with assignees and internal stakeholders (line management, local HR).
• Meeting the expectations of each expatriate group though targeted employee value propositions.

Responding to change over following a plan

Not all issues and requirements can be anticipated, and business realities change fast. Teams should be adaptive rather than trying to adhere to a pre-defined rigid plan.

• Coping with faster international talent deployment and changing requirements. The flexibility should not just be in policies (multiple options) but also in the processes.
• The mobility team should be able to quickly re-organize itself to face new challenges and tap into the expertise of its members as needed without being constrained by rigid roles/job descriptions.

How does it work in practice?

The agile methodologies rely on a specific terminology that fosters collaborative and adaptive teamwork instead of rigid and bureaucratic thinking.

Agile terminology

Waterfall: The traditional way of project management based on rigid planning, fixed roles, and responsibilities, as well as sequential approaches. Agile approaches aim to eliminate the limitations of the waterfall approach.

Agile, Scrum, and Lean:

• Agile is the umbrella name for approaches designed to develop adaptive frameworks.
• Scrum is one of the most common Agile approaches.
• Lean is a management approach designed to eliminate unnecessary tasks.

In practice, there are overlaps among these approaches that share similar tools and methodologies.

Agile/Scrum team: An agile team is a self-organized cross-functional unit. There is no fixed role assigned: tasks are divided between the team members at the beginning of each sprint. The size of the team is usually limited to 3 to 9 members to be efficient.

Scrum master / agile coach: Rather than being the head of the team, a scrum master is a facilitator that ensure that Agile principles are understood and applied effectively. The primary objective of the scrum master is to remove barriers preventing the team from progressing.

Product owner: The product owner is a business-oriented person whose role is to maximize the value of the work of the scrum team and act as interface between the agile team and the stakeholders. The owner is responsible for capturing the requirements of the customers and managing the backlog (prioritizing the deliverables). The owner communicates transparently with all stakeholders about the performance of the project, completion dates, etc.

Project manager: Project managers, whose role are focused on project planning and task allocation, are often (but not always) absent from Agile frameworks. Their roles are split among the agile coach (facilitation), product owner (gathering requirements and managing priorities), and the Agile team itself (a self-organized team).

Sprint: A sprint is a time-boxed (maximum duration) period during which the team focuses on a specific goal: developing deliverables than can be showed to stakeholders (an increment). The overall goal of the sprint is broken down into stories describing each task that has to be done. A sprint usually lasts 2 to 4 weeks.

Users stories: A user story is an Agile method to capture a description of a feature from a user perspective. The story details what a specific type of user needs to achieve and why.

Story backlog: The backlog is an ordered list of all the stories that might be needed to deliver a solution.

Story board / Kanban board: The board displays the stories that are being worked on during a given sprint and the stage of completion.

Burn-down chart: The burn-down chart help measure the progress of the team by showing the amount of remaining work.

Breaking down projects into a series of sprints

An Agile team performs a series of sprints, those short periods of time during which the team focus on developing deliverables that can be showed to stakeholders to gather feedback and constantly improve the solution delivered.

Several events take place during a sprint. They are designed to allow for transparency, adaptability, inspection, and regularity. This is also a way to avoid lengthy meetings and discussions.

Sprint process (overall duration: 2-4 weeks)

Sprint planning:

Meeting during which the team determine the items they are going to deliver and the way they will be delivered (up to 4 hours). These items are based on stories taken from the backlog.

Development during the Sprint:

The team organizes itself and works to achieve the goals of the sprint.

Lengthy regular meetings are replaced by short daily stand-up meetings (15 minutes) to coordinate the work. During the daily meetings the same questions are asked to each team member:

• What did you do yesterday?
• What are you going to do today?
• Do you have any blockers?

Sprint review:

At the end of the sprint, the team review the sprint’s deliverables with the product owner and the stakeholders. Their feedback is used to plan the next sprint or adjust the backlog (up to 4 hours).

Sprint retrospective:

The team holds an internal meeting to review how things went during the sprint and discuss how to improve the way the team operates (up to three hours).

Developing user stories

Stories are typically based on the following template: “AS A (type of user), I NEED TO achieve (a specific goal), SO THAT (rationale behind this action)”. The team will then use this story to elicit more details from the user and determine what has to be developed to respond to the issue that has been detailed.

For example: a story to develop a new mobility-related feature in an HR system could be “AS A mobility coordinator using the HR system, I NEED TO receive an email alert each time an assignment is 6 months from the end date SO THAT I can initiate the repatriation preparation.”

Larger stories are called “epics” and are broken down into smaller stories. For example, an epic could be about setting a policy about a specific group of international assignees. This epic could be broken down into several stories, each dealing with one aspect of the policy (managing housing, per diems etc.).

Stories are stored in a backlog. Setting priorities in the backlog is the responsibility of the product owner but it’s the team that collaboratively evaluate how many stories can fit in a given sprint. Stories are not assigned arbitrarily to one person. It’s the team that collectively decides who is doing what in order to take advantage of the skills and availability of all team members. The backlog is regularly updated with new stories designed to refine, correct, or further develop the business solution.

Implementation tips

Evaluating the level of readiness of your organization

Securing support from management is important for all changes but becomes critical when trying to implement Agile practices. Traditional project management features such as reporting lines, fixed roles and responsibilities, and rigid deadlines are partly eliminated or changed in an Agile project. If there is no understanding of the Agile concepts within the organization, management might be puzzled by the lack of detailed formal planning and the concept of self-organization and ultimately resist change.

In theory, Agile sprints are protected time-boxes during which the Agile team can focus on a specific goal – these sprints can be easily disrupted when other priorities and additional tasks are arbitrarily assigned to team members by management. Similarly, we sometimes see project managers assigned to Agile teams to compensate for a perceived lack coordination. They immediately put in place detailed RACI charts (roles and responsibilities) and numerous reporting meetings – a clear sign that the Agile approach has not been fully understood or accepted.

For these reasons, HR Agile frameworks are best implemented in organizations that already have experience with Agile (at least within the IT department) and where management understand and support the implementation.

Piloting small scale applications and developing a lab mindset

In organizations with no experience with Agile approaches, adopting some of the Agile tools or asking a team to test the concept is better first step than trying to have large business unit become fully Agile. New initiatives can be tested through small agile teams to see if they could be applied for the whole business.

Scaling Agile and dealing with scattered teams

The Agile approach was originally created for small teams based in the same location. Larger teams (more than 10) needs to be split into several smaller teams with an additional level of coordination added. This is called Agility at scale.

Distance can be another challenge, as Agile approaches rely heavily on the capacity of team members to communicate effectively with each other. An Agile project becomes more complex when teams are spread between geographies.

Furthermore, cross-cultural issues can add to the complexity: Agile principles can be applied in most countries but might need to be adapted or explained differently depending on the audience – highly hierarchical cultures or those valuing indirect/contextual rather direct communication might be initially uncomfortable with Agile frameworks. An experienced Agile facilitator/Scrum master might be needed to ensure good collaboration and avoid misunderstandings.

Mitigating Agile risks

The Agile approach works better with some types of projects than others. Repetitive tasks can benefit from ongoing improvements. However, other tasks, such as compliance, don’t lend themselves to the agile trial-and-error approach and might require more thorough planning and controlling.

Published on August 17, 2019