Saturday, January 30, 2010

How you can build Meaningful Interactivity into your eLearning

So last week I tweeted an example of immersive learning scenario built entirely in Powerpoint and published using Articulate Presenter. Given that I saw the tweet travel a fair bit, I thought it might be a good idea to share some of the related ideas on this blog.

Does Rapid eLearning mean Crapid eLearning?

No, it doesn't have to. Really, the quality of your elearning depends on your creativity and the amount of thought you put into its design. In a recent conference, Cammy Bean and Stephen Walsh put together a great talk on 10 ways you can yawn proof your elearning. If you look at any of the ideas they put into their guide, you'll notice, none of them says, "Employ an expensive flash programmer." or "Get a budget of $100k." Recent advancements in rapid elearning development have put a lot of power into the hands of the average SME who has a passion for learning.

The key to creating interactive elearning then isn't about rollovers and animations. In fact most people are really past the ooh's and aah's you might expect to get as a result of those fancy effects. So the way I define interactivity in elearning is:

"It's not about how someone interacts with the interface, but how the interface interacts with the person's mind."

Immersive scenarios are an inexpensive way to create meaningful interactivity

A few months back, my favorite blogger Cathy Moore put up a very interesting article about why you want to include scenarios in your elearning. Coupled with Cathy's excellent presentation on the topic (see below), it was great advocacy for the use of immersive scenarios in your elearning. The key as Cathy says, is to 'solve real problems in the real world.' so we need to think of ourselves as 'experience designers' and not 'information developers'.

How I built my scenario

So, first things first - the credits. None of the content of this example was mine. This was a scenario Katherine and William Horton presented at a conference 3-4 years back. All I did was pretty it up a bit and place it in Articulate Presenter. My aim was to illustrate how easy it is to create something fairly engaging with just a few minutes of work in Powerpoint, provided you have your design well thought through.

My approach towards scenarios

When designing any kind of elearning, I like to use Cathy Moore's action mapping approach to first define the scenario-based activities. I then use Ruth Clark's framework to flesh out the details of the scenario. Ruth recommends that as designers we think through the following aspects of the situation on screen.
  • Task Deliverable: What will the learner do to demonstrate competence?
    • In our case we wanted the manager to make the right decision about somebody's sabbatical leave request.
  • Trigger Event: How the task or problem normally initiates in the job setting.
    • In our case, the scenario gets triggered when you recieve the approved request from the applicant's supervisor.
  • Case Data: What background information is needed to solve the case?
    • The employee's file and leave request form the case data for this scenario.
  • Guidance: How will learners get assistance when solving the case?
    • You can get guidance by talking to the employee's supervisor, an HR person or a legal eagle.
  • Feedback: How will the learners receive intrinsic feedback as the scenario plays out? How will they receive traditional, instructional feedback a.k.a Teaching Moments?
    • The scenario has some very traditional feedback for the choices they make, but some intrinsic feedback could be useful. Our scenario misses this at the moment, but one way to build this in would be to illustrate the consequence of their choices.
  • Reflection: What opportunities will the learner have to review their actions/ decisions and consider alternatives?
    • We're missing this part in the demo, but its really important to give the manager and opportunity to review their actions and reflect on how they actually went about the decision.

Visually representing the scenario

I built out all of the elements in my scenario entirely in Powerpoint -- at no point did I go into any external program. A few things that might help you achieve the same effect:
As far as the remaining graphics are concerned, yes they may look custom, but they're not. They're just standard clipart from Microsoft Office. All you need to do is search by the styles I've mentioned below.
The rest is plain and simple hyperlinking. The current version of this demo has a few minor bugs, but I'll let you have the source files so you can dissect this and have a bit of a play around.

All you need is a bit of inspiration

For many years of my life I kept waking up saying, "I'm not a creative person." I know now that nothing can be far from the truth for both you and me. Sometimes all you need is a bit of inspiration. There are several examples of creativity that you can learn from. In fact, I'm starting to catalogue all such examples at this link. A few examples that I really liked in recent days were:
You can find many more such examples on the web and in particular on the Articulate Community. Its defnitely worth being a part of this community even if you're silent lurker. All of the wonderful discussions that take place are well worth listening into, every once in a while. Remember, the tools don't matter -- exploit your creativity. Also, if you find something really creative that you care to let me know of, just drop me an email. And as always, please post your thoughts in the comments section. I'm really keen to hear from you.

Thursday, January 28, 2010

Better Beginnings: How to Capture your Audience in 30 seconds - webinar by Carmen Taran

These are liveblogged notes from the ELearning Guild online forum on Building Effective Interactivity. If you're not a member yet, please enrol -- the benefits are tremendous. I loved Carmen's really interesting webinar about how you can capture your audience's attention during online webinars and in virtual classrooms.

Carmen Taran: Managing Partner at Rexi Media. In the business for almost two decades. Author of the book - Better Beginnings.

Do you remember your first kiss? Most probably yes! People remember first and lasts. How do we recreate the "You had me at hello" syndrome?

Most online training and presentations are boring. And the problem is not that bad things happen, but really nothing happens. Most people multi-task at the time they're in an online training. There's so much information around people now -- we find it difficult to capture people's attention for full hours.

Chase Manhattan has reduced their ATM waiting time by 18 seconds. That says a lot about people's value for time.

So how do we create better beginnings -- as juicy as the first kiss?

Create Anticipation

Hockey players run towards a puck. We love to look towards a future state. We enjoy anticipating what'll happen next. Newscasters do this very well -- "What will Apple unveil next? All of this and more at 10PM!"

