I am late filing my taxes for 2007, which explains why I’m awake at 5.00 this morning. I’m not entirely sure how many consecutive mornings I’ve been waking up earlier and earlier: maybe it’s six, maybe it’s seven. My fingers feel a little heavy, I’ve yawned three times since I opened my computer, and it’s too dark in here to scan paper, so I decided to write these words.

Let me tell you a little about my project: I have to file my taxes. Since I have been audited, I no longer trust myself to file my own corporate taxes, so I’m preparing paperwork for my accountant. My goal is to deliver a DVD of my data and let my accountant and her staff do a first draft of my taxes while we’re at XP 2008. When we return, I’ll be able to answer questions, then I hope to file before June 28 when we have to leave for the next trip. That is the goal, some context and a few constraints, and I think that’s enough for you to understand me.

This, dear friends, is a death march. Here is how I know: I have a pile of things to do long enough that I don’t know how much there is, I don’t know when I will finish, I don’t feel like measuring what I’ve done will help he know how much more time it will take, I have doing this essentially 12-14 hours per day, I have no system for choosing the next task, and I feel like I’m making up the tasks as I go. As a result of all this, I’m in here at 5.16 and I don’t think I’ll leave here until 22.00, and I need to do this until further notice, and until it’s done. And oh yes, I can’t really describe “done” precisely, but I’ll know it when I see it. That all sounds like a death march to me. It’s not a fun place, so how did I get here?

A big part of it is fear: I am at the tail end of an audit for the four preceding years, and I don’t think I’ve ever felt so much stress in my life. I dealt with my father’s alcoholic rages better than I’ve dealt with this audit. I have coped (if you can call it that) mostly by withdrawing from life in general and certainly avoiding anything that looks like financial record-keeping. Of course, I’ve also spent a lot of time blaming myself for being such a poor accountant, even though my last bit of real accounting training was 1991 in high school. I’ve been afraid to deal with the audit, and terrified to keep records carefully since about October 2007 or so, and my year end is October 2007. As a result of this fear I have delayed tackling my current taxes, wanting to focus my accountant and tax lawyer on the audit. Only now that the audit is mostly settled have I turned my attention back to the present.

Another part is incompetence: in 2002 I walked away from my first accountant because I started a full-time job and let my company hibernate indefinitely. On that basis I couldn’t justify the expense of an accountant. As a result, I hired myself as accountant by default, and while the job wasn’t very demanding in 2003, I left my full-time job that year to write JUnit Recipes, which led me to more of the work I’d wanted to do as an independent, then I started XP Day North America, which introduced me to my current business partner, ... you can see where that’s headed: more money, more records to keep, more taxes to pay, and more financial information to get wrong. It’s that incompetence that directly led to the audit and ignorance of a good filing system that has led to the long string of files of paperwork I need to process here. If I were any good at this, not only could I file my taxes sooner, but I probably wouldn’t have been audited in the first place, and even if I had I would have been confident enough to handle it well.

As you can see, incompetence and fear play a big role, and not that my incompetence—at least as far as it has hurt me in this context—has mostly to do with something I was never trained properly to do! It’s worth arguing that if I’d hired someone to do it, I’d be in better shape, and that that is the truly incompetent part. I grant that, but part of the reason I didn’t hire anyone is that I was too ignorant to see that I needed to do it, then once I realized I needed someone, too ashamed of the mistakes I’d made to let anyone look at them. Fear, incompetence, shame… I’m doing really well so far.

Finally, there are the tangible effects of my fear, incompetence and shame. The audit has contributed to my sinking into a fairly deep depression (and no, not just sadness, believe me), the result of which has been many days spent in bed, rather than taking care of these matters. Every day I went to bed thinking, Tomorrow I’ll get up, start working on my financial records, and within a couple of weeks, I’ll have organized everything, and every morning the first big thought in my head was, Not today! As a result of this, not only were my 2007 records remaining disorganized, but my incoming paperwork began to create a serious backlog. Even more, I wasn’t separating the 2007 material from the 2008 material, which is one of the reasons my current work is going so slowly: I first have to figure out whether I need to handle a piece of paper before I handle it. Such waste!

