Apr 242015

2013-03-04 20.13.41Googling, I discovered that the folks over at XCeleratePartners blogged about an Innovation Games for Product Development course I taught in Houston. That was gratifying.

But what was truly gratifying was their write-up about the course (and here’s part 2). Go check it out. You’ll see some excellent details on how the games are played, which one to use for what purpose. And there are nice pictures, too.

Every teacher wants to know that they have made a difference, that their learners “get it.” That’s the true test of training. Not Net Promoter Score. Not standardized tests. The measure of the teacher shows in the real-life performance of their students.

“Educate” comes from the Latin educare, meaning “to lead out that which lies within.” The best learning is centered in the learner — not on the teacher — allowing the student to connect new concepts and techniques to those understandings which they already possess.

ProdBoxThe depth of the XCelerate students’ understanding is demonstrated in their ability to write about the games in a clear and comprehensive way. As an organizational coach, I couldn’t be more glad for the existence of another Innovation Games practitioner.

As an educator, I couldn’t ask for a better compliment.

 Posted by at 5:46 pm
Feb 102012

I love this Google+ post from Dave Gray. He talks about the operation of an aircraft carrier, a complex system with high personnel turnover but no comprehensive operations manual. There is no manual because it would have to be as complex as the carrier itself. Instead, the “manual” for the carrier is the sum of ongoing expertise and learning that is occurring all the time:

When the situation is stable, predictable, and well-understood, traditional hierarchy prevails. But when decisions need to be made quickly, decisions will migrate to the edge, where people can sense and respond to situations in real time.

At the end of the post Dave invites us to use this story as a metaphor for other large complex systems. One such large complex system is the so-called “software development process.” A documented process presupposes a simplistic ecosystem, but the ecosystem of enterprise software development — like the ecosystem of an aircraft carrier — is enormously complex. Beyond one person, a small team, or even a team of teams, enterprise software development is of the same order of complexity as the enterprise itself.

And as such, as Dave says, “there ain’t no manual.”

Sure, we need some abstractions (like UML) to help us quickly get our minds around general concepts. And we need some procedural checklists (like automated code-management tools). But mistaking these for “how to do software development” guides reminds me of Martin Fowler’s warning against mistaking software design docs for the software itself: “the code is the best source of comprehensive information, as the code is the easiest thing to keep in sync with the code.” Martin is reminding us that abstractions of complex systems are useful, but they are not the thing itself. Guidelines are useful, but manuals are useless.

So what do you do when your manual for the system will be as complex as the system itself? You don’t try to foster compliance — you foster learning.

And I have seen that scare the pee out of many people. They don’t want to learn. They don’t ever want to be the “new recruit” who has to learn how to best fit their own talents into that of the organization. They went to school, they have a degree, they have 10 years of experience, they want to prove to their organization that they “follow all the right processes and procedures.”

No wonder something like Scrum — three roles, three artifacts, three meetings, and 1 big rule: “adapt your work to best realize the needs of the product” — can be unsettling.

So, why are we learning to be afraid of learning?

 Posted by at 1:41 pm
Oct 162011

I recently spent a day helping the leadership of an organization make the leap from “can we become Agile?” to “now we’re becoming Agile!”  The problem was one of mindset: getting people to think less about barriers and more about what actions are possible.  My solution involved hands-on experiential learning and structured group debriefing.

I’ve written about it below, but I’m a visual person so I’ve added a lot of captioned pictures if you want the gist, and the how-to “recipe” for doing this mindset-shift yourself is at the end.

Continue reading »

 Posted by at 6:59 pm