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.

A Personal Approach to Agility

I will always appreciate the spirit of the Agile Manifesto. I revisit the 12 principles behind the Agile Manifesto on occasion, particularly after experiencing recipe-driven nincompoops who use the principles as blunt instruments to flog me and fellow developers.

I am also increasingly surprised by how disconnected Conference Circuit Agilists have become from producing software. Pithy anecdotes don't often jibe with in-the-trenches experience.

A Personal Approach

As an itinerant software maker, I enjoy the inter-personal stuff of software teams. I also enjoy the process stuff, but mainly in environments where the process remains in a state of continuous improvement.

Improvement has little to do with output and a much more to do with making software that people like to use. My approach is born from trial and error. I hope my approach remains in continuous improvement. I hope it remains simple.

I try to understand the context of the product challenges. I like to think I have become less dogmatic and grown more pragmatic. I try to be sensitive to the social dynamics of the organization that has invited me in. Some truisms are:

• Recognize every product is different - There's no one-size-fits-all in producing software.
• Build capital by getting stuff done - There are few bigger chits than working software.

Assuming you have banked some capital with your benefactors:

• Protest & respectfully resist process ceremony - Process ceremony wastes everyone's time.
• Practice the things that make sense - If it has to make sense, it's always a fluid practice.

My approach is a state of mind, rather than a recipe.

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

Commoditized Agile

Commoditized Agile is a market-driven, largely failed, money-making machine. It is a prescriptive approach that metastasized from what began as the agile movement. Behind the guise of agile, ne'er-do-wells seized the chance to make a living lecturing people about The Best way to make software.

It's the product of opportunists and lazy organizations.

Lazy organizations, seeking the easy pills, threw money at a state of mind believing it would somehow morph into a prescriptive remedy for unhappy employees and crappy software.

• Opportunists packaged prescriptive service offerings and over-featured software products around a set of principles that were probably never intended to be prescriptive.
• Organizations seized on something new, so they had to throw money at the something new as proof they were doing it.

Commoditized Agile as troweled out by Conference Circuit Agilists, several of whom couldn't possibly have time to produce software, is mostly snake oil. Commoditized Agile, as represented by a host of crappy software products targeted at organizations who are "doing agile", is poorly conceived.

The lessons are simple. Find a personal approach that's an aggregation of trial and error. Co-opt the best ideas of others. Apply those ideas where they make sense. Deep-six any process with the scent of gratuitous ceremony. Remain skeptical of shiny new things. Get rid of tools that hinder your progress. Beware of charlatans selling snake oil.

"You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete."
- R. Buckminster Fuller

Postscript

I've been told in a tweet that this post is a bit cynical. So readers should know that I almost always enjoy the smart people I work with. In fact,

The joy I get from the people I work with invariably outweighs the profound organizational stupidity I encounter.