In addition, as you might expect, I am ignoring my other responsibilities in the name of Getting This Done, but when an urgent request comes up, it completely ruins my flow. My business partner needed me to pay him for some long-outstanding invoices. Nothing huge, but big enough to matter, and because the invoices were months old, I had to wade through old reports, old receipts, and so on, in order to help him. What should have taken 45 minutes took over 3.5 hours and knocked me completely off my rhythm. (I did manage to track down the cause of a $107 credit I had in my books, though: it turns out the credit was my mistake. Big surprise.) Yesterday, after paying him (but not for everything, because I’m just not that well organized) I had to stop working, even though it was only 17.30, because my mind simply folded up its tent and left. I couldn’t concentrate at all. I managed to go grocery shopping, but even that manifested this death march: we usually shop every 2-3 days and carry home 2-4 bags of groceries. Sometimes those bags are pretty heavy, but usually they aren’t. This time, even though we were leaving the country in 5 days, we carried 5 bags home—after buying another bag at the store—and just barely. I don’t know about Sarah’s, but my bags were heavy! I was struck by how my work problems were affecting my home life. About the only benefit of staying in my office is that I’ve mostly avoided working around the contractors finishing up the main floor in our house.

So it’s now 5.37 and the sky is brightening despite the rain. Pretty soon I’ll be able to see enough that I can’t justify not scanning papers and organizing them. I don’t know how much I’ll get done, nor how far along the project that represents, nor when it will be done, nor how to pace myself to finish it. I don’t yet know whether I’ll be late and delay my taxes an extra 1-2 weeks as a result, not to mention having this waiting for me when we return from Ireland. I don’t know much about this project, but I’m busting my ass on it, and that is what makes it a death march.

The foregoing is a true story. The names have not been changed. The events are real. I hope you feel a little compassion and even pity for me, even though this is a situation largely of my own creation. I have a question: do you think the causes of your last (or current!) death march are much different? Do you feel compassion and even pity for the people who landed you there?

Discuss

I use Backpack to help me change my habits for the better, and I wanted to share this little technique with you.

The programmer in me values version control systems because they allow me to keep an indefinite record of what I’ve done. If something goes wrong while I’m working, then I can go back to an old version of a file and continue working. This is why I use Mercurial every day.

The entrepreneur in me values off-site backups because if a fire destroys my office, then all I need is any computer and an internet connection and I can get back to work. This is why I use Amazon S3 every day.

The scanner in me values getting things done, because when commitments start to sneak up on me, I have my commitments, actions and priorities in one place, and I can get back on track. This is why I use OmniFocus every day.

What I’ve noticed, though, is that my tasks aren’t really getting done. For me, most tasks require building or changing some key assets. Sometimes that’s code, or expense receipts, or drafts of an article. It’s not good enough to write the article, I want to put it into version control and know it’s backed up off site. It’s natural for me to end a coding session by committing changes to Mercurial, but it’s not yet natural for me to end a non-coding work session the same way. I need to remind myself to do this.

Whenever I hear myself think or say, “I need to remind myself…” I immediately log in to Backpack, because it does such a great job of reminding me of things. Today, I added a reminder that reads

A task isn’t done until the assets are safe: under version control and backed up

I set the reminder for tomorrow, and every day after that, until the idea is burned into my brain and becomes second nature. I’m not sure how long that’ll take, but by this time next month, I should be able to switch that reminder to every month, just to make sure it doesn’t fall completely off my radar.

This is how Backpack helps me move away from bad habits and move towards better habits.

Discuss

What does velocity measure?

First, let’s be clear: by velocity, I mean story points delivered per iteration over time. Of course, that means we need more definitions, so let me get those out of the way now.

“A story point” is a unit that programmers invent solely to make it easier to estimate the work it takes to deliver a story. A story point is however big the programmers decide it is, no more, and no less. Story points are useful to the extent that they help programmers compare the effort required to deliver different stories, so that the team can decide how many stories to commit to delivering in a given iteration. Although story points necessarily fluctuate in value, one hopes that over a sufficiently short span of time – say the length of a release – the fluctuation is small enough that a constant approximation of velocity is helpful enough to plan the release.

“Delivered” means realizing (in the accounting sense) the value the customer intended to realize by asking the team to work on the story. A story is not delivered until it either reduces cost or generates revenue.

“Iteration” means equal-length time boxes the goal of which is to provide natural breaks in daily work to reconsider the plan and stop work from expanding indefinitely. On teams that have less trouble stopping when they’ve done enough, iterations are less important.

“Over time” refers to the trend of spot measurements over at least the length of a release.

