Myers-Briggs "Lifestyle" dimension meets Agile & Lean

I was thinking this morning about how Myers Briggs Type Indicators (MBTI) play into our receptiveness and ability to thrive in agile environments and further, into lean approaches to software development.

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.

10 Attributes of Well-Run Meetings

I love well-run meetings. The key here - well-run. What are the qualities of a well-run meeting?

1) Facilitated. Note the distinction between this property and "led" or "managed" or "controlled". The person running the meeting has good skills at eliciting input, tracking progress and action items, and keeping everyone engaged.

2) Non-laptop/PDA focused. I can't recount how many meetings I've attended where one or, usually more, attendees have laptops/PDA's open and are focused somewhere else. Yes, I understand multitasking and the demands on our time, and the usefulness of getting things done while sitting in a meeting. The cause and effect here is not always clear, but I submit that if the meeting was well-run, the attendees would be riveted to the discussion topic to the point where they'd forget they were carrying a PDA.

3) Accomplishment-bound instead of time-bound. Meetings fill the time they are allotted. If you have 26 minutes worth of productive discussion, don't keep the meeting going to fill the whole hour you reserved. Keep focused, accomplish your objective, and release folks early to go do their email.

4) Speaking of objectives.... HAVE ONE! In agile, we talk about having "acceptance criteria" for story completion. We should adopt the same approach to meeting management. An agenda would be nice too - for more formal meetings - but I don't think it's always necessary.

5) Take issues offline. This is easy for an effective facilitator to drive, but is not done nearly enough.

6) Determine if a meeting is the right approach to accomplishing your objective. I was a participant in a weekly meeting for a couple of months for which the only agenda item was to go through an action item list and report status. I stopped going. So did many others. Fortunately, the organizer(s) got the message and canceled it. We can easily update a wiki as needed to update status. If folks have questions, walk over to the other person's office and talk in person.

7) Find a good time for the meeting. I know that cross-oceanic teams sometimes necessitate bizarre meeting times (unfortunately, early morning for me - ugh). If you have to have an 8am (or 7am or....) meeting, at least bring bagels and coffee or something. And don't schedule lame meetings for that timeframe, because your attendance will suffer even more for the time schedule (in addition to the lameness factor). If I'm an attendee to that early morning meeting, and the alarm goes off, I have a choice.... hit the snooze, or wake up excited to attend the meeting. Unfortunately, my snooze-button is well-warn.

8) Cancel if the right people can't attend. Use those "optional" and "required" tags on your meeting invitations and mean it! If someone is required, and they reject your invitation, find out why and reschedule or address the issue.

9) Don't call all-day meetings unless you have a plan for how to spend the time.

10) Don't forget the remote attendees. I find this difficult; the conference phone is dialed to the conference line and the remote attendees are there, but often the facilitator forgets them, or doesn't include them in the discussion as often as possible. Also - make the communication bandwidth as rich as possible. Use Netmeeting or other conference alternatives to share the desktop with remote participants, and set up a webcam if you can. The more you can do to make the remote attendees feel a part of the meeting, the more valuable participation you'll gain from their attendance.

I could go on. What attributes do you find to be important in meeting effectiveness and efficiency?

Thoughtworks is hiring

I work for Thoughtworks, a global IT consulting firm with offices in six countries (US, Canada, UK, Australia, India, China). We hire very good people to work on interesting/difficult problems.

We're hiring.

Most of our development is in Java, Ruby, and C# (with Ruby becoming more and more a staple of our most interesting gigs). We're looking for developers, testers, project managers, client principals, and probably sales folks.

