Sometimes I learn new things at conferences and training classes. And sometimes I am reminded of things that I already know.
Two events caused me to see something I knew but had lost sight of:
- Craig Larman mentioned in LeSS class that software developers are trained in computer science programs to gather requirements, design, code, and test, so doing these activities within a self-organizing team is not a big stretch for them.
- Diana Larsen pointed out during the Organization Design Forum that “knowledge worker” is a misnomer for software developers—a better name would be “learning worker” because we are continually learning more about our customers, our business, technology, etc.
Software development is all about learning! That sounds obvious, and in some ways, it is. It is the foundation of our work. Learning is the bottleneck in delivering software. And yet I see organizations try to optimize teams and processes based on knowledge rather than learning. Teams are often designed based on people’s roles, assumed skills, and existing domain knowledge instead of allowing cross-functional teams to self-design based on their understanding of people’s skill sets and social preferences.
I also remembered a few facts about adult learners that further amplified for me why scrum teams can be great learning vehicles:
- Groups learn faster than individuals
- An individual’s commitment is proportionate to personal investment in design
- Highly cohesive groups influence each other more than non-cohesive groups
- People have to see practical connection
How is your organization design supporting learning rather than knowledge? How is it not?