I started at ThoughtWorks a couple of weeks ago. Once upon a time, I would have been in India for immersion now – but that’s changed. I have mixed feelings about this – on the one hand, getting right into work is exciting for me and more profitable for all, but on the other, I don’t get the deeper experience and bonds of learning side-by-side with a ton of other Thoughtworkers. I did have a couple of lovely people in my orientation group, but it didn’t feel as absorbed in the culture as I would like.

That, by the way, is clearly going to be the most difficult part of itinerant consulting: making and keeping connections with the people I don’t work with every day. There are a ton of brilliant people at TW, a couple of them working with me now, and that’s part of the appeal of this company: getting to absorb some of these brilliant, different perspectives. I’ll be working on that, looking for people and projects that can help feed that sense of tribe.

The travel isn’t hard. Well, the travel might be hard, if I weren’t someone who really enjoys new places. And airports. I’m working in Boston for the next several weeks, and it’s a good city full of good people, far as I can tell. I’m home this weekend in Richmond feeling a bit homesick for Boston (Richmond can’t handle snow and is getting a lot; Boston is highly competent at snow). The travel’s fun: new food, new vistas, new people, tiny towels. I like it all.

Working on a project also feels like jumping into the other awesome thing about working with ThoughtWorks: changing the world. We’re totally doing it.

How much do people, on average, think about their communication style? Over time, I’ve interacted with a lot of different personality and style assessments, and it’s fairly common for the people I know to have some assessment result they use to describe themselves – whether that’s MBTI, Personalysis, DiSc, or whatever they’ve experienced. Horoscopes, even (though those have nothing to do with your actual responses to questions or situations, they can color your understanding of self, right?).
[Read more →]

I’m keen on Kanban 101. It does a nice job of explaining the concept of flow as it applies to lean thinking. This quote is particularly good: 

To achieve efficiency, minimize disruptions and distractions. Work should enter the development process and proceed through it smoothly and continuously.

It’s also applicable to work that isn’t using kanban; lean concepts are relevant to anyone. No disruptions and smooth, continuous work totally apply within agile teams’ iterations, for instance, or anyone’s tasks.

Speaking of anyone’s tasks: I finally found a non-irritating-to-others tomato timer online (there are a few, actually, but this one has nice typography). Not that I’m consistently using the pomodoro technique – so much of my current job description amounts to basically “be available for interruptions and immediate problem-solving” aka squashing tomatoes – but when I do, the timer on my screen allows me to keep focus on screen (vs. objects around me). A physical timer would be handier for off-screen tasks.

I’ve been reading Birth of the Chaordic Age for a month or two – it’s my breakfast table book, which means it gets read for about 15 minutes a day; a fast and focused reader could down it in a few days. Neat stuff. Lots of interesting commentary on work and human interaction – none of that’s particularly new, but I like hearing it nonetheless. I also just plain like Hock. I would hang out on a tractor with him.

Today, though, I got to the bit about the creation of BASE 1 (the original BankAmericard authorization system). Wow. You know as you practice it that agile work uses some pretty obvious principles of human interaction and getting work done, right? But it’s still pretty fantastic to read about NBI (later VISA*) having a task board and the equivalent of daily standups in… 1970? 1971? Right around the time the term ‘waterfall‘ came into use to describe software creation. By the way, while it’s often cited that ‘waterfall’ was coined to describe a broken process, that’s only half true; the Winston Royce article does describe a broken process, but he doesn’t recommend changing the waterfall so much as creating little offshoots. I think this telling of history better supports my point, though, so I may be biased. My point? Like many people after (and probably many before – my parents both confirm that many military organizations use the people coordination & visibility stuff that people have come to associate with agility), Hock and his team did something pretty obvious that was also revolutionary.

It’s a good story. I may write more reflecting on the philosophy he espouses later, too – but in the meantime, the history fascinates me.

* Random extra factoid: VISA is a backronym, starting just as the word and later being labeled (recursively) Visa International Something Anothersomething.

This post’s title is a direct quote from a member of my team, talking about his role as risk-identifier, gadfly, pessimist and occasional nay-sayer.

I recall many a project-management-of-people class touching on the idea of pessimist as a useful team role, to the point of designating someone to pick apart all the reasons a solution might not work. I assume there’s some organizational behavior research behind this recurring idea, too – there’s almost always some form of psychology at the heart of any simplified management truism.

That notion isn’t unique to projects or even “management”; deBono’s thinking hats thing, for instance, includes a hat of “critical judgment”, which I like to think of as the hat of angst and risk aversion.

In any case. I don’t believe optimism is foolish. It can be, but it’s just as likely to be a result of experience and trust. You get through one cluster of a problem, and you begin to see paths through others. It’s not a failure to see problems so much as a belief that they’ll get solved.

