Agile Team Etiquette – say YES!

December 29th, 2011

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!

State Machines are Awesome

December 10th, 2011

If you’re writing code that makes calls that can block or throw, then you should be using State Machines.  Building enterprise applications without State Machines is like building cathedrals without arches.

State Machines provide the paradigm shift needed to separate out exception handling logic from strictly algorithmic code.  They let you run all the code that just works on one thread, while delegating to worker threads the code that might fail, or block indefinitely waiting for an external resource.

Inversion of Control containers provide mechanisms for achieving this separation, but the programming model they offer is so primitive – signals and handlers.  A state machine container fills the gap by grouping event handlers around an entity state model, allowing the design of work-flows that capture the desired progression of entities from initial to completed state.

At my shop, we’ve got our own Hierarchical State Machine framework, which is based on the work done by Dr. Miro Samek’s QuantumLeaps framework – see http://www.state-machine.com/

Truth and Faith

August 8th, 2011

There is a misconception, that faith is simply the act of believing something.  But that’s not right.  To have faith is to believe something that is true!  To believe something that is not true may feel like faith, subjectively, to the believer, but it’s not.  To believe a lie is self-delusion.  Proper faith bridges the gap between facts that can be known absolutely, and facts that must be derived.

Faith in Christ Jesus is a great example.  The historical evidence for Jesus’ resurrection is good.  The evidence is also good that surviving testimonies about his life and sayings are reliable.  The eschatology concerning the trinity of Creator, Redeemer and Council is philosophically sound, and the likelihood that Jesus is that redeemer is very high.  But it is difficult to believe that Jesus was physically raised from the dead, that he lives now, and that we can relate personally to the creator of the universe through his mediation.   It’s hard to believe, but great and critical minds have challenged the evidence time and again through the ages, and the evidence has stood.  And so we choose to believe what is true, but difficult to believe.  We choose to have faith.

It’s More Like Sailing

February 12th, 2010

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.

Enter the Hero

February 11th, 2010

It feels good to be in control!  Oh, to be right!

Yes, you’re all part of a team – my team.  In fact, you are all extensions of my massive ego.  The harder and faster I work, the more you might marvel at the complexity of my creations!  Look here, I’ve created a framework by which you can make some modest contribution.  Look again, even the API is profoundly complex.  But don’t worry, I’ve created some base classes that handle most of the complexity – you should look at one before you go to sleep so that you might dream of my greatness!  But really, you can just express your puny business logic in XML – I’ve created code generators that can spew code so incomprehensible that even I’m astounded!

I’m actually too busy to listen to you right now, but I can explain some of my more fabulous constructs again if you have some time.  I mean, I could listen to you, theoretically, but what would be the point?  I can already understand everything you do, and I’m frankly a little disgusted by your simplicity.  Better that you should listen to me, so that you can tell your friends how bafflingly brilliant I am.

No time for functional slices, or design documents.  The place is here – the time is now!  Tap tap tap tap.  If you don’t have anything to do, maybe you could write some unit tests for my code.  Did I mention that I got here before you did this morning, and I’ll be going home late.  And this weekend, I’ll be rewriting everything you’ve done so far.  Hey, you don’t have to thank me, any more than you have to thank superman.  I mean, it just goes without saying.

Come on people, lets keep our focus.  Sure we’re behind schedule, but the idiots who came up with the specifications had no idea how complex the solution could be, so of course they didn’t plan for it.  I’ve been working 80 hour weeks all along, so I’m pretty sure it’s not my fault.  In fact, I’m so wired that I can hardly see straight – I don’t even know what I’m typing anymore.  Hero?  Well shucks, maybe I am.

Know Thine Self

February 11th, 2010

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?

Architects Despair

February 8th, 2010

The project has gone so out of process that I cannot even guess when the trunk might be deployable again.  I continue my attempts to stabilize the production branch, to provide some small value in this way.  The value that I’d hoped to bring – a rational and deliberate approach to code production, has not materialized except briefly and modestly.  The deadlines that we’re chasing are arbitrary and insubstantial, but they support an abandonment of reason in favor of frantic action.  I’ve lost.

Cold Comfort

February 8th, 2010

One of the eventual benefits of relentless self analysis is that one learns to see through one’s own bullshit.  It’s cold comfort for the most part.  Bullshit is mostly there to support our irrational behaviors, for which we hold a natural and unaccountable fondness.

Group Intelligence

February 6th, 2010

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.

What is an Agile Meme

February 6th, 2010

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.