Pluses of Thoughtworks:
- You'll probably not find a more competent/smart group of people in any other consulting company.
- We deliver working software using Agile software development approaches (pairing, TDD, etc.)
- Lots of travel (if you're single and want to see the world, we encourage travel to different countries)
- Amazing level of transparency in corporate activities and a flat organization.

Minuses:
- Lots of travel

If you would like more information, see www.thoughtworks.com, or respond in this blog with your email address and I will be happy to provide more insight.

For Dummies

I've always despised the "For Dummies" book series. It's not the idea... the few I've browsed in the bookstore (with suitable disguise in place) seem to be well-written and humorous. It's the damn title. If I buy the "Sewing for Dummies" book, and interpret language literally, the purchase has nothing to do with my novice status as a seamstress (seamster?) but conveys that I'm actually a dummy.

I must admit I bought one once - but it was appropriate: "Golf for Dummies". My golf game is worthy of the term (nothwithstanding my strict grammatical interpretation argument above).

Saw an interesting title on the shelf at the library today: "Beginning Java for Dummies". This begged the question: where is the "Advanced Java for Dummies" book? And does one exist? Can you get to the advanced tier of "Java developer" and be a dummy? Perhaps the library just doesn't carry it. It was, however, a college library (OK, not exactly a top-tier university).

I checked Amazon. No, there's no "Advanaced Java for Dummies". But there is a POJFD book (OK... take off on POJO.... plain old "Java for Dummies"). There's also "Java Programming for Dummies". Not sure what the difference is. If you're not programming with Java, what exactly are you doing with it? Hmmm.... Perhaps the "Java for Dummies" book describes how to order at Starbucks.

Aside=> My favorite Starbucks order: Alok's: "double tall, two splenda, breve cappacino".... I used to pick up coffee for him and the barista would always eye me and say... "Ah, for Alok?". As if to make sure that I wasn't actually ordering Alok's "usual" for myself. Fortunately, at the time, I had no clue what I was ordering.... it could have come with pork rinds as a garnish for all I knew.

A search for the terms java and dummies on Amazon yielded 412 results. There were only 14 results for ruby and dummies. Hmmm.... guess I figured out where the smart people are hangin' out. To be fair though, not all responses were relevant to the specific technology. The Ruby results included a few "dummies" books whose authors included someone with the name "Ruby". And I'm pretty sure "Ballet for Dummies" has nothing to do with Ruby. Not quite sure how that got into the mix. Didn't have the time to peruse the 412 Java results to weed out the chafe.

Found "Management for Dummies"... hmmm, maybe there is an argument for the validity of this series. (Thinking about managers from previous companies of course.... really.... wonder if any of them are still on my Christmas list?)

Shoemaker's shoemaker

Sometimes I feel like a shoemaker who walks around life in bare feet. I'm a software development professional... consultant even. I help companies create advanced software.

My colleagues are hot on IPods, Macs, PS2, XBox, fancy cell phones.

What's wrong with CD's? I've got a CD player... a bunch of CD's and I can cycle through them. I know, the IPod and other MP3 players allow you to consolidate. OK, good. I have sparse financial resources (4 kids!) and have to wisely allocate those resources. Do I need an IPod? Focus on the word "need". Do I really NEED it? Yes... I'd like one. (feel free to post a response and I'll give you my mailing address for your to send me a check.... or maybe I'll even figure out how to do PayPal, or whatever the cool version of it is now)

Macs.... I really don't understand this one. OK, it makes some cool things easier.... like creating movies, music, art, etc. I'm a left-brained guy. This is not as important to me. If you're a computer guy complaining to your management/IT department that you can't be effective with a PC.... but if they were to get you a MAC, boy, you'd be smokin'.... check your motivation. I mean, really... as an IT professional.... you can't figure out how to make your Windows experience efficient? Be honest with yourself.... you're after the cool factor. You couldn't get the chearleader in school, so now you're trying to be the "football player" of cool technology. Give it a rest. If you want a Mac, buy one yourself. And stop your bitchin.

Gaming machines.... really. Sounds cool. Why don't you try LIVING life instead of experiencing it vicariously through the imagination of some geeks who create virtual worlds? Reminds me of a guy ... good friend actually.... who claimed he couldn't make our volleyball match because he had to sit at home and watch a Giants game. What's with that. Do you live life, or are you a spectator?

Do you really need to check your email via the phone? Really? Are you that important? Ask yourself ... as you thumb through your emails in mid-conversation with a colleague or employee of yours.... is this more important than human contact? I had a manager once who thumbed through his blackberry as we had a "one-on-one" at a Taco Bell of all places. As I was conveying my career goals and such, he was thumbing through the blackberry and mumbling... "uh huh". Please.

Lastly... this "connectedness technology" does not exist for you ... it's for me. If you expect me to answer my cell phone when you call, you have severely mistaken my motivation for obtaining said cell phone. You see... I bought it to make it easier for ME to connect to others.... not for YOU to find me at all hours of the day and night.

Dope a rope

So you're on a team using all of the agile techniques (please don't say methodology). You're pairing, using TDD, daily standups, etc. You have the maturity to understand (or you've been on the other end too many times) that micromanaging doesn't work, but you want to keep a close eye on one of your team members; the code she writes often ends up being less than healthy. In fact, it sometimes is beyond refactoring and needs to be rewritten. You'd rather she not spend a great deal of time going down ratholes. What do you do?

Rotate pairs often. This is a stealthy/healthy way to keep fresh eyes on the problem. It's the classic agile way of spreading the perspective around.

