It’s more-than-popular to talk about “Agility” in business lately. But what does “being Agile” really mean? And, if you’re not a software developer, what does it mean to “borrow concepts from Agile software development”?
It’s important to note that Agile software development includes a group of software development methods which have a core set of principles in common (including Scrum, Extreme Programming (XP), feature-driven development, among others). There is no one specific way to be Agile.
However, here are the two basic ideas that most people agree upon when it comes to Agile software development:
#1 The Agile Manifesto
Agile software development is based on the Agile Manifesto, or The Manifesto for Agile Software Development:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the left more.”
—Kent Beck, James Grenning, Robert C. Martin, Mike Beedle, Jim Highsmith, Steve Mellor, Arie van Bennekum, Andrew Hunt, Ken Schwaber, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Ward Cunningham, Jon Kern, Dave Thomas, Martin Fowler, Brian Marick
© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.
#2 The 12 Principles of Agile Software Development
There are 12 principles of Agile software development, which you can read on the Agile Alliance’s website.
As evidenced by the points above, “being Agile” doesn’t mean throwing out all rules and processes following the way of the old Wild West. Being Agile does mean working in a lightweight, highly responsive way so that you deliver your product or services in the way the customer wants and at that time the customer needs them.
There are rules, albeit not many rigid rules. After all, we are talking about being Agile here.
The Agile Manifesto and the 12 principles of Agile […] development are quite lightweight and hardly restrictive. So, how you actually put the Manifesto and principles development into practice can be subject to some interpretation. Especially if you are applying Agile methods to something other than software development—like managing or creating training programs—you have to make adaptations.
But, following the Manifesto and 12 principles in the spirit in which they were intended, I would say, is “being Agile”.
As opposed to more traditional, sequential development methods, Agile methods allow you and your organization to be responsive to what’s important. In other words, Agile methods allow you to:
And, that’s just the start of what can be accomplished through the ability to respond to changes, changes, direct communication and focusing discussions on tangible work.
Every organization needs to ponder the Agile Manifesto and the 12 principles of Agile development and determine how best to make things work for its own needs and culture. A good starting point is to look at each of the 12 principles of Agile development, one-by-one, and decide on applications to your organization.
I’ll use three of the principles, for illustration purposes on how you might choose to adapt Agile methodologies to eLearning development.
Principle #3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Megan Torrance writes about how Agile can work for eLearning development and gives ideas on how to equate eLearning development to software development using Agile methods. Basically, choose to use process-light, user-focused techniques to home in on what matters most to your learning audience. Create and deploy relevant content quickly (ideally 1-2 week iterations). The point is to avoid wasting unnecessary time building an eLearning program which may end up being obsolete at the time of release, when a course correction is too late and/or too expensive.
Principle #7: Working software is the primary measure of progress.
Demos trump documentation. Be prepared to show stakeholders something that works at pretty much any time. For example, if you are developing microlearning (short bursts of learning, typically of a few minutes in length) or performance support (learning-based support delivered to a learner on the job and at the point-of-need), you can easily find discreet deliverables that are intrinsically valuable and can be completed in short sprints. As you build a library of discreet learning modules in your LMS, you can easily rollup each deliverable into a larger course.
Still unclear how to deliver a “working product” in a short amount of time? Challenge yourself to create an online training course in one day. Better yet, challenge everyone on your team to create an online training course in one day. You may be surprised about what you learn and how much easier it is to create a “working product” in a short sprint.
Principle #5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Following Agile principles at Mindflash has resulted in a predictable, reasonable work schedule for employees and higher product quality. At the same time, modifying some Agile principles (while still retaining the spirit in which those principles were put in place) has worked well for Mindflash. Wells says, “We’ve chosen to ignore the Agile precept that dictates co-location of employees for a couple of reasons: One is work-life balance and another is that it’s not relevant due to the explosion of highly-effective, virtual collaboration tools.” Instead, the Mindflash team holds "fly-in sprints" to bring geographically dispersed employees together physcially about once in three sprints (about once a quarter).
Mindflash’s modification to traditional Agile development methodologies has resulted in higher-than-average employee tenure, high-value work relationships, higher quality product, increased responsiveness to customers, and a culture of work/life balance.
Agility in the eLearning field involves creating useful, working learning solutions developed with “customer” (learner/stakeholder) collaboration, responding flexibly to the market, and valuing individuals and interaction over formal processes. And knowing when to adapt “rules” to fit your own organization’s needs.
How have you adopted and adapted Agile software development methodologies to your projects and your organization?
Gauri Reyes is a talent developer and learning leader with extensive experience in roles ranging from software management to managing the learning function in organizations. She is Principal Learning Strategist and CEO at Triple Point Advisors and Founder of the YOUth LEAD program. Follow her on Twitter, LinkedIn or Google+.