I think much has been written about the classic programmer profile: INTJ: Introvert, iNtuitive, Thinking, Judging. The poster-child programmer is a loan wolf who uses his analytical skills in a controlled environment to produce excellent software.
From an agile perspective, introverts are, at least in theory, less likely to be amenable to or effective at pairing.I'm not sure this is a particularly apt conclusion, but for now, I'll shelve that thought.
This morning, I turned my thoughts to the last dimension, the so-called "Lifestyle" dimension. That is, Judging vs. Perceiving. From wikipedia:
People with a preference for Judging prefer matters to be decided; to start tasks in good time, well ahead of a deadline; to have clear plans that they prefer not to be distracted from; and they can sometimes seem inflexible in this regard. Those whose preference is Perceiving are happier to leave matters open, for further input; they may want to leave finishing a task until close to the deadline, and be energised by a late rush of information and ideas; and they are readier to change plans if new information comes along. They may sometimes seem
too flexible for their Judging peers.
So: Judging = Waterfall; Perceiving = Agile.
But wait. Isn't Agile just a shorter planning cycle to deal with? "matters to be decided" at the beginning of the iteration; "clear plans", "no distraction". These seem part and parcel of iteration-based development - scrum, for example.
It seems to me that "lean" approaches like not having iterations; just-in-time analysis; polyskilled, adaptable "resources" (aka people) are a "judging" person's worst nightmare. These judgers have already adapted to a shorter planning horizon; now you're asking for a transition from short planning horizon to flexibility - beyond their comfort level.
The challenge is to introduce lean approaches with an understanding of each participant's comfort level.
3 comments:
> The poster-child programmer is a loan wolf
Is that the mammalian equivalent of a loan shark? ;-)
I'm an ENTJ, and I've been using timeboxed iterations and implementing by feature for over 20 years. The reason I do, is *because* I can plan for a few weeks at a time. Trying to predict the end of a long project makes me nuts, because too much can happen.
Don't assume the "J" people like waterfall and the "P" people like agile. I've met a number of "P" people who hated the timeboxes because they thought it stifled their creativity. They hated knowing what was already in an iteration. They hated the discipline of agile.
How you do development (or testing or whatever) is colored by your preferences, but your preferences are not your destiny.
Johanna,
Thanks for the response.
I guess I wasn't clear enough... my "But wait" paragraph was meant to counter my tongue-in-cheek summary (J=Waterfall). "But Wait" was meant to convey precisely what you're saying in your summary of how P's and J's deal with timeboxes.
My reflection in this post was based on the discomfort I have witnessed in discussions around the prospect of lean software development - around approaches like eliminating iterations. It's not about shortening the timebox, it's about eliminating it. I probably would have done better to summarize what I see as the distinctions between agile and lean before delving into the MBTI perspective.
And, yes, I absolutely agree that preferences are not your destiny. But they can be useful tools in diagnosing discomfort around approaches and in addressing team dynamics.
Post a Comment