The Learning Team

A Learning Organization seems so obviously desirable as to be ubiquitous yet most of us will never experience one.

Learning Organization
A term for an organization that fosters ongoing learning among its members. Because learning is ongoing, the organization continuously transforms itself.

If we can't fix our inept organization, perhaps we can influence our team.

All politics is local.
― Tip O'Neill

All politics is local means that our success is tied to our ability to understand and influence our constituents.

My constituents are my teammates.

We owe ourselves the courtesy of modeling the kind of behavior we want to see in our teammates. We owe ourselves the courtesy of striving to be good learners and aspiring to be good teachers.

“You cannot force commitment, what you can do…You nudge a little here, inspire a little there, and provide a role model. Your primary influence is the environment you create.”
― Peter Senge

Fun teams cultivate learning. The rest suffered from varying degrees of toxicity. I resolve to choose fun. I urge you to join me.

People unfamiliar with the nuts & bolts of software development imagine it's an engineering process, but it's a profoundly human activity.
― Alan Cooper

A Learning Team

The closest I've been to a learning organization has been flashes of a learning team practiced by me and my teammates.

If your teammate responds to a question by affirming, "That's a good question", all indicators point to a learning team.

A well-tended and searchable wiki  ― thanks Ward ― that has up-to-date on-boarding instructions, and frequently used command sequences, is one sign of a learning team. On the other hand, admonishing a teammate to "look it up on the wiki" is a red flag your teammate is missing a teaching opportunity. Such opportunities occur whenever a teammate asks a question.

Missed teaching opportunities occur whenever a teammate stops asking or regrets asking.

A few red flags that you're falling short of a learning team are:

1. Defensive Postures
2. Shaming Mechanisms
3. Cynicism

Defensive Postures:

We often recognize defensive postures in ourselves and in our teammates. Defensiveness is a burden and a buzz-kill. Excise it.

“It is not the absence of defensiveness that characterizes learning teams but the way defensiveness is faced”
― Peter Senge

Your teammate doesn't want a knife in the back. He wants to you have his back. When your teammate is defensive, she's probably not pro-active.

Shaming Mechanisms:

Sometimes the original idea for a practice, or the spirit of an idea, gets lost over time.

Practices should never devolve into a mechanism for shaming.

Examples of sound practices that have gone toxic:

• Continuous integration is a highly recommended, ongoing health-check, BUT never shame a teammate for breaking the build, or for failed functional tests. I suffered through an immature team that handed around a stuffed Build Monkey to anyone who broke the build. I deep-sixed the monkey.
• Test-First is a valuable learning tool, as is Test-Driven. Both play a role in ensuring quality. BUT avoid shaming a teammate for not adopting them as a matter of course. If one or the other is an agreed upon team practice, then reward good behavior rather than shaming people for slip-ups or for regressing under pressure.
• Estimation and burn-down charts, once handy tools to make wild-ass-guesses at story sizes and to make progress visible, have become blunt instruments for flogging in the hands of command-and-control managers. NEVER use a tool or a process to hurt people.

Process alone is usually innocent. It is converting ideals into expectations that can be toxic. For more on shaming, see Say No To Brogrammers.

Cynicism:

Cynicism grows from the loam of unmet expectations. One tip:

Don't romanticize your teammate's abilities to be a "craftsman" ― particularly if he must measure up to a poorly articulated definition of craftsmanship.

By avoiding romanticizing the notion that developers are craftsman, you'll be better equipped to avoid the psychological baggage of unmet expectations.

“In combating cynicism, it helps to know its source. Scratch the surface of most cynics and you find a frustrated idealist – someone who made the mistake of converting his ideals into expectations.”
― Peter Senge

Cynicism grows from trying to change too much. Forget about the larger broken organization for now. Remember all politics is local.

Get to root causes. If it's something the team can fix, fix it before it devours all optimism.

Lastly, try modeling vulnerability rather than oozing cynicism. Your teammates will appreciate it.

Getting to the Learning Team

A learning team, like a happy family, requires practice and vigilance. A learning team gets sustenance from people expressing ideas and opinions with reckless abandon.

Remember everyone has a different take. The spectrum might range from Michelangelo to Cowboy Coder.

To voice an opinion or posit an idea we need to feel comfortable speaking up and we need to be practiced at listening. A learning team starts by modeling listening, practicing Beginner's Mind, and aspiring to teach.

"In the beginner's mind there are many possibilities, but in the expert's mind there are few"
― Shunryu Suzuki

Learning frequently calls upon us to step out into the vast unfamiliar. Learning can make us uncomfortable because it means exposing our weaknesses. But humility goes a long way toward learning. Practice humility.

The place I'd start to cultivate a learning team is a distributed source control system that supports the Pull Request Workflow.

Pull Request Workflow:

If you use no other means to get to a learning team, try the Pull Request Workflow on GitHub and Bitbucket. The PR Workflow encourages you and your teammates to:

• publicly view proposed code changes,
• publicly offer options or discuss alternatives, and
• approve all changes ― shared responsibility.

Two outcomes of the PR workflow are:

1. Quality - Under the assumption that two-plus heads are better than one, quality invariably improves from peer-reviewed code; and
2. Learning - Newbies can view other's code before it's merged and benefit from the public dialogue about how the code might be improved. Old hand's are given the golden opportunity to learn and the golden opportunity to teach. Double gold. Be respectful. No one loses.

See Pull Requests for Teams for more details.

An ideal teammate teaches you something and wants to learn from you. Seek or grow a learning team. Resolve to choose fun.

REFERENCES

• Beginner's Mind, Dumb Luck & Agility, Bobtuse, 20 April 2009.
• Pull Requests for Teams, Bobtuse, 28 August 2013.
• Say No To Brogrammers, Bobtuse, 26 May 2012.
• TDD is dead. Long live testing. David Heinemeier Hansson, 23 April 2014.
• The Fifth Discipline: The Art & Practice of The Learning Organization, Peter Senge, 2006.

ACKNOWLEDGEMENT

Hat tip to Chris Bartling for introducing me to aspects of the learning environment and for nudging me into the vast unfamiliar of open source.

Naming Conventions

On my last three software teams I have had a teammate named "Bob". What are the odds of a Bob having a teammate named Bob? I can understand a Horatio or a Cuthbert, but not another software guy named Bob.

Bob is a rare name. Ask any SETI scientist. Okay so maybe the software world has a notorious Uncle Bob, but I suspect Uncle Bob is a actually a closet Robert (see Robert Cecil Martin).

Before my software gig, I probably encountered two or three Bobs in my lifetime, one of whom was my father. It's pure dumb luck that I'm not a Bob Jr. Being branded Bob Jr. would be worse than having a Microsoft operating system named after you.

But there's a solution to this madness. The next time I encounter another Bob, I'll diffuse any confusion by pulling a Steve Jobs, who when he encountered a designer named Steve on the iPhone team, declared,

"Guess what, you’re Margaret from now on”. ⁽¹⁾
― Steve Jobs