A few years back, Martin Fowler our chief scientist wrote that People Matter Most in software development and one of the reasons he joined ThoughtWorks was because he saw ThoughtWorks as Roy - our founder's social experiment. In many ways, as a software delivery and technology consulting firm, what makes ThoughtWorks unique is the outstanding ability of ThoughtWorkers. Its a place I'm quite proud and privileged to be part of. As I've mentioned earlier, elearning development has got extremely commoditized and should really not be very different from software development. Its really important then, that we give people as much importance in elearning development as we do in software development.
Whether you run an elearning consultancy or are a training manager or a team member on an elearning development team, its important to think of how to empower people on your team. How much is your organization maximizing their ability? A lot of what I'm about to suggest in this article isn't necessarily a trivial change. Having said that, if you find value in implementing any of the suggestions I'm making, you may need to plan this change and transformation for the benefit of your team.
Growing Versatilists on the teamWe saw in an earlier post, how there's very little overlap between the skills of different people on a traditional elearning team. I've revisited the current state of the skill map on most elearning teams I've seen in the recent past and right alongside, is what I think should be the minimum overlap of skills in the team. A Instructional writer/ designer should be able to do some testing and some building work; a builder should be able to do some writing, some testing and some graphics work and a graphic artist should understand the basics of building. Of course, any versatility beyond this helps. I'm a big advocate of Learning Generalists as against Specialists, so the more skilled a professional, the higher they rate in my book.
How environment affects versatilityThe above floor layout will create a sense of deja-vu for those who've been in my position. This is a floor layout I observed first hand, four months back at an elearning firm. The seats I've pointed out are those of people on the same project. The graphic artist being a freelancer, doesn't even work on the same floor. I find it funny to think that people communicate using documents to subvert this kind of a layout. I can understand the limitations of forced distribution, but really that isn't even the case with most elearning teams. Its not hard to imagine why a lot of people stay specialists in just one trade. Its not surprising either, to understand why there are so many silos in some elearning outfits!
The waste of documentation inventoryThe above picture represents the typical flow of work across silos. Notice the amount of documentation that gets created in this process. The learning consultant has a "consultanty" conversation with the customer to determine the "Instruction Strategy". This goes into a document that gets passed a few desks across to the Instructional Designer. The designer spends the next few weeks writing out a script, filling out matrices and creating more documentation to pass on to the builder. The builder on the other hand passes on graphics descriptions in a document to the graphic artist. The graphic artist sends out images based on his understanding of the document and if we're lucky then the back and forth isn't very long. The builder then passes on the completed module to a tester and the tester sends back documents with bug descriptions to the builder. If we're lucky then this back and forth isn't very long. All this is usually governed by a set of technical specifications documented by the Technical Consultant who sits nowhere near anyone doing this work!
Now I'm not trying to say that documentation is bad! What I'm trying to say is that documentation as a substitute for face to face communication is not ideal and is really a waste. The biggest waste in this process is the elearning script. Why do we need to write a script for 200 screens of elearning, when:
- all that the builder can build in a day is say, 15 screens;
- we should be showing the client training for the highest priority actions first;
- we can simply explain most of these screens through face to face conversation;
- an initial showcase of our work could render all of the scripting useless!
Simplify your work environmentA small, yet highly political change of the workplace can hugely simplify this approach. What if everyone sat on one table with no cubicles? People can choose seating that was convenient for the day -- depending on who they need to collaborate with. We can shout out ideas across the table since we're all within earshot. All of a sudden writing documents doesn't even seem like an option. Its so much easier to talk to the other person. Yes I understand that "Learning Consultants" and "Technical Consultants" can't always sit at the table because they have their fingers in many different projects. Its important to think of whether you need these roles in the first place. Given that your overall design is simple and modular, most projects can do without these overheads. If you do need someone like them though, they should be obliged to spend some time on a regular basis with each team.
De-managing your project - think "Collective Ownership"I strongly believe that every group initiative needs a leader. I'm not so sure about layered management though. Its interesting to see how you can put a bunch of smart people together and see how they take charge of a situation once you allow them to self organize. This is a huge paradigm shift from the command and control structure that I've seen in some elearning outfits, but then I'm fast seeing other outfits that believe more in collaboration than coordination. There are a few management questions I still need to answer, so let me try my hand.
Managing SchedulingNow if you noticed the project manager was doing a lot of scheduling work to get the right person to work on the project at the right time. This is no easy task -- almost equivalent to mastering the space and time continuum! Often, there's either a person waiting for work or work waiting for a person. This idle time is a waste in the process. A simple design up front, colocated-team-on-a-table approach takes away the scheduling overhead from the project manager, because every person downstream in the process pulls work from the person upstream. Which is to say:
- We keep design simple, by using an action mapping approach;
- We ask the customer to prioritize actions based on their perception of business value;
- We (builders and designers) storyboard the most important action and activities first;
- The builder and designer work to build the first activity together;
- The graphic artist builds the visuals in collaboration with the builder;
- The tester tests the first set of screens;
- The customer looks through this set and signs off;
- In the mean time, the process has already started another cycle with another activity
Try a Card WallThe traditional project manager, who would be obsessed with a project plan can now create collective ownership in the team by using a Card Wall. A card wall is a simple visual representation of the work in progress for the current iteration. Depending on the different stages of work that each card goes through, you can construct the wall by making swim lanes for each stage. The progress of an individual card is indicated by its place on card. With a card wall, its quite easy to see where your bottlenecks are. For example, if you see a lot of cards in the "Waiting for Testing" lane, then it means that your testers perhaps need help in clearing out activities/screens waiting for testing.
On Agile teams, each morning the team meets for 15 minutes for a standup, describing what they did the previous day, what they're doing today and their blockers. This discussion happens in front of the card wall, so that issues can be pointed out in correlation to the work in progress. This empowers the team to find solutions to their own problems and generally creates a great problem solving culture in the team. With a colocated SME/ customer you can avoid creating reports as well (if they don't mind). The card wall is a snapshot of the work in progress for the team. If you need more convincing, read this post to see how such a lightweight tool makes a huge difference.Now I fully agree that this is difficult for a distributed team. I strongly recommend the use of a collaborative project management tool such as Mingle, to facilitate this kind of a process. I'll try to address that in a future post.
So, if the team is empowered to pick up work on their own, manage their workflow and solve their problems, what need do we have for a project manager? Here's where I feel the project manager could play a project leader. I've written earlier about what I believe to be the tenets of leadership. The project manager/ leader's time should get spent in coaching, mentoring, absorbing external pressures and providing help and guidance in removing team blockers. In time, the project manager builds these essential leadership skills and by helping to remove blockers for the team, can possibly emerge as the team's ultimate generalist.
How did you like this post? Please feel free to let me know. If you liked this post, you may just like some of these other, related posts:
The Agile Elearning Design Manual - Problems with existing Approaches
The Agile Elearning Design Manual - Agile Re-explained
The Agile Elearning Design Manual - Think Small (Iterations, Action Maps, Storyboards, and Mini-Modules
The Agile Elearning Design Manual - Iterations huh?
My Tenets of Leadership
From Training Specialist to Learning Generalist
Why your Training Team needs Versatilists