|This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group.|
This is a personal story by Net Objectives Founder Al Shalloway that describes how he learned the “Pickup Sticks Model of Teaching.”
Here is an approach I use when deciding what I need to talk about when teaching a course. This approach informs my professional coaching practice and engagement with clients.
In the mid 1990’s, I accepted a consulting role at Boeing. My job was to guide about 300 FORTRAN / mainframe programmers into an object-oriented C++ / Microsoft Windows NT® environment. This was a big shift for me. Before this, I had been doing mostly software development and support. I was very good with C++ and object-oriented design and programming and was fairly reasonable at one-on-one coaching. It looked like fun and more importantly, a relief from the grinds of software development.
About a month into the engagement, the reality of the situation started dawning on me. Three hundred people in a year! How was I supposed to do this?
When faced with a situation in which I don’t think I can succeed, I take one of two approaches. The first is to imagine failure and see if I can survive. For example, in this situation, I could imagine doing such a bad job that they let me go. My ego would be hurt, but I would still be employable so I could see that I could get another job and could manage this failure. Visualizing this helps remove the fear of survival issues and helps me concentrate on the tasks at hand. However, it won’t help me figure out how to get the job done!
The second approach is to scale the problem into something more manageable: See that I can handle that and then work on scaling the solution. For example, I could imagine being able to handle having to train only one person in C++ / object-orientation. Of course, the client wouldn’t be happy with me if that is all I did, but at least it gave me some perspective.
Taking the second approach, I said to myself, “OK, how do I train one person in C++ / object-orientation given one year to do it?” I felt confident in teaching the language. The tricky part was teaching object-orientation.
I asked myself, “What’s the difference between me and a him? Is it that I am smarter?” Not necessarily. Also, having someone smarter than me to teach would make my job easier but would still need to happen. Well then, what’s the difference?
Before I give my conclusion, let me give a little background. I have taken a number of courses in communication and personal development. They teach a powerful paradigm that a person’s reality shows up in the language constructs they use; that is, how they talk about things. It reflects what they pay attention to or what distinctions they have of the world around them. With this in mind, I came to the conclusion that,
the difference between me and someone who didn’t know object-oriented design is that when faced with a problem, I would look at certain things they wouldn’t, and they would look at certain things I wouldn’t.
Let’s talk about polymorphism
For example, given several variations of a task, I would realize there was a common conceptual way of describing the task and that I could make an interface represent this conceptual, shared method. I could then implement this to polymorphically hide these variations.
So how do I get across this point about polymorphism? My first inclination might be to explain polymorphism as a thing; that is, I look at it and describe it. However, it’s not just that I look at some things while others less able than me look at others; rather, it’s that I can see some distinctions that others don’t pay attention to and really don’t even notice. I therefore have to break the concept “polymorphism” down into smaller concepts.
One thing I’ve learned as a trainer is that if I pretend things don’t exist in reality but are a construct of my mind, then I can be more effective. Because they don’t exist, I can’t assume anything I say about them will be in the listener’s mind. This forces me to explain things from basic features. If I know something about my listener, I may assume certain common understandings and be able to move faster. But this is easier to do right than making an assumption that is incorrect. In other words, when something exists on its own, I can describe what I see. But maybe the distinctions or features I see are not what someone else sees. The person doesn’t readily understand my descriptions because there is not a common understanding – an understanding I am assuming exists and therefore not speaking to.
Now, trying to explain “polymorphism” as a thing is often difficult because I am not speaking to my listener’s reality. Maybe I can’t know their reality but at least I can try to start with they almost understand. First, understand the distinctions upon which polymorphism is based. Then, begin teaching those distinctions that my students almost understand.
For example, when teaching polymorphism, it is tempting to say, “you must not have duplication in your code!” But the question remains: “What is duplication?” Clearly code that is the same is duplicated code but there are other kinds of duplication such as duplication of a concept, duplication of a rule, duplication of a switch construct. It is better to think about something that they “already almost understand” that matches what I want to teach them.
A better starting point
If you use the exact piece of code in two places, make a method that implements the code and call that method in both places. Then, when you change this one method you affect both places.
Of course, this isn’t all there is to avoiding duplication but with this insight, the others are a little easier.
Next, I have to figure out the next thing that they already almost know and address that. And that is the point. After teaching one distinction that someone already almost knows, they now already almost know a different distinction.
The approach for teaching then is, instead of focusing on what I want to teach them at a high level (polymorphism, interfaces, …), focus on the separate distinctions on which these are built.
The order I teach them in is simple – teach them the ones they already almost know. After they know these, there will be a new set they already almost know.
I’ve been told this is all you can teach anybody anything anyway: what they already almost know.
The pick-up sticks method of training
I call this approach the “Pick-up Sticks Method of Teaching.”
When I was a kid, my brothers always beat me at the game of pick-up sticks. I was always tempted to go after the high scoring sticks that were buried in the pile because I could get more points. This is like going after polymorphism before all of the distinctions on which it is based are stated. Finally, I learned that the better strategy was to remove the stick on top (the distinction already almost known). And then to focus on the next new stick “on top” (a new distinction is now already almost known).
Taking this approach in training, my students and I eventually reach the goal: all of the sticks (distinctions) have been picked up and we have learned!
It is what makes a daunting task manageable.
This chapter was an excerpt from FLEX for the Disciplined Agilist: FLow for Enterprise Transformation (online book). It has been edited to fit into the Disciplined Agile Value Stream Consultant workshop. The Table of Contents for the book is here.