This is part of why I love estimating with these numbers rather than any old whole numbers. It’s not just that we simplify argument & agreement, but there is something nifty and natural and just plain elegant about using this sequence.

It’s lovely to have something in our processes that is both useful and beautiful.

We talk a fair amount about “servant leadership” to project and functional managers making the transition into agile roles. But this isn’t really a new or different kind of leadership, just a new way of interpreting where the leader’s power comes from. Leaders – even ones radically changing the world or heading troops into battle – derive their power from people’s willingness to follow them. [This doesn't remove the usefulness of things like management or positional authority. If you've ever gotten lost with a group of friends, you've experienced how easy it is to just follow someone because they're in front of you.]

Leaders don’t need an immense, soaring vision. I’d argue that too detailed a soaring vision can actually get in the way of leadership’s main task: this co-active power of finding the best, most awesome things in a person or team. Leadership, too, need not reside only in the people with positional authority. It’s better when every member of a team can call forth their own, others’ and the group’s best potential.

Encouraging that leadership among team members, by the way, is a big part of the raison-d’etre for the coach, PM, Scrum Master, etc. – anyone who takes on the role of holding up the mirror to the team. The first (and frankly, constant – I have to redo this for myself often) step is recognizing that your own personal leadership comes largely from being a decent person who keeps growing.

The second step is to read Esther’s blog. *

* I kid, and yet I don’t. Part of being a decent, inspiring person is being inspired and growing yourself.

People who rescue wild animals probably feel a bit like this. You like them, but ultimately the point is to send them back out on their own. The whole effort is impermanent by design. I’d like to install little tags on all these folk (painlessly, of course, and with their consent) so I can check in on everyone. Flying ok? Still favoring that frail left wing? Check it out! They met mates and are laying new generations of birdlets! [Er... maybe I'm taking the metaphor a bit far.]

Unlike wild animals, though, the best outcome from consulting and training is that we grow our future peers. I hope to see these client folk – especially the PM’s, if y’all are reading – at conferences and such in the future. Or writing books; whatever, I just want them to succeed and give back later.

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.

An unintended consequence of this education is that I’ve assumed all this time that people are going to think in different, possibly patterned, ways, and part of my role as a fellow person is to try to bridge the gap between you and me. Not everyone believes this. There are many people who haven’t really thought about communication gaps, of course. There are also many who believe, consciously or otherwise, that it’s Everyone Else’s responsibility to figure out how to communicate with them. Some of these people are just jerks. Others think they’ve found the One True Style of communicating, and yet others think their preferences, good or bad, are fixed and immutable.

The intersection of personality types and people’s self-concept is particularly fun for interaction with those latter folk. It tends to show up as in expressions of being vs. doing (I am an introvert or I am a yellow/red instead of I act introverted or My preference is yellow), as if part of a person’s identity. The notion of some of these styles as a fixed identity rather than an adaptable behavior, while a pretty core concept in personality theory, seems to me at odds with the way real people communicate well.

Let’s take an example: left to my own devices, I talk like this – I wander, I use fanciful words, I talk informally and in abstract blah blah blah. This has not always been true & has not always served me. There have been times when a more crisp, bullet-pointed, decisive way of thinking has worked better, and other times when introspection and consideration were more important. I get different results from style-preference assessments at different times & in different contexts. Most people do, if they answer honestly (it’s also easy to game assessments, either by knowing them well, or by being influenced by your notion of fixed, immutable type). Many of the things we think of as “personality” are nowhere near as solid as we think of a person being. [Er. So, there's a whole other field of discussion about how solid individuals actually are, and it's not really related... but that's neat, too.]

If style preference is an adaptation to circumstance, then, people have a much wider range of options open in communicating with each other. We have the style choices we liked yesterday, the style choice someone else might like today, and the style choice we’ll actually prefer tomorrow (which, if we adapt, is some combination of the other two). I think this is delightful! If we consider our interactions with others in this way, we have so many options to allow those interactions to change us.

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.

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.

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.

Short story: Python’s faster.

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.