As learning and development (L&D) teams increasingly adopt Agile development methods, leaders need to adopt Agile roles and techniques. L&D leaders considering Agile project management would benefit from a look at Agile leadership roles.

Adapting Agile for L&D

Agile methods dominate the software development space, partly because:

  • Agile methods improve the ability to meet schedule deadlines.
  • Agile quality is better than traditional norms.
  • Agile methods continue to provide users with a competitive advantage.

It’s no wonder that other organizational functions are beginning to eye Agile methods as an attractive option for project management, decision making, and prioritization. Agile expands upon previous iterative models for continuous improvement.

With The Quick Guide to LLAMA® and Michael Allen’s Leaving ADDIE for SAM, L&D teams have been able to adapt Agile software development techniques—personas, stories, estimating, iterations—for eLearning use. Considerably less time has been spent focusing on the unique challenges that leaders of Agile L&D teams face. This article addresses that gap, focusing on the concept of “role” in two ways: what we call these leaders, and what we need them to do. A follow-up article will explore the Agile project team leader role in greater depth.

Formal leadership roles on Agile teams

Given software development’s leading role in defining Agile methods, much of the literature and most of the formal and informal learning available about Agile is based in software development. Agile software development teams include these leadership roles:

  • Product owner: The product owner’s chief responsibility is high-level vision for the [software] product and the prioritization of the steps to getting there. Some organizations separate the roles of product owner (internally focused) and product manager (customer and marketplace focused). Atlassian’s guide to Agile describes the product owner as the person “who champions customer needs, the ‘why’ of the product.”
  • Scrum master: Scrum is the predominant (but not the only) way of using Agile methods in software development, so you’ve likely heard the term “Scrum master” before. According to the official Scrum Guide, the Scrum master is a servant-leader who supports the team, the product owner, and the organization in implementing Agile techniques. The Scrum master handles the necessary tactical aspects of implementing the product owner’s vision and has a generally shorter-term view of the work than the product owner.

Leadership roles on a LLAMA team

The LLAMA® approach that many teams use to implement Agile methods in instructional design and development projects follows the same Agile values and principles and uses many of the techniques that software teams use.

Our work in instructional design is similar (but not identical) to that of software development. Therefore, to enable instructional designers to support those areas of our work that differ, the roles and their titles are a bit different in LLAMA or Agile project management in the L&D space:

  • Project sponsor: This catch-all term has emerged as an equivalent to the Agile product owner. It’s a term many people already know and understand, and its typical usage is in line with the role of the product owner. Using this term allows for situations where, for example, an L&D team is building training for a software project—and the product owner for the software project is someone other than the sponsor of the learning project.
  • Project manager: Again borrowing a title already in use, the term covers non-Scrum Agile projects where the title of Scrum master would not work. In some Agile literature, the Scrum master as a facilitator of how the team gets work done is often contrasted with the concept of a traditional project manager, stereotyped as a top-down manager with a command-and-control approach. In Agile project management, the difference does not have to be that black-and-white.

What Agile team leaders do

Whether called a Scrum master or a project manager, the person fulfilling this role is responsible for the tactical activities of how the team gets its work done, as well as the emotional work of supporting a team that is constantly soliciting—and being buffeted by—change as the project unfolds.

While a command-and-control approach to project work can be faulted for its rigidity and potential to stifle team creativity, it does provide a certain amount of stability, particularly in a team or environment that resists change. But Agile teams embrace change, which means that leaders of Agile teams face a number of challenges that, while common to all leaders, are particularly evident in Agile projects. These include:

  • Navigating the transformation from traditional project methods to Agile
  • Managing communications with people outside of the team who are not familiar with Agile methods (including SMEs and project stakeholders)
  • Balancing an environment where success is measured by team output, but individuals are evaluated and compensated based on individual performance
  • Responding to constant change and identifying the useful changes in scope and approach
  • Supporting the team in an environment where each iteration could show that the team is on the wrong path and needs to revise significantly
  • Actively incorporating reflection and learning into the team’s regular work

Continual evaluation means constant change

Traditional project methods for instructional design follow the ADDIE model, a waterfall approach in which implementation and evaluation come at the end of the project, like this:

The ADDIE process is sequential, moving from the Analyze stage, through Design, Develop, and Implement before arriving at EvaluateFigure 1: The ADDIE process is sequential, moving from the Analyze stage, through Design, Develop, and Implement before arriving at Evaluate

While most would agree that this is an over-generalization, a sequential development approach is an effective means of controlling change. But, when evaluation is left to the end of a project, the team does not get the benefit of knowing if the solution will work until it has been implemented.

In contrast, an iterative project approach such as Agile or LLAMA® requires the team to constantly gather feedback from learners and use that to inform future rounds of development.

The Agile or LLAMA approach is cyclical; following an initial analysis, it includes repeated cycles of design, develop, implement, and evaluateFigure 2: The Agile or LLAMA approach is cyclical; following an initial analysis, it includes repeated cycles of design, develop, implement, and evaluate

This cyclical approach means that the team regularly receives changes and potential shifts in scope during development. It could mean that the team will find out that the intended solution does not actually work!

How constant change looks in practice

On a recent project at TorranceLearning, we’d worked with a client’s training team to develop a prototype of a mobile learning app that would also support service delivery. Our UX designer had the opportunity to test the prototype with field trainers from many of the countries the client operates in. We were pretty pleased with our solution. We’d incorporated all of the client’s requests into the prototype and made some improvements based on what we’d learned with them from prior projects.

However, instead of the expected feedback on the nuances of usability, placement of buttons, and order of content, the field trainers told the UX designer that it wasn’t really a useful solution at all. They shared their stories and solutions and gave us additional feedback on our prototype.

When the UX designer returned from the meeting and shared what had happened, I was elated. We’d gotten some really important feedback, and we’d have the chance to pivot our approach before any development had begun. This was excellent news!

And then I saw the look on her face. She was not feeling the same level of joy about this that I was. In fact, she was concerned that our credibility was at stake, and she felt horrible for working on what seemed like a waste of the client’s time and money to create the prototype.

In the moment with the client, she’d experienced a whole set of emotions she didn’t expect and wasn’t prepared for. And as an Agile project leader, I’d completely failed to take into account the emotional toll of receiving such devastating feedback.

The resolution tempered both my elation and her disappointment. We reviewed our strategy with the client team and went to work on the next iteration. In the broader scheme of things, this example called for what Michael Hamman calls “sense-and-respond” leadership in his book Evolvagility—which he contrasts with traditional “predict-and-plan” leadership.

A July 15 Learning Solutions article will describe the role of the Agile project team leader in greater depth.

Become an Agile project manager

Eager to learn more? The eLearning Guild’s Agile Project Management Certificate Program will give you the techniques, tools, and mindset you need to adopt Agile methods in your own work. Whether you are a project manager, designer, developer, or L&D manager who oversees project workflows, you can benefit from adding this skillset to your repertoire. Join Megan Torrance for this comprehensive two-day workshop, October 21–22, 2019. It is co-located with DevLearn 2019 Conference & Expo, October 23–25, in Las Vegas.