Leaders are often tasked to deliver more with their existing teams (or deliver the same with smaller teams) in service of increased profit margins. There are many ways to promote bottom-line growth, but for now, I’d like to share the story of how we collaborated with one client to accelerate value delivery in learning and development (L&D) by introducing a novel approach to strengthen an L&D team’s relationship with its business partners.
A major big-box retailer partnered with us to help its L&D team support the company’s IT department. The department was in the midst of an Agile transformation and had asked the L&D team to build learning solutions to align the employees and upskill them on Agile ways of working. (You can learn more about Agile’s original values and principles in the Manifesto for Agile Software Development.)
In its role as a strategic partner to the IT department, the L&D team’s plan was to first collect all the information outlining the department’s new ways of working. Then, this team would launch a project to perform analysis, design, development, and implementation. However, this approach presented two key challenges. First, it would not support the rapid timeline the IT department had adopted for its Agile transformation. Second, in a sense, the traditional project plan would engender a “client and supplier” relationship—not quite the strategic partnership the L&D team was after.
As GP Strategies came on board, we proposed a new way to deliver learning solutions that met the demands of the business and enabled the desired partnership. Borrowing from one of the most effective Agile software development frameworks, we set out to establish the retailer’s first L&D Scrum team.
Why Combine L&D with Scrum?
The Scrum approach would empower L&D to support the IT department’s transformation immediately instead of waiting for the department to fully define its Agile approach for software delivery—which they expected would evolve over time anyway. The two groups would partner to develop learning solutions even as the IT department explored and shaped its new Agile operating model. This was possible because the Scrum framework provided the flexibility to deliver learning solutions in parallel with the creation of new ways of working.
As the IT department defined a part of its Agile operating model, the L&D team would begin developing the initial learning solution—not waiting for everything to be finalized—to support the IT department’s desired speed of transformation. The Scrum model and parallel timeline allowed the L&D team to share and empathize with the IT department’s transformation experience and provided a platform for true partnership. In moving away from the traditional project approach toward Agile learning-solution development, the company positioned itself to improve the learning solutions being developed.
For those not familiar with the Agile approach, it flips traditional project management on its head. In a traditional approach, scope is fixed, while cost and time vary. For example, if you want to build a house, you define the scope (a finished building) and then allocate a budget and a timeline to construct it—hopefully by an agreed-upon date. Then, the contractors all move on to their next project.
By contrast, in an Agile approach, cost and time are fixed, while scope varies. It is common for teams following an Agile approach to use the Scrum method, which timeboxes (or subdivides) work into short “sprints,” normally two weeks in duration. Each sprint should produce a deliverable that’s ready to implement in the business, so deliverables are defined and recorded in a “product backlog” (see Figure 1). This backlog is filled with a description of the components required to make up the learning solution and developed in tight partnership with the business partner, resulting in a prioritized list of work for the team. (I’ll describe the team itself a little further on.)
Once the product backlog is built, it’s time for sprint planning. The team identifies new deliverables for each individual sprint, allowing the scope of work to flex in response to changing circumstances. Those items are moved into the “sprint backlog” for the team to work on during the sprint. During the sprint, the team participates in the daily scrum, a meeting conducted at the same time and place every day that allows the team to connect, align on work in flight, and ensure they are on track to produce that sprint’s deliverables.
At the end of each sprint, the team conducts a sprint review with the business partners and other stakeholders. The objective is to publish the sprint deliverable at the end of the sprint, but feedback is also collected with ideas for refined or new deliverables added to the product backlog to be selected for a later sprint. Finally, the team conducts a sprint retrospective. This short “start, stop, and continue” reflection is intended to enable the team to continuously improve performance.
Figure 1: A diagram of the Scrum framework. Source: https://www.Scrum.org/resources/Scrum-framework-poster
In the case of the big-box retailer, we started by building the team. The understanding was that due to the ever-evolving nature of technology, the IT department could continually benefit from new or updated learning solutions. So we decided to build a stable, high-performing team that would develop and implement learning solutions in perpetuity. This is another departure from the traditional project approach, which typically brings teams together for a defined period then shuffles people from one project to the next.
Driving teams through the “forming, storming, norming, and performing” process, only to dismantle them once they hit their stride before restarting the process for the next project, can be hard on productivity. In the Scrum framework, we don’t bring new teams to the work; our intent is to build the right team, then bring the work to them.
Without knowing exactly how many people would be optimal, we decided to start with three instructional designers. Next, we needed a product owner: someone to partner with the IT department, manage learning-solution intake, and prioritize the product backlog to meet the learners’ needs. The IT department provided the initial product owner with the idea that one of the instructional designers on the team would learn from the product owner, then eventually replace them. A Scrum master came from the IT department as well, planning to roll off once the team was experienced and effective in executing the Scrum model.
With the Scrum team set, we started developing learning solutions. As the team produced deliverables, we measured the velocity of delivery against the backlog of demand and timing of requests. This data informed the decision to rightsize the team to four instructional designers.
The Scrum workflow made it possible to start developing learning solutions even before all the new IT department ways of working were defined. It also broke up the work into small parts of incremental value (training courses or a learning experience) that could be delivered at the end of each sprint. Then, while the first course was being delivered, the Scrum team worked on the next course. This flow allowed the IT department to shorten its time to proficiency, evaluate the results of the learning solution, collect feedback, and adjust accordingly.
Figure 2: A diagram of our L&D Scrum workflow for the IT department at a big-box retail client.
The traditional approach would have required the IT department’s Agile evolution to be finalized and the full learning journey to be designed and developed before delivery, but the Scrum framework allowed the company to start delivering courses and realizing value after just a few weeks. Members of the L&D Scrum team told us they enjoyed the working model and were better able to empathize with the learners and deliver engaging learning solutions. The iterative Scrum approach also facilitated a tight partner relationship between the L&D team and the IT department during their Agile transformation. As a result of the learning solutions the L&D Scrum team quickly delivered, the IT department was able to launch its own Scrum teams, in turn accelerating its Agile transformation—exactly the business outcome the company targeted.
Since the introduction of Agile software development in 2001, countless organizations in multiple industries and disciplines have learned to borrow and bend Agile processes, flows, and tenets (in much the same way L&D teams know to curate learning content). These processes can present a highly effective way to help organizations move faster, save resources, and grow the bottom line.
So ask yourself: How could the introduction of Scrum methodology maximize the impact of your L&D efforts and strengthen your relationship with your business partners?
For more information on building stronger relationships within your organization, learn about the 5 Powerful Conversations L&D Leaders Should Have with their Business Partners.
About the Authors
