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.

Why do pears fall in love?

So, I've been following Corey Haines' Pair Programming Tour. Check it out, it's a rather cool gig, both as it brings the topic of Pairing back under a much needed limelight, as well as, in and of itself, the totally unique and inspiring act of Corey taking such a tour in the name of our craft. Kudos Corey!

It's got me re-inspired to write up some of the things I've always wanted to about pairing, as I'll do now and then here in my nifty new super fantastic blog.

To start, I'm drumming something up from one of my first writings years ago about this wonderful thing we call Pair Programming. It's a simple list, intended to highlight the major reasons why we pair. Here it is...

When programming (ie. designing) alone even the most disciplined/skilled of us will:

• Get stuck on various "how to's" (often for a great deal of time)
• Often stray, both in thought and code, away from the current task at hand
• Spend a lot of time debating various decisions in our head
• Create designs only we understand, thus requiring a future time-consuming learning curve for everyone else (trust me)
• Be prone to, at least occasionally, make bad decisions - each of which incurring technical debt*
• Be prone to make programming errors (especially if we're not test-driving), thus incurring technical debt*
• Be likely to "cheat" (out of good programming practices), thus incurring technical debt*
• Periodically get burnt out, requiring a break [during which time no work is done]
• Have no one to encourage us or celebrate with

* "technical debt" = exponentially costly [ie, time-consuming] future rework!
See also: Martin Fowler on Technical Debt

When pair programming (ie. designing) even the least disciplined/skilled of us will:


• Rarely get stuck on any "how to's" - for those things that stick us, our pair is highly unlikely to be stuck as well
• Remain focused on the task at hand
• Be able to more efficiently [quickly] make design decisions collaboratively with our partner
• Be sure that at least one person won't have a time consuming learning curve to understand my design
• Be forced to verbally justify the rational for our decisions, thus greatly decreasing the likelihood that we "miss something"
• Rarely make a programming error that our pair won't pick up
  
• Not be able to "cheat"
• Be able to pass the keyboard to our pair when we need a break - keeps us moving, and keeps us fresh
• Have someone to constantly encourage us and celebrate with (ie..fun)

For these reasons, it has been shown that diligent pair programming, at least over any non-trivial period of time, does not decrease team velocity. In fact, it will often increase team velocity (and, as a nifty side effect, software quality as well).

So, chew on that, maybe it'll help you in the next hallway conversation where you need to explain to someone how "pairing does NOT double the time it takes to get something done".

And of course, remember why this is necessary in the first place: The world we live in these days, well kids, It Ain't Your Daddy's Software Development...

**Update: Check out this for some Q&A about Pairing

Where art thou been?

(Disclaimer: you will find nothing of value in this post. Leave now.)

So, here's me, welcome to the party. For the life of me I cannot even begin to understand how it's taken me to until December 13, 2008 to actually create my own personal blog. It's an anomaly. Whacked. Crazy. Odd. Questionable.

Anyone who knows me knows that, more often than not, its hard to shut me up. I love to write, I've been doing it for many years, and in many ways, for many reasons. I've written much about many things. Much even about software, and about agile, about people and the world we all rock.

So where have I been? Who knows, maybe I was subconsciously afraid no one would give a flying crap what I had to say in the blogosphere and was avoiding the rejection? Maybe I wasn't properly motivating myself? Maybe I was too busy with other stuff? Maybe I'm just lazy (yes, that's it).

It's unfortunate, really, how much people fail to do the things they know they should do, or want to do. How much we let something get in the of way it. Personally speaking, and professionally. In life, and in business...and, here it comes, definitely in software development. People, all over the world, knowing they could or should be doing software better. Designing better. Coding better. Delivering better. Collaborating better. Communicating better. Trusting better. In the end - living better.

Doing it better...and having more fun doing it!

So, here then lies the root of what you'll likely find here: writings...well, ok, ramblings (some useless, some useful, some idiotic, some wise, some comical, some ridiculous, some stupid, some cool), that chronicle whatever might be striking my fancy any given sunny day about the world of software and the people who inhabit it. Sometimes it'll be geeky, sometimes business-y, sometimes touchy-feely, sometimes none of the above. We'll see.

Anyhoo, just needed to get that off my chest, that was for me, please do disregard this rambling collection of words. Promise, no more stream-of-consciousness psycho-babble about "me" (well, at least not for a little while!). From here on out, we talk of our craft. We talk of software, and of that funny thing they call "agile".

See ya soon.