Easy technique: Use a key phrase. "At last" a software that improves productivity. "Imagine" what it would be like to disconnect from the brain chatter. This program will open a "new" world for you.

Promise a reward -- for example a freebie you give away during the session.

There is order underneath chaos -- if you can promise to reduce complexity, you'll have people's attention. People want to demistify complicated things.

Don't be predictable. Include a touch of unpredictability. Keep them guessing what'll happen next. For example, you promise how something will work in the audience's specific situation. That way people will keep waiting to get that hugely contextualised session.

What kills anticipation at the beginning of a training program?

A narcisstic beginning -- presenters that begin with boasts about themselves or their company. Don't focus on your ego. Reserve the elements of building credibility for later. Use the unforgiving first minute to gain people's attention. Think about TV commercials, Reader's Digest, movie teasers. Teaching is the act of 'giving' - focus on what people want to know.


Taking your audience on one path and them leaving them on a concept that they wouldn't expect. Show how reality is incongruent to what they would naturally think. Surprise facts help do this.

For example what did the first coin operated vending machine dispense?
Holy Water

How many countries are there in the world?

What's the difference between nerd, geek and dork?
Do some research! :-)

What's the best time to work late?
Research says Tuesday nights between 6-9

What such incongruent stuff can you share in the beginning of your sessions? Think of the crazy statistic that people will never imagine!


One way Carmen demonstrated -- a contest to win the free book she promised. We live in the era of participation. People want to interact with everything. Tivo for example!

  • Asking a question! Chat is your best friend. The more you do, the more you engage people. The moment you ask a question, the brain is programmed to answer. So that means people are thinking immediately. Eg: Atlantic used to hide questions in muffins. These were really intriguing questions and Atlantic's circulation increased hugely during this time.
  • Try an interactive game: Flashcom guru has multiple such games that you can use within Adobe Connect Pro. Make sure that its linked to the content you're presenting.

Visual Thinking

The power of visuals is quite well known -- Presentation Zen.

Edge, Energy, Emotion: You have people's attention when your visuals actually use all three of these factors. Use images that are striking and create the right energies (post modern room vs clutter) When you create just the right visual, you create the right kind of emotion.

This way you:
  • save time
  • are more memorable
  • keep people focussed
Keep in mind texture - you should feel like being a part of the picture. Keep in mind focus - what grabs your attention first? Use full size graphics.

"Good design is design that makes you want to lick the screen."

You cannot go wrong with red. Red captures attention and triggers a whole bunch of emotions! But again go with what your audience may like.

Sometimes color can be a distraction. Consider every so often turning things to black and white and see if the meaning changes.

Abstract concepts -- try visualising those with symbolism. For example barb wire for alienation. Try to brainstorm different ways to depict a certain topic.

Remember, "Any good design takes three eye movements or less."

Vocal Variety

There's a huge amount of power in your voice. Monotones are always boring. Sound natural, passionate and friendly.

As virtual presenters, we don't have the luxury of body language and beautiful facial expressions. We're addressing people who are multitasking. The voice is a transitory medium - we have only one chance to connect with people. We delete voice mails after listening to it for 10 seconds. No one has the time to listen to something very long.

Add more melody and pitch to your voice. Modulate your voice and don't be predictable. Doesn't matter if you go up or down -- its important you change your tone. Try highlighting adjectives and adverbs in your speech and change your tone by stressing those. That creates a great radio announcer effect.

The ear listens more when there's variety. Use your host, co-present your sessions if need be.

Practice by picking an everyday phrase and say it with various emotions.

Monday, January 25, 2010

Here's how I'm approaching Personal Knowledge Management

A few months back, Harold Jarche wrote a very interesting article about sense making with Personal Knowledge Management (PKM). Harold suggested a model that he uses to manage his personal knowledge and stay on top of his social media intake. I strongly suggest that you also look through the webinar he did on PKM at the LearnTrends conference. I think the article is a great reference for anyone that claims to be getting overwhelmed by the volume of information out there on the web. I have had this problem for ages as well and given that I'm a Getting Things Done (GTD) guy, I wanted to make my knowledge management fit into my regular scheme of life. So, at the very outset let me tell you that the names of the steps on my KM model are stolen from David Allen, though the content of these steps may be a little different from how Allen describes them in his book. Anyway, lets quickly look through the steps I go through to make sense of all the wonderful information that I come across on the big broad internet.

The First Step - Collection

I like to keep my collection mechanism automated. I work at least 12 hours a day on a regular basis and with 8 hours of sleep added on, there's very little time I have to manually collect information. I'd rather have all the information collected for me in advance, so I can get to processing it thereafter. So here are my channels of collecting information:
  • I use Google Reader to collect and aggregate all of my information from news sites and blogs;
  • I use Twitter to collect and aggregate all of the information that my social network wants to throw my way;
  • I often get information from some other sources like webinars, forums, IM and email;
Here's a quick video tour of my most prominent channels to collect information and you can see how I ensure that the information stays contextualised in the right places.

The Second Step - Processing

One of the things I know for a fact is that even when I have all of this information collected automatically, I'll never ever be able to keep up with everything. I was at DevLearn last year and Leo Laporte in his keynote said, "Its a river of information, dip your foot in whenever its convenient." So the first rule for me when processing stuff is not to fret about staying on top of everything. So here's what I do to process my 'stuff':
  • If I miss something really important, my network will bring it to the surface again at some point -- so missing important stuff is something I try hard not to worry about.
  • I set aside a few fixed slots of time each day to look through my various collection channels of information.
  • During this time, I try to skim through all the information that has come my way, while resisting the the information to read through each of them.
  • I ensure that everything I wish to ignore is separate from the things I actually want to pay attention to.
  • I organise the things I want to pay attention to as I perform the processing step.

