Burning-Down the house

A (the?) primary essence of agile is to focus on delivering value-adding functionality as often as possible. Value-adding, that is, from the point of view of your consumer.

[Quick aside: we most often think of this in terms of value-adding 'application software', but certainly not by rule - it is whatever it is that is of value to your consumer. If you don't have a consumer, or if you aren't bringing value, then why are you spending time on it? Anyway...]

The implication of this is that many tasks we perform, while in most instances are in fact (hopefully) necessary, do not in and of themselves provide any real 'customer' value. In software terms, for example, this means that while "analysis" or "coding" or "testing" activities might in fact be necessary, they are not what our consumer/customer seeks…it is "a working feature" only that truly provides the value.

Let's bring into the discussion that holy agile grail we call a "story" (a symbol/moniker for a value-adding feature) - it is assumed that all the tasks that have to occur to deliver a story will occur, but alas, we simply should not be giving or getting any cookies for completing these tasks. We get cookies only for delivering [running, tested] features; we get cookies for delivering value.

More to the point of where I'm going with this, its not really to any benefit then to explicitly track these tasks (ie, track, meaning in your reports, "backlog" if that's a tool of yours, or things similar). Why? Well, primarily, simply because it is the story (feature) we strive to deliver, not necessarily analysis or code, etc.

(Taking a bit of a tangent here, but its an important one...) "Deliver value as often as possible". The further implication here is that we also strive to break the feature up into smaller and smaller pieces (stories); the smaller, the quicker it can be delivered, eh? And, further, the smaller the more likely to have an accurate estimate; the easier to design in an evolutionary way; the easier to test; etc. But in the end, with respect to our "stories", no matter how small we split, we do not split by tasks - each split in and of itself must still provide some sort of demonstrable value. Anyhoo...

"So Mike," you say, "where in the world are you going with all this?!?!". Great question, here it is: (MBark of this post) Do away with your "burndown charts".


The sprint "burndown" [pictured left], at least as prescribed by Scrum, is tracking tasks. Being we like not to focus on tasks, and being we only get cookies for completed stories, doesn't a burndown focus us on the wrong thing? Yes, it does. Bad burndown, bad. In addition to focusing us on the wrong things, it burdens us to worry about too many things; to, in many ways, encourage us to micro-manage (which, of course, is not good for anybody and very un-agile). If you need more, how about the fact that it can lead quite readily to false-negatives with respect to how "done" you really are: "great, Bob, you've got task x, y, and z's hours all used up, sweet!"...but, uh, what the heck does that really mean with respect to the status of obtaining your real goal (delivering the feature)?



Thus, a "burnup" [pictured right]. A burnup tracks only features (whatever that might mean in your context); the features represented by stories, each assigned a point value to indicate size. When a story is complete (a feature is "done"), the burn goes "up" by that feature's points. No hours, no tasks, no minutiae about various random "inputs" - rather, just a simple representation of what we really care about - features being output. Easy-peasy, and way more in line with our goals. And, of course, as far as contributing as a tool to help us determine our velocity: if we really need to measure anything, what we really want to be measuring is our rate of delivering working software, not our rate of "doing analysis", right?

Be not mistaken by my message, it's not to say you and your team won't have daily knowledge of what particular tasks might be going on, I sure as hooha hope you do! It's just that we don't go so far as to officially track or measure them. That's what your daily stand-up is for. And, of course, common sense is required, if you really want them to be visible, fantastic (I mean it) - go ahead and hang up some task stickies on your Storyboard or some other "information radiator" hanging in your team room.

But, alas, my spidey-sense says: unless you're hoping to burn down your project, steer clear of the Burndown chart.

Riddle Me This, Mr Pair Programmer

"So, my programmers were pairing; one was on the middle-tier stuff, the other on the UI layer. Things didn't seem too efficient to us. What's up?"
Two people working on different "pieces" of the same story, even if simultaneously, is not "pair programming" - this is plain old fashioned delegation. In fact, this often decreases overall productivity, due to the fact (one of many) that putting the pieces together often exposes mismatching interfaces requiring varying degrees of rework.

"Pair programming" means two people working together, side by side, on the same exact piece of code - two people thinking and talking together, one person [happens to be] typing. Furthermore, 'one person typing, one person watching' is also not "pair programming"; the key to pairing is two people thinking as one...two people collaborating.

"How to best go about selection of pairs?
Pairs should typically not be assigned, they should be formed naturally on their own. [But, see the next question for more info]

"I suspect that some pairs, for example two junior programmers, might be less effective and thus decrease productivity and code quality. Is this true?"
Yes, technically there is some truth to this... at least at the beginning. Part of the point of pairing is to help share skills and knowledge, so it may help to match up more skilled with less skilled.

BUT, much more true when you start pairing as a team, not so much once you've been at it for a little while. Once everyone is of relatively equal understanding (of the practices at least) everyone should pair with everyone. The only requirement is that the two people get along from a personal POV (and if they don't, maybe they shouldn't be on the same team anyway?). Within reason, the more "movement" the better. @see Promiscuous Pairing.

Also, something else to chew on. Having "preset/preference" pairs actually works a bit against the desired outcome - the essence of PP is having "two heads" working on one problem, in sort of a checks & balances way; the longer 2 people work together, the more they become "one head", which in large part works against the goal ("two heads collaborating").

