Here’s a video that very prettily relates the Fibonacci sequence to nature and the golden mean.

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.

Esther Derby posted this lovely Mary Parker Follett quote earlier, and I share it because it elegantly describes what I think about leadership.

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.

I finished my first coaching project today, and am leaving the lovely little city of Boston tonight. It’s exciting to imagine what will happen next, both for the teams I leave and for me. It’s a little sad, too: I’ve spent time with some pretty fantastic people, both the tiny ThoughtWorks team (in other words, Patrick Turley, with a little Ron and Greg for seasoning) and the gang from the client side. They’re swell, even when they’re a pain in the ass, and I’ll miss them.

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.

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.