Specialization is already common in training development teams in which we have participated or led. The instructional/LX designer often leads the work, often supported by other instructional/LX designers, a media person or a media team, and one or more developers that encode the instructional content, build software driven components, or modify the courseware "player."
As individuals, we are often hired for our specializations. However, we need to be open in Lean-Agile to work outside of those specialties to help the team achieve better throughput. For example, during QA content checking and QA functionality testing, when putting the components or courseware through the QA checklists and test cases and identifying defects, all team members can perform this work. Lean-Agile is not about zero specializations, but rather it is about people being able to do more than one task well in the product development process.
Rather than trying to generalize too much, however, it is often faster to let the specialist do the thing they excel at because they are faster at it and it may produce less rework. For example, instructional/LX design is something that we have found not all people do well from scratch. Some have been involved in training for a long time, especially as instructors in workplace training. However, their instructor background was often primarily course conducts rather than developing new courseware from scratch. Modifying someone else’s fully developed course is easier than developing a course from nothing, synthesizing content from SME interviews that supports well-crafted learning objectives. So we have learned to ask during interviews about their experiences and challenges starting from zero to better sort those who can newly create from those that are better at revising.
Another challenge of generalization is the pay rate differences. instructional/LX design often pays more than media development. And software development may pay even more than either depending on experience and the technology involved. All of these roles use design thinking to varying degrees with different focal points, instructional work products, media work products and software products. We have had success with people who have multiple specialties, especially with game engine development for training courseware. So instead of thinking pure theory, adapt Lean-Agile to fit your organization’s situation and circumstances. If there are significant pay rate differences, you may need to adjust who is on the project team and move the highest paid specialist to another project without as much generalization. Your decision points may vary depending on how tight of a financial ship your organization runs. Some groups have much less a sense of how much they are spending than others on a monthly or sometimes weekly basis. If your group has to use earned value management and check costs weekly against plan, or if your group developed a plan that moved specialists away at a particular point in the project, then you will have to adapt Lean-Agile to your circumstances. Make a testable prediction, or hypothesis, and conduct some experiments to see what the data tells you is the best for your situation.