"Do we need a certain minimum level of skill across the team before taking on pair programming?"
Absolutely not. Getting to a shared higher "level of skill across the team" is an outcome of PP (not a prereq).

"Is there a way to verify the quality of a pair that is not that experienced?"
The team should simply pay attention and use common sense.

"Is PP appropriate for some tasks and not others? Aren't small complexity activities not worth pairing on, since it just delays them?"
No.

First, on a slight tangent, part of our goal as craftsman in general is to make all tasks "small complexity", ie. simple - small stories and evolutionary design exist in large part to virtually eliminate "large complexity" altogether. When everything feels like a "toy example", then we've succeeded.

Anyway, the "stupid typos"/"silly decisions"/"shortcuts"/etc are actually more likely to occur for the "simple tasks" becuase the programmer often sees it as just that: "oh, this is just a simple little thing, I don't really need to TDD/[fill in the blank], what could go wrong"...and wallah, we've got a broken window.

Now, all that said, yes, if the task is truly a few minute trivial thing, then it may not help to PP. As with all things, common sense is required.

The truth is that the time where one in fact might be better off working alone is when they have a real doozy of a problem that they need to concentrate very hard on to get their head around. If you need some quiet dorm room time, go ahead and split up for a stint. Prototype, spike, get your head about you, then regroup and get to it. Rule is though: "No non-throwaway code during solo time".

"Should teams adjust their expected velocity to account for the effect of pair programming, especially when first adopting?"
My experience is that velocity rarely decreases enough to try to predict it - assuming they pair effectively (which is not hard), the benefits are often gained immediately.

"Do we need to pair from the onset of a story?"
Yes.

"In other words, can a story be begun by one person, then a pair picked up halfway through?"
Not advised.

Pairing actually tends to be a bit counterproductive if "picked up halfway through", mostly because the "pair" comes on and is quite likely to become, at best, a bystander observing what the other has done / is doing, or, at worst, just "a pain who won't stop poking holes in my design".

Again, true pair programming means the two are largely thinking as one, just so happens only one person is typing.

If pairing is attempted "half way in", the result is often "one person thinking, another person simply watching" - which, consequently, is more of a waste of time than a benefit.

E-A-G-L-E-S, EAGLES!!!

Sorry, I just couldn't help it! GO BIRDS!!!

Where'd Jeff Probst go? (aka, Kicking someone off the island)

Yesterday I spent the better part of my morning reading through the 130 or so messages in the Scrum Dev Yahoo group's "Rotten Apple In Scrum Team" discussion, then I posted this "newsy" summary of the discussion on InfoQ.

In a nutshell, Marko told the group of a guy on his team he sees as a drastic "under-performer", or as he put it originally a "rotten apple", and asked for advice as to what to do with him. Read the InfoQ post to get a deeper sense for how people responded, but the gist of most of the advice was for Marko to take an open-minded and objective stab at finding out (and/or helping the team find out) what's really driving this person's performance, or, rather, lack thereof. And then to help him out.

"Try 'Beginners Mind'"..."take queue from Linda Rising"..."pair up with the guy"..."be nice, be helpful, be supportive"...and so on and so on. Hear this clearly (before I get to my real point of this post): I generally agree wholeheartedly with all the advice presented.

Now though, all that Dr. Jeckyll buildup for the Mr. Hyde thought: 130+ replies and not one mention of "kicking someone off the island"?

[...and the crowd gasps in horror...]

I've seen, and I'm sure you have too, a team who had an individual who truly did bring the team down. Typically not because they couldn't program quite as fast, or weren't quite as smart, or weren't quite as good in front of customers, or anything skill/experience/productivity-related like that. Rather, simply because they had a negative attitude, because they didn't play nicely or just plain didn't care.

[*Note: For what's worth, I do not think this applies to Marko's guy, but the discussion got me thinking anyway.]

One seriously under appreciated technique that I stress should be considered for these true "rotten apples" is to get them off your team, kick 'em off the damn island. No one says you have to fire them, just get them out of the way somehow.

Forget tools, intelligence, certifications, experience for a moment. The degree with which having a good team (in the "synergy" sense that is) contributes to good results (and, hell, a good time) is amazing; having a great team, well that's just indescribably astounding, magical even. Conversely, the degree with which having a bad team atmosphere can lead to serious bed-shatting, well, that's also quite amazing as well.

So if you've got someone who after the Prime Directive and the Beginner's Mind and the Pairing has still got that sour-puss face and, more importantly, is still killing your team's ju-ju, then by all means call the spade a spade, cut your losses, and remove them. Be as graceful as you like, but please, as Bo used to say, just do it.

Again I stress, I'm about as "glass half full" as they come - I'm not trying to encourage a general exclusive, head-chopping, "only the best" attitude. 95 times out of 100 your man intends the best and just needs a little love, and by all means you outta be doing your damnedest to facilitate that happening. My point is that for those other 5, stop being so P.C. and get the bad apple out of your basket. Your team's ju-ju will thank you for it.

** Update: Thanks to Esther Derby for shouting out about her related and more concretely useful post from some time ago echoing the same sentiment.