Today, the expectations of learners are much different than they were only a few years ago. Much of what is currently rolled up monolithic, one-size-fits-all courses must give way to small but relevant content updated and delivered continuously to learners based on their individual profiles or needs. In other words, learning needs to go Agile.
In a recent blog post by Bersin & Associates, Josh Bersin provides a great description of how Agile applies to training:
“Agile is also built on the understanding that people learn in small chunks – so while it may in fact take a year or two to build a highly complex website, no person needs to try to understand the entire engineering program in advance. […] Daily work becomes a part of a bigger project in a continuous, dynamic process.”
What does this mean for us?
So how do Training Vendors help training organizations go agile: they adopt Agile Development. Agile Development is an approach where vendors deliver very fast, iterative product development through close collaboration with its user base (i.e. training organizations). According to McKinsey & Company:
“This agility can deliver new systems and capabilities in a matter of weeks or months instead of years. A frequent iteration cycle also keeps IT developers and business users in sync on requirements and priorities. […] Since this approach is most effective when business needs are shifting, it is gaining favor among many IT departments.”
Indeed, according to a survey of global executives by McKinsey, over 70% of respondents have deployed or piloted Agile Development within their organizations in order to be more responsive to changing business conditions.
In 2011, recognizing the rapid change in the training industry and our clients’ need to quickly adapt to the needs of their learners, Xyleme fully embraced and adopted enterprise-wide, the Agile Development Model. This post is the first in a series, written by Greg Schottland, Vice President of Operations for Xyleme, that presents the business value of using Agile, why it has proven a key competitive advantage to companies like Apple, Google, Microsoft, Facebook and many others. Part one of this series provides a simple overview of what Agile is. You’ll begin to see the value just discussing the basics in this post.
Agile is simple:
• Build in small increments.
• Focus your team on one well defined goal.
• Keep the team small.
• Coordinate daily
• Get everything (and everyone) else out of the way.
And the result:
• A working product in weeks, not months.
• Customers that get what they are waiting for quickly.
• Developers that build what the customer wanted and nothing else.
Sounds simple, and it is. While there are volumes written about the details of effectively practicing Agile, this post will focuses on what Agile looks like “on the ground” in daily practice.
Taken from Josh Bersin’s blog
It all starts with an idea.
Somebody wants software to do something. Say we get this great idea to be able to create and store documents on the web (a la GoogleDocs). Rather than designing an entire web based document application, we start small. What is the most important problem to solve? This is simple to define. What do users have to be able to easily do at the most basic level? For our application, this would be the ability to create a simple document using a plain web browser over an average internet connection. You may be thinking, that is pretty basic, shouldn’t we at least include other basics like spell checking, text styles, maybe import/export? I mean who wants a document processor that doesn’t support bolding and italics…I mean really!
This little example is chock full of important lessons that Agile helps address. We might be inclined to design a more complete first version. The logic being it is easier to design everything in from the start. And, in some cases it is. But, more often than not, without getting key usability, architecture or market acceptance issues implemented and down cold, much of our “complete design” ends up being wasted, as key assumptions run into challenges. Years of effort and millions of dollars down the drain.
Let’s look at our example in this respect. We have put a stake in the sand and said that the one thing that has to work is the ability to create basic text document on any browser over an average internet connection. If this doesn’t work, no one will care how slick our spell checker is, nor how easy it is to bold some text. If response is slow, same problem. But, if we have version 1 prove that we can connect 1,000 users to our system, and things are snappy responsive and basic documents can be created, isn’t that a relief? Now we can build on top of this base.
So, turns out our too small initial release may be just about right. What we do at this stage is write up our requirements for this initial release in a set of short, concise documents called User Stories. They include two major pieces of information: 1) a clear statement of some small functionality and 2) detailed description of how to test this functionality. That’s it. No massive requirements document. One of our User Stories might be that users can connect to create and save a blank document. The test would detail step by step instructions of the URL, the buttons pressed, dialogs that appear, etc.
Ease of Development.
As you can see, with well written User Stories, development is a whole lot easier. We code to the test; back our design into the tests. As a development manager, or customer, I can sleep at night. Developers aren’t done until our tests work. I don’t have to watch over it.
So, our initial planning will consist of creating a small set of User Stories which define our first release. We’ll call each such small release a “Sprint.” Each Sprint will be scheduled to last several weeks. No magic number here, can be 2, 3, 4 weeks, but probably should be less than 8 weeks. You’ll go back and forth trading off initial features against time and end up with a Sprint 1 of say 4 weeks (just an example we chose, no magic number).
You’re almost ready to start coding. The one remaining task is to take each User Story assign them to developers and have the responsible developer estimate what tasks they’ll have to do to implement the User Story, and estimate their best guess of how long it will take to complete that task. But…one twist. These tasks have to be small enough that they take between 4 -16 hours to complete. This level of detail is often unnatural. But, it has magic built into it. By forcing yourself to break down work to this level, invariably important overlooked details emerge, providing for much more accurate estimates. Now, admittedly, you are relying on the best guess skills of your developers, which will vary by developer, by task and sometimes by whether they have just had their morning coffee and are feeling optimistic or not. But, it provides a starting point, and over time you’ll find your developers get better at this, and you get better at coaching your under or over-estimators.
Ready. Set. Code!
You are ready to start coding armed with User Stories and a detailed task list for each developer. You may feel like you’re traveling light, and you are. That’s the whole point. You backpack has everything you’ll need and nothing else. You will have a daily meeting (called a Scrum) with all the developers with tasks on the project and you, the project leader and no one else. No managers, no other developers, no business analysts, just the “doers.” These meetings will be no longer than 15 minutes. You’ll ask each developer just three simple questions: which task did you work yesterday, which tasks will you be working on today, what is blocking your progress? That’s it. No lengthy design discussions or play by play of your development day. Just these three simple questions and 15 minutes later you are done. The purpose of this meeting is to ensure that any blocks from progress are removed immediately and that your developers stay on task. You, as leader of the Scrum, are there to listen for blockers and remove them as fast as possible. All the team members know exactly where the project is all the time.
One final task.
At the end of each day, developers update their task list with their best guess of the amount of time remaining to complete each task. Sometimes these numbers go down as work progresses, sometimes they increase (as you discover the task is more complex or taking longer than you guessed). Over time, you get a nice chart of all the hours remaining for the Sprint, called a “Burndown” chart. This chart, while simple, is amazingly powerful. Bersin reports,
“Companies which can adapt to agile management models will move faster and out-perform their competitors.”
So that’s it. Your team writes code each day to fulfill the tests in your User Stories, meets for 15 minutes each day, updates the time remaining for their development tasks — and after 4 weeks (in our example), you done. Delivered on time and to spec.
It sounds easy, and it is!
In our next in the series, we’ll look at how this simple process translates into faster time to market, lower costs and wildly happy customers.
Technorati Tags: Agile Development
Sarah Danzl Agile Development, informal learning, Learning Technologies Agile Development
Last week, I had the good fortune to speak with George Siemens for an upcoming 
Dawn Poulos is the primary author of this blog. She is Xyleme's VP of Marketing, writes a lot about XML, learns a tremendous amount from the training community and hopes she’s adding some insight.