Friday, April 23, 2010

Agile, Lego and Training: The common factors...


Harold Jarche’s posts as always hits the nail on the head and this one is no exception. Before I launch into my thoughts, here's what Sara Ford (Program Manager of CodePlex) has to say about Agile:

1. Design and plan for the very next step, instead of designing and planning for the very next feature.
2. Break down work into smallest possible sets. Adding work is fun and rewarding; removing work is painful and risky.
3. Design and plan 80% of the way as the very next step. Use feedback to solve the remaining 20% in the very next step after that.

What does Agile have to do with Informal Learning and Instructional Design? A lot! It's all about the mindset. It’s about effective communication. It’s about collaboration.

Agile means the willingness to be in a perpetual state of Beta, accepting that there is no closure, can be no closure with information, requirements, needs, business opportunities changing at lightning speed.

This mindset plays a critical role in understanding the business goals of a training program. As Harold Jarche writes, trying to pin down everything at the outset and expecting nothing will change is arrogance. This in most cases stem from the traditional program management mentality that was more suited to a manufacturing setup following the Waterfall Method, where scope was well-defined, there was one and only one way of doing something, processes ruled. Deviation was firmly discouraged; innovation was probably a dirty word.

But that was then; this is now!

With training being developed in tandem with product development today, scope of work can only be planned for in phases. In byte sizes. Quick and dirty is the rule. Fast feedback and successive approximation are the keys. And acceptance that there is never "an end" is paramount.

Thus, designing training or facilitating learning in today's business environment means accepting that formal training cannot be the ONLY solution. It means creating opportunities for self learning, exploration and collaboration. It means creating space for conversations to take place. It means building more water coolers. The rest will take care of itself.

Once we accept this, we will not be restricted by traditional program management attitude of defining the scope of a training program and the building to meet the scope. Aaarghhh! The scope will change ten times over even as the product development moves from iteration to iteration. The pre-defined scope would not be worth the paper it was written on.

Sara Ford uses a wonderful, visual analogy for Agile that is a brilliant fit for scoping of training needs in today’s business organizations. Legos! Think of a training program as a Lego set. Break it down into movable pieces. Of one hour each. Estimate, plan, scope for that one hour only. Move the pieces around. The rest is easy multiplication depending on the evolving training needs.



As assumptions and requirements change for software development, so do they change for training design as well. It’s time to embrace this change; time to say no to a process that acts like a straightjacket and becomes more of a hindrance than help; time to say “let’s think Lego!”

List of related readings:
1. Agility and Autonomy (Harold Jarche)
2. How I Learned to Program Manage an Agile Team after 6 years of Waterfall (Sue Ford)
3. Other PKM processes (Harold Jarche)
4. Social Learning in the Workplace = New Toolset + New Mindset + New Skillset (Jane Hart)
5. The Future of Software Development (
6. Networking = Learning? (Sue Schnorr)
7. Esko Kilpi
8. Making Your L&D Department Meaningful & Relevant (Charles Jennings)
9. Social Media for Knowledge Workers: eLearning Technology (Tony Karrer)
10. Informal and Formal Learning Tool (Clark Quinn)
11. The Future Business of Learning for Suppliers (Charles Jennings)

No comments:

Post a Comment

Thank you for visiting my blog and for taking the time to post your thoughts.

Organizations as Communities — Part 2

Yesterday, in a Twitter conversation with Rachel Happe regarding the need for organizations to function as communities, I wrote the follow...