Dope a rope. This is a technique I use sometimes to be welcomed into another developer's sandbox. "Dope"... means I express ignorance (maybe too strong a word) about what he's doing and ask 3rd grader type questions. (Easy for me now - as I have no developer credentials on my current project and am acting as a project manager). I ask for explanations that lead the developer to "throw me a rope" and pull me into the code to show me.

What is the result? The developer sees that what he's doing matters (because I'm paying attention) and feels confidence (after all - he knows more than me). I get an opening to subtley convey suggestions for improvement. And I usually learn something.

Cram First

CRAM First

CRAM is an acronym that represents a model for dealing with workplace performance. I first heard it in business school – in my Managing People and Organizations class. It resonated with me at the time and has endured the test of time: 7 years beyond graduation. How much do you remember that long after school finishes?

The natural reaction to underperformance of a team member is to blame it on motivation. “He’s lazy” or “She’s just not applying herself.” While this reaction may be accurate, there may be other more substantial issues that render the motivation issue irrelevant. This model can help to “peel the onion” to find more basic issues related to performance.

To the point: C = Constraints; R = Resources; A = Aptitude; M = Motivation. Think of these as cascading (or – like Maslow’s hierarchy of needs – a pyramid).



Constraints: I have been divorced twice. The first time I got separated, I was working at IBM on mainframe operating system development. I was on an elite team doing cutting edge development – writing software that translates service-level-agreement objectives into algorithms that adjust resource allocation within the system to achieve performance objectives. It was complex work and demanded a great deal of concentration.

When my personal life took a dive, I would – literally – sit in front of the computer screen and stare at it. I felt like a zombie. Though I knew that I was falling behind, I didn’t want to – no, that’s not right – I didn’t care about raising a flag to indicate that I was in trouble. I’m sure I experienced aspects of clinical depression. I finally spoke to my manager. He moved me onto a less complex part of the project, where I flourished. I was fortunate that my prior performance provided evidence of my capability, so my manager was able to understand the impact of my personal issues.
So ask me – was I motivated? I don’t know. I didn’t care. My issues were more foundational – my motivation was irrelevant. Ask a homeless person if they are working on self-actualization.

Resources: In this day and age, why doesn’t every developer have a big flat-screen monitor on which to work? Why don’t they have 2-gig systems (or more) with dual-core multiprocessors to speed their work? Understand that the more lag time there is between tasks, the more start/stop energy that gets expended by thrashing. If my build takes 4 minutes, and I start looking at cnn.com in the meantime, I’m losing my concentration. Nobody can be expected to maintain concentration over this time.

I run meetings where I need a projector. Management decides to purchase one projector to share among 50 people – to save money. Consider that I’m costing you $150 an hour… so every 10 minutes I spend hunting down, or reserving the projector costs you $25. Moreover, I’m losing concentration on the tasks I could have been performing.

Administrative assistants provide incredible leverage for productivity. I spent an hour recently reserving rooms for a recurring daily meeting using a terrible Lotus Notes conference room scheduling implementation. You can hire great administrative assistants to do this at a much lower cost. Think of me (and other high-tech workers) as expensive pieces of machinery in your manufacturing plant. To optimize your profit, you need to keep your expensive pieces of machinery at optimum capacity. Don’t eschew paying $50 an hour for a maintenance person who keeps a $1,000 per hour piece of machinery humming.

Aptitude: I had a good friend/colleague at IBM once who was extremely bright. He had (presumably still has) a quick wit, a great attitude, and could solve some complex problems with ease. He had a master’s degree in Mathematics. Unfortunately, he was working as a programmer. He wasn’t a great programmer. He was eventually managed out of the company. To this day, it bothers me. I was his team leader, but I was young and had no leadership sense. I was timid. I wanted to get along – climb the IBM corporate ladder – become CEO someday. My friend was not a poor employee; his best skills were simply not being leveraged. He would have been an outstanding software performance analyst. To this day, when faced with seemingly incompetent people, my experience tells me to look for where the aptitude lies. That person may not be shining in his current role, but may be brilliant in other areas. Let’s find the areas where we can all be brilliant.

Motivation: Some people are lazy, unmotivated – whatever. There are reams of books on motivating people – particularly in the sales arena. I’m sure some of these tactics work. But motivation is irrelevant when deeper issues exist. Don’t be lazy in managing these individuals. Figure out if there are more foundational issues to address before giving your next motivational speech. CRAM first; motivate later.

First Post

My first post. This blog is my foray into blogging on tech topics related to (in no particular order)

Software development
C#/.NET
Agile Software Development/Scrum/XP Programming
Software development career paths
Human Resource Management in the software industry
Project management/Iteration Management/Scrum Mastery
People Management
Performance Measurement/Balanced Scorecard/Metrics