I hope that makes it crystal clear what I mean by velocity. Now that I’ve clarified the meaning of velocity, what does it measure? It simply aggregates past estimates of effort of a set of stories the team selected to complete in the last several iterations. That doesn’t sound like much, does it? There’s more. Here are some things that velocity does not measure:

• productivity
• efficiency
• value
• suitability to re-hire or retain

...and, of course, past performance does not guarantee future results. Read your prospectus before investing. If velocity is so meaningless, then why measure it? Well, it turns out that:

• It is a good approximation (accurate about 2 times in 3, we think) of what the team can commit to in the next iteration
• It is a good approximation (we think) of what the team can commit to over the next handful of iterations (say 4-6)
• It is a good approximation of when the current stack of work we’ve identified will be done, as long as the stack of work isn’t too large (up to about 4-6 iterations’ worth)

I have just witnessed a conversation on the extremeprogramming Yahoo! group that illustrates the knots in which we tie ourselves when we allow ourselves to be too imprecise about what a measurement measures. The whole thing puts me in mind of personal financing and when budgets don’t work.

Think about budgeting your expenses at home: you know how much you actually pay for some expenses, like car payments, mortgage or rent, insurance… the amounts you owe are usually spread out over such a long period that you can anticipate what you’ll owe next month with certainty. Moreover, you know that it takes concerted effort on someone’s part, or human error, to change the amount you owe on a mortgage, car loan or your home insurance. Changes in those amounts, at least correct ones, generally don’t sneak up on you.

There are other expenses that vary from month to month: food, clothing, entertainment, communications… the amounts you owe usually depend on how much of a given resource you consume, such as how much you eat, how much you talk on the phone and how stressful your work is that month. You can budget these amounts fairly accurately, because the variation is low enough and mostly under your control: you can choose to eat less, take better care of your clothes, read more library books and rent fewer movies. Not only is it easier to guess what you’ll spend in a given month, but if you start spending too much, you can easily correct course to spend less.

There are still other expenses that you just can’t foresee. You are injured in an accident and rack up $20k in hospital bills; this is the year out of the last ten that you finally need new shingles on the roof; you find out your son needs braces. You might buy insurance as a way of smoothing out the costs over time, but they are generally big expenses that you know are coming in the larger sense, but which arrives without warning and needs to be paid immediately.

These are the expenses that make budgeting not work, because they prove that there’s no such thing as a typical month. This is also why you cannot rely on velocity to plan far ahead: there is no such thing as a typical project or even a typical iteration. If velocity doesn’t bring a project under control, then what might? For an answer, I invite you to consider personal finance again.

I read Your Money or Your Life to help me bring my personal finances under control and become financially free. One of the key exercises the book asked me to perform was to track all money coming in and out of our household for several months. This exercise is designed to call attention to our spending habits, so we can decide what to do about them. In particular, we identified those expenses we valued and those we didn’t value, so we could stop spending money on things we don’t value. This tactic, spending money only on things we value, doesn’t necessarily make one rich, but it ensures that one is not wasting money on things one doesn’t actually value. You’d be surprised how much money we were throwing away on things that didn’t ultimately make our lives any better, and you’d be amazed at the results when we stopped: we used that money as capital to generate passive income, and within five years, we’ve become financially free. But I digress. The point is what we measured, then how we analyzed it.

We measured actual spending, rather than estimated future spending or even estimated past spending. When we had the numbers, we didn’t start slashing expenses we cared about, and we didn’t start looking for cheaper alternatives to all our expenditures. Instead, we simply looked for those expenses we did not value, then cut them off. In some cases, this required investment of money: we bought a coffee grinder, an AeroPress, then started brewing coffee at home, rather than spending $2 per on coffee at our local coffee shop. In some cases, this required investment of time: we reviewed our work commitments and changed the way we work so that we wouldn’t be so tired so often, which meant we no longer “needed” to order dinner in as often as we did. We measured our actual spending, we looked at those numbers to identify waste, then we eliminated it. We did not waste effort staring at our budget, wondering how accurate it was, wondering how realistic it was, desperately trying to spread not enough money over too many expenses. We didn’t have to: we had actual expense numbers and could decide which items we valued and which we didn’t. More to the point, this exercise was far more instructive and effective than budgeting ever was.