Where I see pessimism being truly helpful, though, is not in the popular domain of risk (sure, that’s handy, but you can get to risks from a lot of different directions, and getting too critical or analytical can paralyze a group). It’s the pessimist’s willingness to be an iconoclast, to stand against something. Because. Standing against is still taking a stand. Even a wobbling uh, guys, I don’t think this is going to work stance is a way of injecting dissent into a group conversation. That’s the whole idea everyone gets from the Asch experiment, right? One black sheep, and suddenly it turns out sheep are like My Little Pony and come in all colors.

Dissent, used well, is how we get a whole picture as a team. That is – sometimes groups don’t even notice they’re falling into consensus too easily. It takes a pessimist – someone brave or smart enough not to fear conflict – to throw up the 40 point card in planning poker and point out how much the group doesn’t understand yet. Just one voice of dissent from an apparent agreement, and it turns out the issue is much more complex, and is actually being understood in several different ways. That diversity of thought contributes to teams outperforming individuals, and it’s often the grumpy pessimist who kicks that off.

In case any of the various people who’ve mentioned Google’s Go language to me recently are reading, there are already comparisons afoot. Today, we see Go stacked up against stackless Python.

Short story: Python’s faster.

I just got home from NFJS in Reston. The tech lead on my team suggested it, and I thought They have Dave Hussman? Sweet. and was in. Going with a Java dude to a post-Java event is a good time. I wonder how long before he’s a post-Java dude. Probably not long at all.

So. About me. I got some useful perspectives – especially on team and project start-up, a thing I love – both from Hussman and from Stu Halloway (who threatened to cry more than once as he got started; don’t mess with that man). I learned Scrum in a non-software context. It totally works that way. With software teams, though, I’m increasingly convinced that the elements of craft contained in XP and just plain good development practices also need to be encoded in your agile startup. Their collective commonsense list of development and architecture-oriented points is totally going in my startup toolkit. Thanks, guys.

I’m not at the point Hussman seems to have arrived at, where any selection of agile practices is good. I mean, yes, some agile practices (the daily coordination meeting, for instance) are good in almost any context; others, though, make more sense within a whole. Scrum works as a whole. Teams can change what they do after they learn Scrum, but for many corporate folk, the shift to agility is so profound that a codified set of practices is needed at first. Then mindsets start to shift, and they either end up in “Scrum, but” (that is, they fall back into old habits) or “Scrum, and” (they discover additional practices that fit their particular work). Start with “Scrum, but”, though, and you may never change minds. You’ll get results. Some, at least. “Scrum, but” is okay. I didn’t join this party for okay, though. I thought we came here to rock.

Anyhow. Yeah, Hussman briefly argued that the notion of “Scrum, but” essentially alienates practitioners. Too liberally applied (eg to “Scrum, and” shops), maybe. Applied in a jerk-like fashion, When Scrum Practitioners Attack style, sure. I’d still argue that people want to be told what is and isn’t big-a Agile or Scrum. Because they want these better ways of working, and they want to know if they’re getting there. Sure, what matters most is that we deliver and our lives get better in the process. But it’s nice to know you’re headed the right direction.

As much as I just talked about the agile track, the single most exciting thing was Brian Sletten’s series on the semantic web. Dude. That is some really simple stuff with some mind-bogglingly awesome potential. I rarely write code for the web these days (I suspect I couldn’t, without weeks and months of practice and retraining), but I use and create plenty of content. And as a user/creator/participant, I want everyone to get busy on this kickass semantic thing, like yesterday. Tomorrow morning, I expect related content to all be mapped together.

Alright. So it might be awhile. But it’s going to be pretty effing awesome when it gets here.

Heh. I bet agile adoption would move faster with a few more murderous atrocities. *

hark, a vagrant on lenin

* I kid! I promise. But there are some interesting parallels in the ways companies adopt agile approaches and the use of communism as a revolutionary concept. Hey, workers! I command you to self-organize! Yeah. Totally effective.

I had an interesting conversation about conflict on teams last week that made we want to collect and share some stuff about conflict & how it plays out on teams.

I’m a bit in love with this manifesto…

We invite diversity into our community not because it is politically correct but because diverse viewpoints are demanded by the manifold mysteries of great things.
We embrace ambiguity not because we are confused or indecisive but because we understand the inadequacy of our concepts to embrace the vastness of great things.
We welcome creative conflict not because we are angry or hostile but because conflict is required to correct our biases and prejudices about the nature of great things.
We practice honesty not only because we owe it to one another but because to lie about what we have seen would be to betray the truth of great things.
We experience humility not because we have fought and lost but because humility is the only lens through which great things can be seen – and once we have seen them, humility is the only posture possible.
The Courage to Teach, Parker Palmer

