Getting Started with Agile for Digital Learning Teams

Nearly 18 years ago, a group of engineers got snowed in at a Utah ski-resort. Over the course of a few days, they got to talking about their grievances with the software development process of the moment and developed a vision for how it could be better — more collaborative, flexible, and customer-centric.

For anyone who has vacationed with a group of engineers, this story isn’t particularly surprising. However, the result of this group diatribe is. A sixty-eight-word document outlining the values behind a new way of work, the Agile Manifesto would go on shape how teams operate not only at software companies, but in large enterprises like Exxon, Lockheed Martin, Verizon, Walmart, and the Pentagon.

In my experience, learning and development teams are an enduring agile holdout, favoring the waterfall approach the manifesto sought to de-throne. There are various reasons why waterfall or waterfall-like project management remains popular: compatibility with ADDIE, fewer competitive imperatives, and lower data-driven accountability are three contentious culprits.

One under-looked reason strikes closer to home, however: team behavior change. The same transformation we seek to spark in the learning experiences we develop is tough work, even among teams who worship at the altar of the growth mindset.

Over the last several months, my team at Trilogy has adopted agile development in the course of updating a product and preparing a new launch. With the goal of helping digital learning teams get started and hit a stride with agile, here are 5 lessons we learned along the way and the resources that helped us internalize them.

0. Start with the Basics

As with any paradigm you adopt, it’s important to first know the back story to the back story, the fundamental principles behind it, and how things have changed from then to now. Revaluate your reasons for exploring agile and what you hope to get in return.

1. Don’t Wait on Others — Get Started

Company-wide agile transformation are slow going or entirely avoided endeavors particularly because they need top-level buy-in and support in multiple areas to be successful. If you need a more customer-centric approach that is flexible to change, don’t wait on decisions above you to try agile. Microsoft started off with a handful of teams experimenting with agile. Over the course of a decade, the movement grew to to several hundreds of international teams. This grass roots story repeats itself in many agile origin stories. You don’t need a consulting group, just the time and humility to read several beginner’s guides.

2. Read About the Common Pitfalls Before Starting

Adopting a development process that’s nearly two decades old is a humbling experience. For this reason, many product owners who have been where you are have shared their trials to make things easier. The most common struggles I gleaned from these reflections related less to a team not understanding the value of agile, but rather gravitating away from its foundational values towards its opposite.

This, Not That

The Agile Manifesto is a pretty short, to-the-point document that outlines what it is, and what it’s not.

• People and interactions, not processes and tools
• Finished work, not beautiful project plans
• Collaborative, not siloed
• Flexible, not rigid

Each of these principles is easier said than done. Although agonizing over what project management tool to use or writing exhaustive documentation of user needs and communication protocols doesn’t sound appetizing, it looks increasingly so when compared to communicating across functions and having honest conversations about where team improvement can be made.

What’s the crux of this challenge? An agile mindset goes counter to a paradigm that may be comfortable. Just as learning something new can require a degree of unlearning, so does going agile force you to watch for old tendencies that were engrained by waterfall.

In Why Agile Goes Awry — and How to Fix It, Lindsay McGregor and Neil Doshi cover some of the most common old habits teams fall into and how these lead to less motivated and less productive teams. The article’s six suggestions on how to loosen the reigns on a command and control mindset while providing a consistent vision was helpful to me as I began to consider how agile might fit with our team’s roadmap.

From this article and others, it became clear that the most underestimated challenge in an agile transformation is the cultural and mindset shift it requires.

3. Make the connection between Agile Manifesto and Learning values

With all the change and unlearning agile demands, why make the move? It’s a good question. While a chart comparing waterfall and agile may win some converts, a stronger case for your learning team may be how agile development supports constructivist learning by putting students at the center of the process.

Just as constructivist learning shifted the focus away from the teacher and toward the student and their interactions, agile seeks to put customer needs ahead of contract negotiations. This intention is most notable in the agile practice of writing user stories, descriptions of small scopes of work as they relate to the context and needs of users. Written in plain speak, a user story lets any team member, technical or not, know why this goal is important and how it alleviates a user pain point.

Agile’s flexibility to new information is one of the reasons it has grown in popularity. Agile is meant to adapt to changing scope and requirements, whereas Waterfall places more weight on upfront planning and dogged execution. If your learning experiences attempt to generate momentum from student interests, prior knowledge, new experiences and dialogue, waterfall is likely too rigid to respond to observations and unforeseen desire paths that even the best upfront research and planning couldn’t predict.

Backlog grooming and sprint planning are perhaps the best examples of agile ceremonies that dedicate time to adapting to observations and other learnings by prioritizing user stories that may have been unknown just a few weeks ago.

These are just two examples of how agile aligns with constructivist approach to knowledge creation, but there are many more to be made that could illuminate how it is a perfect process for supporting a shared learning process.

4. Look for Best Practices, Watch Out for Process Creep, Calibrate with Principles

Fortunately, the web is replete with resources to help make a transition to agile development. When you’re getting started, try to suss out what the agreed-upon practices are and work to integrate them into your next project. These stalwarts typically include practices like measuring capacity, reporting blockers, and defining a time-based, finite end-goal, among others.

It doesn’t take long, however, to see that while some practices are sacrosanct, others are open for debate and relative to context.

Does everyone attend backlog grooming or just a few folks? Do you hold a retro on the last day of the sprint or the first day of the next? Do you estimate time needed for a task by number of hours, t-shirt size, or Fibonacci sequence? These are questions that could be debated endlessly and have the potential to be distractors and dividers.

As you start off, don’t get hung up following the ‘rules’ of one source with a monastic fervor — adapt agile to the culture and context of your team with consideration to the amount of change that can be absorbed at any moment.

Joe Van Os captures it well: “Process should adapt to the environment, not the other way around...Focus should shift away from Agile processes, and back to the principles of being agile.” In Deconstructing Being Agile, Joe outlines several principles that help you focus on being agile, and not ‘following’ agile. These principles served me as helpful guardrails, ensuring that our team didn’t get too myopic with process part of agile, or too loose with its principles.

5. Stay the Course

It’s a lot of work and dedication to do well, and at first applying agile principles will seem burdensome and not the lightweight framework that was promised. Consider this a start-up cost and don’t give up too early.

While both practices are not universally beloved, our team found great value in sprint retros and time estimation. Retros helped us refine how we adopted agile so that it best fit our team and time estimations helped us get better at planning what goals we could accomplish in a fixed amount of time. Both of these practices were imperative to improve how we worked together and provide the data — as well as the completed work — to see the progress we had made.