Does your company value the areas where your software team spends its money? Do you know how to measure the value of what your team produces? How much money (time, energy, or actual cash) does your team spend on things no-one values? Could you pick three such wastes and eliminate them? What would you do with the recovered time, energy, or cash? How would you know that things got any better?

Forget velocity for the time being. Measure it and report it to whoever still wants it, but just between you and me, forget velocity and focus on these key questions. Try it for a few months. Tell me what happens, at ForgetVelocity atSign jbrains theDot ca. I’d love to hear from you.

Discuss

describe "Year 2008" do
    it "should be happy" do
        Date.new(2008, 1, 1).year.should be_happy
    end
end

Best wishes to all my readers for a happy 2008!

Discuss

I ran across Cédric Beust’s article Agile People Still Don’t Get It again, and I just wanted to point one little thing out for you, for him, for everyone. He writes about a presentation he attended that illustrated why agile people still don’t get it:

One of the first slides that deeply troubled me claimed the following: Tests are (executable) specs; (and) If it’s not testable, it’s useless.

Cédric went on to show a number of examples of algorithms that aren’t worth test-driving and useful code that isn’t testable. All very good, all understood, all makes sense; but all in his acerbic, off-putting style.

Cédric, I love you like a brother, but this Bileblog nonsense is wearing thin. We’re not 21 any more; and it’s time to reach a wider audience of more thoughtful people through sensible and reasonable discourse. I’m afraid that, in this case, your conclusion does not at all follow from the hypothesis.

It’s true that there is a steady supply of agile evangelists out there that push agile like a religion, but not only is none of this is news, but it’s a natural part of the evolution of any idea. I went through my proselytizing phase. It was at a time when my primary concern was getting to practice agile, and I thought that if more people liked it, more people would give me the chance to practice it. Instead, I started taking myself more seriously as a business person, made more money, and that has translated to more free time to practice whatever I want to practice. This allowed me to feel more secure about my own agile practice and my own effectiveness as both a practitioner and consultant. Not everyone takes the lead in their careers like I did, so when you see someone lashing out, proselytizing, don’t hate them, but help them. There’s something missing in their lives, and it’s worth offering them a chance to find out what it is and fill the void. People did that for me, and I’m willing to do that for others. Are you?

On the question of the agile religion, you might think Bob Martin is one of the High Priests of Agile, but as early as 2002 (!) he warned us about this behavior, and I take away two key points from his message. I believe it was at a dinner talk at XP/Agile Universe 2002 that he invited us not to make absolute statements about agile.

Those absolute statements served us well to rile up the visionaries (in the Crossing the Chasm sense), but as we reach the mainstream, statements like these hurt more than they help. I prefer to tell people that the more they test, the better their features are; and the more testable their features are, the more easily maintained they are. They seem to respond to that, especially when I show them how that is. I still astonish people, as unexpectedness is a key component of a sticky message, but I prefer not to use divisive, absolute rhetoric to do that. I use different techniques for that now.

I believe it’s become more important to be less overtly provocative, and instead be clearer with our advice. I don’t think most thoughtful agilists will claim that they write production code the way they teach others to do it; but this is not a simple case of “do as I say, but not as I do”, but rather a case of the student needing to learn the lessons by following some useful rules before leaning too much on under-developed judgment. Not everyone agrees that we should give novice rules to novices, but it works well for me, so I do it. This means that I sometimes tell people “delete that code because it isn’t tested” or “stop and refactor the code until it’s testable”. I find it an effective way to help them learn and develop judgment, the skills I believe will serve them best. I tell my students directly:

Do I take tiny steps like this every time I write code? No. Do I think you should take tiny steps like this when you write code? Yes. Why? Not because it’s the best way to write software, but because you learn a lot when you do it and, more importantly, when it’s 2 AM, you’ve been called back from vacation, you’re performing surgery on a production system that’s losing $100,000 per hour of downtime, you’ll be glad you can work in such small steps.

More succinctly, I’m more up-front with people about the pedagogical aspects of what I do. They seem to respond well to that, rather than patting them on the head and saying, “No, trust me, just write the tests. You’ll learn.” I’m sure there are plenty of trainers out there, agile and otherwise, who treat their students like children, rather than adults. They make absolute statements of the type that Cédric is right to complain about. I just wish he wouldn’t make it seem like a uniquely agile problem, and I wish he wouldn’t lump us all in one bucket. I suppose it’s convenient to do that, but it’s not true.

In fact, it feels downright religious to do so.

Discuss