Conflict is required to correct our biases and prejudices about the nature of great things. Wow. That’s a really important thing to think about. I recall reading something Alistair Cockburn said about teams needing conflict – it was less beautiful than that quote above, but the same idea. Despite our need for it, conflict is scary and socially unacceptable (well, depending on your society). But. Agile teams are, like the old MTV Real World (back when the people were actually interesting without manufactured melodrama), a place where people start getting real. So conflict is more likely to get expressed.

Knowing you’re going to have conflict, the team needs a way to talk about it – sometimes, the team needs permission to talk about it. It helps to bring this up as the team forms, which is conveniently an awesome time to practice, since learning to work together tends to bring out clashes of people and perspective.

You need, as a team, to essentially come to agreement that conflict can be useful or not: “I disagree with that… here’s why” is a natural part of collaboration, while an angry “everything about you infuriates me” vibe – while true, and an allowable feeling – sucks. So find a way to talk about degree of feeling/passion, and what’s safe to express within the team.

I think it’s easier to talk about conflict with a vocabulary model for the team. A team might choose their own, or use what others have created.

Plenty of experts and amateurs have developed models or theories to talk about types of and approaches to conflict. Here are a handful:

• Relationship-Data-Interest-Structure-Value
• Dependence-Style-Background-Leadership-Personality (The semi-inclusion of “gender” in “background” annoys my inner feminist – I think there’s a fine argument for learned gender differences as a form of background, but why call it out separate from any other quality?)
• The popular Thomas-Kilmann Accommodating-Competing-Avoiding-Compromising-Collaborating model (which is more about ways of handling conflict than types of it)

Just getting comfortable labeling and talking about conflict seems to help teams work in it. I’ll write more later on some of the resources I’ve seen for deciding what to do with a conflict.

Some less-organized thoughts on conflict…
While I was looking for whatever Alistair Cockburn said about conflict, I wandered into this blog post on conflict-handling dysfunctions; it’s not exactly what I’m talking about, but it’s a nice little survey of quotes.

If you’re near Richmond, my friend Lyssa is doing an evening introduction to a conflict model I like: 9/15/09, info via Agile Richmond. She also presented it at Agile 2009 – and is doing it again for Agile Development Practices. So many ways to acquire this information.

There’s a bit in this chapter of Save the World & Still be Home for Dinner [Click on the pdf download link to read the full chapter - the teaser's not what I want to talk about.] that should be required reading for everyone I’ve ever worked with.

The answer to our stress is supposed to be something called work-life balance. This is achieved, we are told, through time management. But it’s an illusion. We try to balance work, family, and play on a preset schedule. The problem is, nothing important ever happens on schedule. Great opportunities and painful crises usually show up inconveniently.

Indeed. And particularly fun to see this coming from a dude who used to train for Covey (the “7 Habits of Disempowered Highly Effective People” dude), whose life’s work was all about managing time and tasks more “efficiently”. If you can’t tell from the snark, I dislike the proscriptive diet Whole New Way of Living approach. I prefer to think of value and values, which are unique to each person – and that’s what Marre is now doing. Obviously he’s right, now that he agrees with me!

I know a fair number of people for whom every task seems equally important as the next, and are caught up in an intense feeling of busy-ness that leaves them with a looming sense of something undone all the time. This, I think, is that “illusion of urgency”. Marre goes on to attribute this sense of everything as urgent, every project or activity having the same priority, as a result of the constant connection many of us have to information and work. I’m not sure that’s entirely true – that connection is just a thing; our relationship to it is what throws us off balance.

There’s an old-school management psych term: “locus of control” that I think is in play here. Feeling caught up in this Grid thing seems to me like a form of externality. I like my ability to plug into various types of work when the urge strikes, and not on a particularly fixed schedule [This is sometimes at odds with the sort of work I do for pay, since it needs people to interact directly & therefore to agree on when and how to do so.], but then, my locus of control is so internal it’s annoying.

I’m still affected by the MUST DO EVERYTHING NOW OMG HOW DO WE MANAGE OUR TIME sense of urgency that pervades work & communication, though – and that’s where value comes in. Rather than responding to the OMG of the moment, I try to think in terms of what I value, or if that’s irrelevant, what is of greatest value to whomever (the latter is a newer addition to my thinking, thanks to a few years of Agile and exposure to Lean). Agile work, I think, ensures that everyone on a team has to think beyond OMG and into what’s important.

this was cross-posted to my LJ/FB, since it’s relevant to several audiences.