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

The standard, universal data processing answer is “it depends”. Specifically, it depends on the ongoing participation of your stakeholders.

If the development team is demonstrating the application at the end of the iteration to the stakeholders, then that’s an anti-pattern. If you’re not getting any constructive criticism from the stakeholders about the demonstration, then the stakeholders are likely not engaged by the demonstration, and it’s a waste of time. If your stakeholders are engaged, then they’re likely giving a sizable amount of constructive criticism, the result of which is re-working a substantial number of stories in the next iteration. Of course, you could just be that good, but I haven’t met that team yet.

The last time I worked with a team in this situation, they held demonstrations once per iteration, which for them meant every two weeks. They expressed to me that they were not getting feedback soon enough, so I asked them whether they thought weekly demonstrations would work better. They did, they asked the stakeholders to make at least two people available every Friday afternoon, and that worked. After a while, they added a Wednesday morning demonstration just before lunch. The next step would be daily demonstrations, then finally continuous stakeholder participation. The secret was to sneak up on the daily demonstrations.

Rather than ask your stakeholder to go from hands-off to daily meetings, hold demonstrations once per iteration. When they point out how much feedback causes rework, suggest having a mid-iteration demonstration to avoid so much rework. You might be able to fix a small problem or two right in front of the stakeholders, and if you can, then do. (It looks impressive.) Once you’ve established that you can fix some problems without putting the stakeholders to sleep, they’re more likely to want to work directly with you. Each time they notice a demonstration leads to substantial rework, suggest doubling the frequency of the demonstrations. Eventually you’ll arrive at the right amount of stakeholder participation for your project. The key is to let your stakeholders notice the problem of not enough feedback, because if it’s their problem, they might look for solutions, but if it’s your problem, they’re less likely to care. If they can’t see it’s their problem, then look for subtle, non-destructive ways to make it their problem.

My goal is for a key stakeholder and the development team to demonstrate the product together to any and all interested parties. This is an important step towards the whole team approach to building software that I find so incredibly effective.

Discuss

I remember being a technical lead, believing that it was my job to make sure everything was doing correctly and as quickly as possible. The result was predictable: I made myself a bottleneck because I was afraid to delegate important tasks to other people, for fear that they’d do it poorly and have to redo it, or even simply because it would take me less time to do it than to explain to someone else how to do it. I know now that letting myself be a bottleneck is a bad idea, but I wasn’t able to explain why very well until just a moment ago when a long-awaited neural connection finally happened. I almost felt the crackle in my brain at the point of impact.

Tim Ottinger wrote about Sooner, Not Faster, which I describe to people frequently in my work as a consultant. My goal in teaching test-driven development is not to help programmers write code more quickly, but rather to help them deliver solid code sooner. The time-saving techniques include being clear about what to build before trying to build it (write a failing test first), building only what you need (write just enough code to pass the test), stopping when you’ve built enough (continue until you can’t think of more failing tests to write), and keeping the code clean as you go to avoid building up inventory of uncompleted necessary work (“clean the kitchen” refactoring). Not all these techniques involve thinking or typing more quickly. Some involve thinking more to type less and knowing what’s enough then stopping. In general, I help teams by focusing on how to deliver a satisfactory result sooner, no matter how fast or slow the individual tasks are completed.

Now I wish I’d thought that way as a technical lead. If I have a backlog of 10 tasks that take a total of 4 weeks to complete, but I could delegate some of those tasks to others, then even if they take 5 times as long as I do to complete those tasks, I could delegate any task up to 3 days in length and, as a group, we could be done in 3 weeks, even if we spend more total time working. The alternative is to keep those tasks for myself, then have the others do busywork to avoid looking idle. You might think this is a false alternative, but how many people on your team are working on its top three priorities, and how many are working on other things? The other things are busywork!

Had I thought this way, I could have benefited dramatically. More important work would have been completed, I’d have learned how to delegate effectively, and I would have felt (and probably now feel) less stress.

If only.

Discuss

I recently had the honor of speaking at the Emerging Technologies for the Enterprise Conference, where I renewed some friendships, made some new acquaintances, and spoke about something I enjoy: failures.

Last summer I debuted XP: My Greatest Misses 2000-2007, which became popular due to its honesty and directness. (See an example of the response to it.) I followed this theme of reflecting on failures to gather some mistakes I have seen people make as they make the transition from work group in chaos to agile team. It’s important to note that I didn’t talk about the five biggest mistakes, the five most common, nor the five most dangerous; but rather, simply about five mistakes that came to my head. As you’d expect, once I’d written my five in the notes, I found a number more, especially as I sat in my fellow presenters’ sessions. Even when they weren’t describing mistakes at all, they triggered a number of memories—so many that I could easily have written the 20 mistakes new agile teams make.

Please enjoy Five Mistakes New Agile Teams Make, and if you’d like me to visit your user group, please contact me at the prominently-displayed e-mail address on this site. You should also consider contacting the Agile Alliance to find out how to qualify for funding to bring out-of-town speakers to your user group or event.

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