Agile Memes

When a teammate drops by with a request – say YES!  Members of an agile team help each other relentlessly! What’s more, the alternatives to saying “yes” are anathema to an agile team:  Think about it, or just say NO.

Think about it?

You could choose to think deeply about whether the request is consistent with your current job description.  The challenge with this approach is that while you’re thinking about the relative contours of you and your colleague’s job descriptions, you’ve stopped thinking about your job.  If your requestor then attempts to impact the calculus you’re performing, then neither of you is thinking about your job.  Over time, a culture that doesn’t apprehend the toxicity of this type of reasoning will come up with mechanisms to short-circuit the decision, so that all interactions occur through well-defined channels.  At this point, your team will no longer be agile.

Just say No?

Alternately, you could simply insist that all requests come through a controlled channel – a ticketing application, for example.  In this way, the request will benefit from the prioritization, categorization and tracking mechanisms provided by the application.  The challenge with this approach is that it forces casual ad hoc requests through the same channel as legitimate work items.  You now have to understand the request once just to get it into the system with the right priority, categories, tags and comments, and then again when you eventually address it.  Addressing this dilemma will inevitably lead to a more ridged structure and less spontaneous communication – collaboration will be hampered by boarder disputes.  Your team will no longer be agile.

Can I really just say YES?

Yes!  When your teammate approaches you with a request, there is an implicit question being asked: “am I worth your time?” YES!

More pointedly, are you willing to stop what you’re doing and instead apply yourself to understanding your teammate’s request?  YES!

Agile productivity can be difficult to quantify.  The most valuable players may spend much of their time collaborating and helping others, and these types of contribution are very difficult to measure. But we all know that!  We know that managing an agile team requires faith in the human spirit and the nurturing of an invisible sum that is greater than its parts.  But we also know that agile teams are uniquely capable of achieving that allusive hyper-productivity, and do we want that?  YES!

It might help to think of your development team as a sail boat.  But you’re not the captain of a crew, you are the crew, and your team is the boat.  Got it?  You have a mainsail and jib, rudder, keel and various blocks and lines.  And you’re trying to get from point A to point B.

This is a powerful analogy, partly because it’s visceral and exciting, but mainly because it puts the indirectness of the process up front.  A completely naive sailor might use his rudder to point in the direction he wants to go, and if that doesn’t work he might start pulling in his sheets (ropes) until his sails fill.  This might work if the winds are favorable, or the boat might jibe unexpectedly, putting our rookie in deep water with a head wound.

And that’s how it is with a development team.  Sure, you have to know where you’re going, but that’s just the beginning. You have to know what your developers are interested in (wind directions), and how capable they are (wind speed), and how experienced (water depth?)  These things will determine how you might get to point B (a product or feature.)

You might need to travel perpendicular to your goal for a while to get to where the wind is more favorable (training or paying off technical debt.) If you notice that your sails are starting to luff, you might pull in your sheets a bit more to tighten your sails (encourage your team to stay focused and work harder), or you might need to back off your upwind tack (move toward a solution that is less than what you’re looking for, but more in line with your teams interests and capabilities.)

Thinking in these terms will help you to remember that speed and direction are distinct, and neither are completely under your control.

Thoughts are behavior, and all behavior is reactive.  The point isn’t to shatter the illusion of free will and self determination.  The ancient memes that proxy for our inner, experiential world are some of humanities greatest treasures!  But if one admits that there is an underlying mechanism – that our perceived souls are built upon a deeper, imperceptible strata, then the possibility of profound and deliberate change can emerge.

So there’s a paradox – by accepting the deterministic nature of human behavior, one can learn to appear less so.  Of course, the memes that guide us in changing our deterministic nature are themselves deterministic.  But if there is no end to the recursion – if we can have countless orders of memes about memes, then our effective self-models can be arbitrarily subtle.  And where is the determinism in a system that’s too complex to ever rule out surprises?

The most important thing to understand about a group intelligence is that it is distinct from the individual intelligences from which it is composed.  This can be demonstrated using a text based Turing test that masks response rates.  Simply have the group members provide words (and punctuation) in turn (no pun intended.)

With practice, a group can present a consistent and coherent persona with all the characteristics of a distinct identity. This is not so different than what happens in real situations, where group members interleave (rather than exchange) words and sentences.  Insight is gained by seeing these interactions as meme building within the group intelligence, and not just as individual exchanges.

A development team’s process can be seen as a group intelligence, and the team should take care that it is both Rational and Impartial.

A group’s intelligence is rational if its behavior is consistent with its utterances, and appropriate to its environment. Rational responses are comforting and endearing, and allow constituents to navigate adverse enforcers effectively.  We like rational responses, and when we can’t have our way, we like to know “why?”.

A group’s intelligence is impartial if responses are evaluated based on the circumstances, and not on the constituent personalities involved.  For example, an impartial group intelligence will not react adversely when a junior member corrects a senior member during a meeting.

When a group takes care to build out its memes across a rational and impartial intelligence, its constituents can enjoy the benefits of rational and impartial interactions.  This in turn allows for a more and more efficient building out of agile memes.

A group intelligence’s level of self-awareness is defined by the presence of memes representing the nature of group intelligence.  If such memes are agile, then the host intelligence can learn and grow effectively.  If these memes are not agile, then changes in a single constituent’s perspective may prove disruptive, and be met with adverse responses.

A meme is a proxy for an idea – a socializable form of a possibly deeper understanding.  Memes connect ideas and understandings across the constituents of a social matrix.  The common memes can smooth over significant differences in the constituent’s internal understandings.

A working distributed meme graph implements a coherent domain model, and allows for the coordination of specialized individual efforts toward a group’s common goals!

A meme can be categorized by the nature of the understandings that back it.  A meme contains Insight if the understandings lead naturally to rational and correct behavior.  A meme has Fidelity if the understandings are consistent across constituents.  A meme is agile to the extent that it exhibits Insight and Fidelity.