The Second and a half Step - Organising

I call organising the second and a half step, because I really almost do it simultaneously with the processing. My organisation revolves around one concept and one concept alone -- tagging. So here are my organising rules:
  • If I receive interesting information on twitter, webinars, forums, IM or email I socially bookmark it on Delicious and add an appropriate tag to it.
  • If I find interesting information from any of the blogs I follow, I share and tag it on Google Reader and at most times when I have the energy I add it to Delicious as well. (I've just started to do this with some discipline, so don't be surprised if my tags on reader in particular don't lead you to much)
Here's a quick video of how I organise my information.

Using my information - Reviewing & Retrieving

Once my information's organised the right way, all I need to do is search on Delicious and/or Google Reader and I should be able to find what I need. What also helps with social tools like Delicious, is that you can benefit from all the PKM that everyone else is doing. So I have power users like Dinesh Tantri on my network and now, I have access not just to the information that I've put up on Delicious, but also to all the information that my network has put up on Delicious. So I combine the power of tagging and search to find what i need, just when I need it - yaay! Take a look through the video below to see how I usually get around my personal and social knowledge base.

So since this blogpost was about how I'm managing my knowledge base, here are some of my aggregated resources that you may find useful.

Firstly my shared items on Google Reader (not many right now, but will grow). Also, here are some news feed bundles I've created which you may find useful:
You can also browse through my Delicious bookmarks and look at the bookmarks from my network. And just in case you got excited about RSS and twitter just because of this blog post, then do check out the links below:
The RSS feed for this blog
My twitter handle - @sumeet_moghe

As always, don't forget to let me know how you found this blogpost. Your comments are always welcome and I'd love to hear what you think.

Friday, January 22, 2010

Agile Bengaluru 2010 - Facilitating Dialogue in situations of Conflict (session outputs)

As promised, here are the workshop outputs from the session Rixt Wiersma and I ran on the topic of 'Facilitating Dialogue in situations of Conflict' at the Agile Bengaluru 2010 conference. It was a really enjoyable session for us as participants and we had a wonderful crowd that impressed us with their keen interest in the humanistics of Agile software developments

At the end of the exercise, here are the thoughts that teams had about dealing with conflict. I don't have record of all the tips and discussion that cameup in the debrief, but this was all the stuff that the teams wrote up on their flipcharts.

Behaviours that facilitate dialogueBehaviours that hinder dialogue
  • An initiative to get the bigger picture (what are we trying to achieve here? who is involved?)
  • Understanding the problem well, before jumping into solution mode
  • Timeboxing often helps the team rally to a decision
  • Listening to everyone - no views ignored (came up multiple times)
  • Being focussed on the discussion at hand and the goal in sight
  • An openness to clarifying doubts at the moment they arose
  • Collective ownership - participation from the whole group
  • Respecting and acknowledging other/ differing opinions
  • Deciding a strategy to begin with and iterating from there (came up multiple times)
  • Everyone trying to understand one another
  • Asking questions and seeking opinions. eg: What do you think? Do you agree?
  • Speaking in a calm tone of voice
  • No language barriers
  • Logical Thinking
  • Agreeing to disagree (concurring with the team)
  • Interest based negotiation
  • Getting stuck in your own views of the situation
  • Too much focus on the process of the discussion than on the rationale presented or even the result
  • Over-ruling others. A strong voice often stops others from expressing themselves freely and in the end may prevail as the only voice.
  • A hurry or unnecessary 'push' towards decision making
  • Avoid making assumptions. Make assumptions explicit if any
  • Forcing your thoughts on others
  • Not letting others speak
  • Personal conflicts!
  • Not making understanding explicit. (People don't have visibility into all aspects of the problem)
  • Unequal participation
  • Hidden agendas and biased priorities
  • Positional bargaining
  • Sidestepping the emotional side of the conflict. (its important to address these concerns)

Here are the slides from our talk, just in case you're interested. Thanks everyone for attending -- hope we get the opportunity to do this in other places as well.

Agile Bengaluru 2010 - Jeff Patton's Story Mapping session

These are live-blogged notes from Jeff Patton's session on Story Mapping which I couldn't upload until late next morning, due to a lack of internet connectivity.

Jeff Patton: Started doing XP in 2000 (ex TW'er). User stories part of Extreme programming at the time, so he has a decade of experience of this thing. Claims to have figured this out only in the last 1 year. From my experience I know Jeff to be one of the most respected analysts in the industry and a name to reckon with in the area of agile customer experience.

Its common practice to use user stories in SCRUM today. 'Everybody touches these user story things today'. Developers, BAs, testers, product owners, what have you.

A lot of responses came out to define User stories:
  • Wishlist
  • Requirements defined in the words of the customer
  • small usable output valuable to the customer
  • unit of functionality
  • business process to be implemented in the system
  • non-functional requirements
  • has a notion of value or priority
  • a unit of testable functionality

Therefore: "User stories are different things to different people."

So we can't all be possibly right. But we are!

So who is a consumer of a user story?

A developer may need
  • implementation details
  • small in scope - shouldn't take too much time
A tester may need
  • Acceptance tests
  • User's perception of functionality
A user may care about whether the user story lets him achieve what he wants

A product may owner care about
  • time to market
  • cost to build
a project manager may care about
  • no of resources
  • schedule, cost, quality, constraints
  • risks
  • is it estimable?
a business stakeholder may care about
  • return on investment
  • quality
  • burn-rate? did they mean velocity?
  • how does this fit in my product strategy?
  • competitive advantage
  • is it big enough to give me profit?
a UX person may care about
  • role/ persona we're building for
  • user's goal?
  • meta-details of the story? a.k.a context
  • is it big enough to give me feedback?
By the time we address all these concerns and put all the details in, it becomes a real 'fat' document that perhaps needs a binder to hold! Everyone has a view on what the user story needs to have. Its really easy to abandon good old stories because its not easy to fit all this fluff into them.

Jeff threw out the word 'boundary object'. User stories are a boundary object -- its information that's used in different ways by different communities. Its interpreted differently across communities, but has enough immutable content to maintain integrity. The big challenge is to make user stories all they mean to different people without making them into requirements specification documents.

User stories are still a 'token for a conversation'.

Here's where story mapping comes in. Jeff then started off to demo building a story map and asked the group to come up with ideas for products.

Jeff picked an application for people new in Bangalore to know about auto-rickshaws, destinations, right prices, etc. They called the application - autorickshaw registry. The 'business value' of the application:
  • public should be able to use this report behaviour
  • police should be able to regulate auto drivers
  • the public should be able to get auto-rickshaw information from this site

The benefit for the stake-holders would be:
  • police can do their job better - provide more safety (overall better law & order)
  • the public sees more accountability for auto-rickshaw drivers
Jeff ordered the story map by putting the persona on top and placing high-level coarse grained scenarios/goals under them and then user story-like requirements under them. This continued for a while with the story map -- with a really passionate customer who just kept hammering her needs onto him. Jeff did his best to facilitate and come up a with a story map. You can take a look at Jeff's blog to know more about the process of story mapping.

The cool thing about the story mapping process is that it tells a story of the system more than an isolated story in a flat product backlog. As Jeff would say, "the new product backlog is a story map". The fact that its attached to a concrete, real persona makes it meaningful. The ordering of a story map often is:
  • Business Value (the purpose of the system)
  • Personas (the people involved)
  • Category of functionality (user activities - cluster of things that people do. eg: ordering and pricing rickshaws, SMS activities)
  • Actions performed (user tasks)
  • Details for that task
Jeff suggested that we should beware of templates (as a, i want to, so that) - they're useful but shouldn't be dogmas. A story map exactly explains all those three parts without getting caught up in the template.

An important point he mentions is that discussion is crucial to the process -- we can't be getting into a 'feature bucket' without understanding the system, the context and the value it brings.
  • Story mapping is an approach to organising and prioritising user stories
  • Story mapping shows decomposition and typical flow across the system
    • Reading the activities from beginning to end, helps us understand the flow of the system
Product discovery workshops help us understand the product we're building as a story map. These sessions may include discussion on:
  • the purpose of the system
  • customers of the sytem
  • users, their usage and consequently the value they'll get out it
A few things to remember about story maps:
  • Building a story map may need a huge open space -- even floor space is cool
  • A story map for a reasonable sized system can actually fill a room (can get very, very long)
  • Adding tape lines t the wall lets participants organise stories into layers. Each layer makes a release!
  • Planning incremental releases can be facilitated as a collaborative event.
It was really cool to see a video of the process from a Brazilian client of Jeff's. Great culmination to his hugely informative session. You can email Jeff for a PDF of the handout for his session. I think you will be able to find them on his website too.

Wednesday, January 20, 2010

Use Learning Paths to develop the right Learning Strategy

Last month when I was in Sri Lanka, I tried a local dish called Kottu. Kottu's a simple, yet complex street side dish and it contains roti bread, carrots, beans, onions, other vegetables, eggs, meats, coconut oil; well almost everything you can imagine, thrown onto a pan and tossed together.

Hold on - did I just say 'everything'? That's a bit of a magic word for anyone in the learning world.
"Teach them everything that they need to know."
"Let's ensure we cover everything!"
"In this course we'll teach you everything you need to get started."

I'm sure most of us have heard each of those statements and more and perhaps said some of those things ourselves in our career. The funny thing is, that at the back of our minds, all of us realise there's no way we can teach people 'everything' they need to know. That said, with stakeholders breathing down our necks and the demands of each role at the back of our minds, it's tough to figure how we can let people get off training without teaching them 'everything' they should know.

In recent days, I've been using Learning Paths to determine the right learning strategy to develop capabilities for specific job roles. In fact we've tried this approach with some success in some of our strategic consulting initiatives as well and I'd like to share this really simple technique with you. Read on to learn more...

Introducing Learning Paths

A learning path is nothing but a chronological representation of an individual's learning journey from Novice to Expert in a specific job role. It can look as complex as a multipage document, but for me it looks like a variant of the picture above. There are a few key elements to a Learning Path:

Job Expectations & Recommended Reading

Every job has some expectations against it. As a L&D professional, not only do I like to know the expectations for the role I'm supporting, but I also think that the learner deserves to know without ambiguity what the role expects of her. That way there's a tangible set of goals to work against. A lot of roles have recommended texts to support people at all levels. Making a list of the most important books and resources for the job is always useful not just for new starters, but also for us as learning professionals to design the right learning experience.

Foundation Skills

Foundation skills are the absolute bare minimum skills to start a job. As simple as that. An amateur journalist will not start editing articles on her first day. A novice salesman isn't going to generate regional sales reports. The key to determining foundation skills is to ask yourself (or the SME), "What are the things the novice performer will absolutely not do in their first month on the job?"

Intermediate Skills

Intermediate skills are usually tricky to figure out. The best I can define them is by saying that these are skills people need after having spent some time on the job and after having gained sufficient mastery with their foundation skills. For example, I can ask a novice analyst to elicit and articulate customer requirements as a foundation skill, but it make take the novice some time before she can lead sessions with the team to estimate these requirements or to lead showcases with the customer or to run planning meetings. These will be intermediate skills for the individual.

Advanced Skills

To pick up advanced skills the learner needs to work with other experienced people. No amount of teaching can give people confidence with advanced skills. It takes time, support and on-the-job support. Coming back to the example of the journalist, if she is expected to take over a complete beat with no experience of doing so in the past, she'll most probably need some apprenticeship before she is ready to go on her own.

Acquired Skills

Lastly, there are acquired skills. These skills come with experience alone. Only when people try, fail, try again and get their hands dirty with a number of things and start building appreciation for a their surrounding ecosystem do they pick up these skills. As an example, a business analyst will gain the skill of facilitating workshops and managing requirements pipelines only over a period of time and with experience.

Adopt the right Learning Strategy

This bit of simple, upfront analysis helps us in a few ways:
  • Individuals know where they stand in their learning journey at the company. 
  • Instructional Designers know what the pre-requisites and assumptions for designing learning for any stage are. This way we can avoid throwing the kitchen sink at any module we create (elearning or not).
  • Stakeholders know exactly what kind of support to invest in, to help people grow in expertise
Once we've drawn up a Learning Path, devising our Learning Strategy becomes all that much simpler:
  • We know which skills we can influence with teaching and traditional elearning -- foundation skills and an initiation to intermediate skills lend themselves quite well to these modes.
  • We know that practicing intermediate skills and learning advanced skills needs mentorship and coaching.
  • We know that it takes not just on the job support, but perhaps also interaction with other practitioners and a robust knowledge sharing strategy in the organisation to develop acquired skills. Most importantly this takes patience, because people need experience to develop these skills. Informal Learning, can perhaps shorten the time to mastery, though!

I'm still trying to develop my thinking around Learning Paths and your feedback will help me in finding the most effective way to apply this technique. Please share your thoughts by commenting liberally in the comments section.

If you liked this article, you're likely to enjoy my other posts on similar topics:

The Agile Elearning Design Manual - Think Small (Iterations, Action Maps, Storyboards, and Mini-Modules)
Using the Dreyfus Model to engage people in your Online Learning program
Put your learners on a diet - consider a pull based approach
Empowering learners in an Induction Program

Monday, January 18, 2010

Webinar: Succeeding with Globally Distributed Agile

When: Wed, Jan 20, 11:00 am GMT/ 4:30 pm IST
Here's an invitation for an interactive webinar on "Succeeding with Globally Distributed Agile" with Sameer Deans, Delivery Manager, ThoughtWorks. This talk will shed light on choosing Agile practices for your software development project and on what happens when the offshore value proposition comes along with the fact that the delivery team is spread over several locations.

What you will learn

  • Importance of basic Agile methods
  • How to structure a team in a distributed Agiile environment
  • Practices to overcome challenges in communication and visibility

Speaker Profile

Sameer Deans is a Business Analyst, Project and Delivery Manager at ThoughtWorks with ten years’ industry experience. He is experienced in Business Process Design and has domain knowledge in Banking and Financial Services, Requirements Analysis and Agile Development Methodologies to client engagements. He is responsible for the initiation and growth of several communication channels for distributed development.

Click here to register.

Saturday, January 16, 2010

[Social Learning] ThoughtWorks needs YOU to join our L&D team

At ThoughtWorks we're looking for versatile learning professionals in India with a keen interest and experience in social media. This role will be based out of either Bangalore or Pune. This depends on the current location of the applicant and in case of really exceptional candidates we can consider a telecommuting option. While we're still trying to define the boundaries of this role, here are some of the key expectations and skills required:

Key Responsibilities

  • Work closely with Instructional Designers and facilitators and find creative uses of social media to enhance our existing learning programs.
  • Design new programs with social media as the primary mode of delivery
  • Evangelise the use of social media as a mode of learning in the organisation
  • Research latest patterns in social learning and keep ThoughtWorks on the cutting edge of learning technology adoption
  • Work with existing community leads to ensure that these groups support continuous learning
  • Work with Marketing and KM to leverage existing resources for learning
  • Work with lead Instructional Designer to develop the most effective learning strategy for a performance problem

Key personality attributes

  • A strong background in eLearning/Instructional Designer/Facilitation/Coaching
  • Passionate about technology
  • Exceptional communication Skills (Oral, Written & Presentation)
  • Good understanding of emerging knowledge management principles and paradigms
  • Good understanding of the implications of Web 2.0 & Enterprise 2.0
  • Excellent networking and relationship-building skills
  • Good research skills
  • Ability to collect and assimilate ideas and content from multiple sources internal and external
  • Deeply self motivated and independent
  • Comfortable managing multiple high-priority knowledge requests simultaneously
  • Excellent organizational skills and attention to details

Experience Profile

  • Overall experience of atleast 4-5 years
  • 2+ years of experience in Social Learning/Collaboration/Web 2.0/Enterprise 2.0 or allied areas
Email me if you are interested : smoghe at

Friday, January 15, 2010

Collaboration 2.0 - There's a Shift happening

There's a shift happening and its all around us. We may not be a part of that shift yet, but I'm sure each one of us will soon be. We might want to think that technology is changing the way we collaborate and yes that's true! But there's a lot changing in the way we think as well. Managers are starting to think differently, staff definitely has a mind of their own and are more empowered each day and the focus on collaboration is much more than we saw even 3-4 years back. Over the last week, I've been thinking about the nature of this shift and I've tried to distill down this change into four main areas. Let's see how we're changing!

From Single Source to Crowd Sourced

There was a time when we believed in single sources of good information. Popular authors, popular textbooks, popular magazines, popular news channels, popular radio stations, all led to the birth of Mass media. People believed these authentic sources of information because the people that created information were hugely qualified and apparently quite talented in their field. There was no arguing with that, was there? Organisations were quick to follow this route and then came the age of file repositories and Quality Management System (QMSs). In fact the best people in your organisation would sit all day and do nothing but document 'best practices'. Depending on the policy of your firm, either your manager would have access to this information or you'd have restricted access to only the QMS of your department. And I remember from my experience in my first few jobs, that I wasn't even allowed to share a useful document with a colleague in another department. Apparently that was for 'information security'! Even when it came to project documents, it was either the tech-lead, business analyst or the project manager who created these and the rest of us just looked at them in amazement and were passive users of these documents. This was truly the age of Nupedia style documentation, characterised by control, bureaucracy and long drawn approval processes.

Things have changed significantly today. Most firms worth their name have some sort of collaborative document management system in place. The death of Nupedia and the subsequent success of Wikipedia has led to the large-scale adoption of wikis in the corporate world. Most importantly, organisations have realised that many heads are better than one. Crowdsourcing is turning out to be new corporate buzzword, and as Andrew McAfee might say, mobs have started to rule! The clamour for social and informal learning is getting louder each day if you believe the Internet Time Group. What you'll notice though is that in teams, its not just senior people that are creating valuable information -- everyone is. Teams are quick to adopt tools like Media Wiki or Google Sites to create collaborative workspaces. The responsibility to create knowledge doesn't just rest with managers now -- everyone's responsible. Which brings me to my next point.

From Command & Control to Collective Ownership

Managers are still the bosses and there's no denying that. But with the advent of collaborative, team-based approaches like extreme programming and agile, the definition of leadership is fast changing. Command and control still exists in the workplace but we're doing more to encourage collective ownership. Take the classic case of Microsoft Project and Microsoft Excel based project plans. The only person who at any given point has any idea about where a project is the guy looking at the project plan. Let's flip this over now and bring it over to the collaborative project environment. In this place the team has a card wall instead of a project plan on the manager's desktop. The tasks are represented on swimlanes with each swimlane representing the status of the tasks in it (eg: New, In Analysis, Ready for Development, etc). Team members can pick up cards from the wall an move them to completion across its swimlanes. If there's a bottleneck, the team see's it and rectifies it. Everyone takes responsibility for doing the best they can and the project manager doesn't have to be a supervisor assigning work. At any point, everyone in the team knows what's going on with the project. Its collective ownership in practice.

Modern project management tools are starting to embody these very characteristics. I work for ThoughtWorks and there's no secret that I'm a big Mingle evangelist. But trust me, Mingle is definitely one of the best project management tools that you can lay your hands on. It uses the card wall metaphor for the team to have visibility into whats going on. Its web-based, so all you need is a browser. It has various reporting and visualisation modes for your project data and packs in its own wiki for your team to collaboratively create documentation. I strongly recommend that you download it and take it for a spin. Mingle's free for a year for a team of upto five users, so its really great to try out if you have a small team.

From Inward Looking to Outward Looking

In my first job, I was not allowed to share documents from my department with people in another department. To do so would be an information security violation and consequently a firing offence. For any problem I faced, I could only look at my team because others had absolutely no idea of what kind of work I was doing. In a similar way, people in other teams had no way of using my help, because just like I had no idea of what they were doing, they didn't know what I was good at.

Things have definitely changed. We're more keen on breaking down silos and departmental boundaries are become more and more porous each day. We don't have to be only inward facing to find our solutions -- we can ask our friends in other departments, we can find people with similar interests who aren't in our companies, we can look outwards to our Linkedin contents and the blogosphere to find solutions. The possibilities are limitless. As we break down walled gardens in the enterprise, knowledge sharing improves, the cream rises to the top and everyone can benefit from everyone's thinking. Wikis and cloud computing using platforms like Google Apps are making this almost an out of box exercise.

From Structured to Freeform

One of the enabling forces behind all of this perceptional and behavioural change is obviously technology and I can't help but remark how the preference for platforms is changing. We loved email and we still do, but there's a huge shift towards more free form and frictionless tools. So while email was the cool thing a few decades back, we've moved to wikis and blogs, then the cloud and now Twitter and Google Wave. To supplement good old email, Twitter and other microblogging platforms support status updates while Wave supports in team collaboration, planning and discussion. The phenomenon of emergence allows us to still have structure only we don't need to develop hierarchies and complex taxonomies -- the structure appears over time, based on the patterns of usage. The larger the group, the quicker this pattern emerges; the smaller the group, the more people need to have a reason to participate. Technology is not just cooler, its more representative of the way we think and participate.
As you can see, the shift is real -- its happening all around us. All we need to do is give in to this change and evolve. Its an exciting time already and the future promises more - dont you think? Let me know by adding your thoughts in the comments section.

If you liked this post, you may like my other posts on the topic of Enterprise 2.0.

Also next week, I'm speaking at the Agile Bengaluru 2010 conference on the topic of "Facilitating Dialogue in situations of Conflict". It promises to be a great event, so please come over and interact with all of Bangalore's Agilist crowd. And don't forget to swing by and say hi to me and other ThoughtWorkers. I'd love to see you at my workshop as well.

Saturday, January 09, 2010

Do high-performing teams always need retrospectives?

A few months back Patrick Kua wrote a blog conjecturing if the lack of retrospectives is really a smell. Pat mentioned how he was very lucky that the team had some really strong people who got things done and kept the project 'continuously improving'.

To quote Patrick,

"It’s amazing what a bunch of energised, passionate and people with the “solve the right problem once” attitude can achieve."

Reminiscing this post from Pat, I had a few thoughts:
  • Given we agree that:
    • retrospectives are a 'best practice';
    • and that they are a tool for improvement;
is it fair for us to say (at least theoretically) that we can take this 'best practice' to an extreme level just as rationale behind extreme programming may suggest?
  • Second, Agile methods (at least theoretically) assume a team composed of the 'best people' who are 'generalising specialists' or 'versatilists'.
  • The key to having a really strong team could then be mechanisms that not only encourage strong communication, but also those that allow teams to recognise problems, find solutions. That then will fuel continuous improvement, perhaps making retrospectives purely an optional ritual.

What could these mechanisms be?

My passion for retrospectives set aside, I realise that the practice is definitely more than a decade old in the mainstream. Things have changed significantly since then.
  • More teams understand the value of solving problems 'just in time';
  • Command and control leadership may have not disappeared from the horizon, but leaders are slowly discovering their roles in empowering their teams to take more control of situations and problems.
  • Technology is changing fast and our ability to use tools to make problems visible solve them is fast increasing.
Here are a few ideas I had to increase communication and to recognise and solve problems on a team. These ideas don't necessarily negate the requirement of a retrospective, but they can perhaps take us one step further to being high performing teams.

A low tech method - daily 'hot topics'

A few months back, we were a team of 7 people with Ritin Tandon at the helm as the team lead. Ritin devised a method for us to recognise issues and solve them on an ongoing basis. In the team area, Ritin put up a flip chart called "Hot Topics". Everytime anyone in the team had something to discuss or a non-urgent problem to solve, they'd put up a sticky on the flipchart. At the end of the day, one of us (often Ritin) would facilitate a quick discussion around our hot topics and we'd volunteer to solve the problems then and there. If we expected that a problem would take time to solve, then one or more of us would sign up to work on it and we kept reporting back progress to the team. Its been a fantastic practice and for the investment of a few minutes each day, we got a huge sense of fulfilment by taking blockers out of our way. What we were doing was a bit of a mini-retrospective each day and that helped us be a continuosly improving team.

A hi-tech method - use Web 2.0 tools to surface and resolve problems.

There are quite a few tools these days that can help create high quality communication in teams. Two tools that I think can be really useful to surface and resolve problems in a team are Google Wave and Google Moderator.
Google Wave
Google Wave follows the paradigm of blips. It could be quite easy to create a retrospective playground on Google Wave where you create brainstorming blips (Keep Doing, Stop Doing, etc) on the wave and people can add their thoughts and following discussion under those blips. In fact I think this could be even better than a ritual retrospective where we often don't discuss issues because of a lack of time. Using this method, people can actually choose to comment on every issue they feel passionately about instead of restraining themselves only because others don't see the value in their thoughts yet!
Google Moderator
Google Moderator is a great social application to crowdsource ideas. You could potentially ask your team an open ended question about ideas for improving the project. As the team posts it ideas, members can vote up the ideas they like the most and provide commentary on its implementation. Over time, you have a nice prioritised list of improvement activities for your project. As you implement these ideas, the burning need for a retrospective may disappear.
Obviously, I'm not speaking from too much experiential wisdom (the lack of proper screenshots is a tell-a-tale sign) and I acknowledge that these ideas may not eliminate the need for retrospectives completely. In fact the goal isn't to eliminate retrospectives (they're obviously a very useful exercise) -- the goal is to continously improve so that the retrospective isn't the only place to achieve this. What do you think? Please let me know by posting your comments on this blog. I'd love to learn from your experience.

Friday, January 08, 2010

The Six Hats of a Trainer

Wow, its 2010 already - a beginning of new decade! It seems like the last year and even the last decade, just went by in a breeze. There have been so many developments in the L&D space in this last decade that have really revolutionised this field. It's as if it was yesterday that Jane Bozarth very smartly predicted that "Trainers won't be replaced by technology. They will be replaced by trainers who are willing to use technology.” This is more true in this decade than it ever was earlier. To greet the new year, I thought I should do a quick post outlining the changing role of the corporate trainer. Today's post follows on from two of my previous posts of a similar nature, which you apparently found interesting:

The Six Hats of a Trainer

Yes, I've read De Bono's work and his "Six Thinking Hats" were an inspiration. In fact my six hats of a trainer are indicative of the various roles that an intelligence age trainer needs to play and as a consequence the different ways she needs to think. Now before I get out of this with egg on my face, let me clarify that I don't expect one person to be good at all of this overnight! That'll take intuitive aptitude! My friend Vijay Colaco takes strong objection to the word 'training' and believes it's akin to how we make animals do our bidding. Vijay OTOH prefers to think about corporate education (on the lines of 3 Idiots), where individuals make informed decisions about the steps they take. What I hope is that as we enter an exciting new decade, traditional trainers can look at their roles with a bigger sense of responsibility and the satisfaction of being able to contribute to their organisations in a more complete fashions. In effect, we'll craft more effective learning experiences and eliminate waste most ruthlessly.

So here's what wearing each of these hats amounts to.

Being a Teacher

"As teachers we focus on helping people acquire general cognitive abilities, rather than on particular performances in specific situations"

The role of the teacher is fairly traditional. Most corporate trainers are pretty good at this already. The key to effective teaching is the ability to help people develop new strategies for thinking and acting. That said, the focus is less on performance improvement and more on new learning. Its important to note that while a lot of modern trainers scoff at teaching and term it as passive, it has its own place especially to empower novices. While teaching is not new to existing trainers, a lot of us could use help with our presentation skills. I find Garrey Reynolds' Presentation Zen to be a great resource for teachers to learn how to effectively prepare, simplify, visualise and deliver a sesssion on any topic.

Being a Facilitator

"As facilitators we're helpers and we assist groups in working together in various contexts to reach the best possible conclusions or decisions."

The game starts to change here a bit. While teachers aid the acquisition of new knowledge and understanding facilitators make it easier bringing out and focusing the wisdom of the group, often as the group creates something new or solves a problem. Facilitators need to have the ability to stand back and let the group perform and interfere only when they see a need to course-correct. The act of facilitation involves creating group interaction patterns that bring out the best learning. This could be limited to facilitating just business as usual meetings or even large scale conferences. In the recent past, my favourite resources for facilitation related wisdom have been ex-ThoughtWorker Jeremy Lightsmith's website on Facilitation Patterns, Steven List's Blog and his interview on Open Spaces with InfoQ and also Patrick Kua's blog.

Being a Coach

"As coaches we actively enable our coachees to develop specific behavioural competencies, as a consequence helping them achieve or improve their performance in certain contexts."

As I've said earlier as well, coaching is a fairly underestimated way of creating learning. That said, I believe coaching to be an "on the ground" job that happens continuously. It's something that should happen on the job and all the time -- it should not be an intervention. That said, to create a crop of good coaches corporate trainers need to don the role of a 'coach coach' or 'master coach'. Through their efforts they need to make mentorship a common practice across teams and organisations. There are far reaching consequences of this investment. There's greater organisational understanding of how people learn. In time, learning becomes common practice and a continuous process rather than an event. In time, the organisation also learns that elearning or training or social media aren't silver bullets and that every extrinsic effort to creat learning falls flat without the intrinsic support of coaching and mentorship.

Being a Designer

"As designers we use creativity and analysis to build instructional solutions that make complicated tasks and concepts simpler."

If you've followed this blog then you know that I feel Instructional Designers need more skills than just writing. Instructional design is easily one of the most skilled professions in the learning industry and when we wear this hat, we are responsible to translate learning visions into concrete resources. I deliberately call this hat that of a 'designer' only (as against instructional designer) though, because I feel that we need to look beyond instructional design alone. I feel we get way too caught up in making things instructionally sound as against picking the low hanging fruit of aggregating 'not-instructionally-sound-yet-useful' information. As a hardcore pragamatist, I often care less about instructional soundness if aggregating useful content gives me a quick win and an easier way to get to a learner. This is not to say that instructional design isn't valuable -- its just that pragmatism and a shorter time to market will give us a sharper edge this year.

Being a Technologist

"As technologists we stay on the cutting edge of technological innovation and harness technology to make the learning experience more effective."

There's no denying that technology is occupying an increasingly large space in education of all forms and at all levels. To avoid technology will only be to live in a state of denial. I can only request my 'training' colleagues across the world to embrace this as an extension of their existing skills and know that this is a great way to utilise their experience of influencing people's learning. Informal Learning is largely accepted as a highly effective way of creating continuous learning and technology is a great way of enabling informal learning. As technologists 'trainers' need to continuously stay on top of emerging trends in the marketplace and we need to embrace the 'don't worry, be crappy' mentality. As innovators, we need to release early and release often and stick our necks out for things that we see potential in. So are virtual worlds the coolest new trend in learning technology? Or is it alternate reality? Or then is it social media? Let's raise our awareness of these trends and at least get our hands dirty to start with. And let's not stop at that alone -- if we see value, let's be prepared to take this to the next level by increasing our engagement with our IT departments to articulate the benefits, risks and issues using shared vocabulary.

Being a Consultant

"As consultants we ruthlessly eliminate waste and evaluate at our learning offerings from the perspective of the business, ensuring that we continuously deliver the most efficient solution (instructional or not) to achieve the performance expectations."

In a previous post, I've pointed to quite a few resources that can help us build our consulting skills. While I talk about Consulting last, its definitely the meta-hat for all the above hats. As service providers to our organisations and clients, we're all consultants. Not only do we need the ability to engage our stakeholders, but we also need to articulate the value of our approaches and determine the right solution to performance problems in the business. Its not enough anymore to be a glorified order-taker for the business -- we need to go several steps forward to look at the entire value stream we're addressing and how our interventions will affect its performance. So, in my opinion, if there's one hat we'll always wear in this decade, it'll first be the consulting hat - to problem solve first and then wear the right hat to implement the solution!
My blogpost is limited to my own experiences with L&D over the last few years, so I have to turn to you for inspiration. What roles do you think trainers will have to play in years to come? What roles are you having to play? Please post your thoughts in the comments section and let me know what you think!
Related Posts with Thumbnails