Agile for Learning and Development Teams: It’s not just for software anymore.

Long before we implemented an Agile process for our own Learning and Development team, we were really interested in the Agile process. We started at our company—a late 90s startup—in 2014 as a new Learning and Development team. Being from the startup mentality, a training department never existed, and for the most part, training didn’t happen in a formal way—training was shadowing the guy next to you—but the company was outgrowing the startup phase with nearly 500 employees across the globe and over 200 in our office alone. After hearing from the organization that training was increasingly an issue, the vice president of the organization made it his mission to advocate for a budget to hire a training team. The company had never had a training department before, and we were hired as a pair to comprise that training department.


The training office was right next to the engineering team for our organization, and anyone who knows stereotypical engineers like the ones at our company (of course we know some that don’t fit this mold, so no hate mail, please!) know they like their quiet, dark space, and they don’t want to be bothered by the brainstorms of a lively and chatty training department. As we would come to find out, it was the worst possible office they could have picked for the two of us and the hoards of employees we started to attract when they figured out they had sudden access to a training department.

We watched the Engineering team develop their Agile process: “they’re moving to Agile,” everyone said, but what did it mean? We watched their Kanban board but didn’t know what it was—they had inconvenient meetings right outside our office door around a whiteboard that had colored sticky notes “must have, should have, want to have.” They yelled on Fridays at each other sometimes—later we’d come to understand (you’ll hear about this in a future post about the Great Standup Fight of 2017).

So, while the idea of Agile was sexy, it took us almost two years to implement. We were attracted to Agile because it sounded exactly like the flexible development process we needed—iterative design and deliverable product in two weeks—but we also recognized that while watching another team transform, it was something we could do, too, and we aren’t even software developers!

When we began to explore an Agile framework, we couldn’t find anything specific to implementing an Agile process for a non-engineering team. While there are methods for Agile Instructional Design or Agile approaches to developing eLearning courses, there wasn’t anything cohesive in one book or program about operating autonomously as a Learning and Development Agile team. Jeff Sutherland has a fantastic book on Scrum that explains the tenets of Scrum (one of the Agile frameworks, and the one in which we work most), but reading about becoming Agile and actually becoming Agile are two different things.  While we watched one team implement Agile and have read about others operating in different frameworks o(Scrum, Kanban, XP, Lean, ScrumBan), we couldn’t find literature on converting a whole team process to Agile.

There are learning methodologies like SAM as presented in Leaving Addie for SAM, but there didn’t seem to be anything fundamentally rooted in Agile written for learning and development, so we decided to start this blog  to help others in our position who think Agile may be an approach that could work for their teams.

It’s not tough to read Engineering books about Agile and decipher a process that works for you,  but we have learned some lessons worth sharing. We’ve also had some questions about whether we’re “doing it right.”  Let’s put it this way–we’ve had some successes and failures, but we’d like to think we’re not getting it all wrong.  When starting with Agile, getting a good foundation is important: understanding the principles can be key to future success.   We do, however, hope this blog starts a new conversation—one that opens a space for conversation and collaboration in a non-engineering context within Agile and the Training and Learning and Development industries, so welcome to our blog.


  1. Excellent! I used and still use an Agile board and process for developing restaurants. It was especially useful as a culinary instructor with lots of tasks for the large and small classes to track.
    We found great cross communication and an ability to see the big picture instead of being focuses on micro.

    Liked by 1 person

    1. Kelvin, it’s awesome that you used that in a restaurant! I was so thrilled to see this comment come through today, and I loved that you mentioned the communication aspect. That’s the one thing I love most about Agile–the transparency helps build communication.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s