Burn-down charts, sometimes known as 'glide path' charts, are a tool used to track progress and momentum in agile projects. Typically this chart is posted somewhere highly visible to remind people that there's still a lot of work to do, and it's no time to relax. In theory they're a great productivity tool, but I don't like them at all.
My sole claim to lasting fame so far is an acknowledgment in David's book regarding my turning him on to Cumulative Flow Diagrams (CFD). Although I didn't know the formal name for them at the time, I had very strong opinions as to why they were superior. You see these charts sometimes in industry growth reports or other areas where you're tracking multiple trend lines simultaneously. The best current example I have for this is a graph of Hybrid Electric Vehicle sales. If a pie graph tracks the distribution of a pool of data for a fixed moment of time, a CFD tracks it over a period of time.
A Burn-down chart, if properly drawn, can reveal a dangerous situation: divergent lines. That is, more tasks are being started than completed, more tasks are being completed than tested. If you find yourself in this situation, it is time to drop everything else that you are doing and have a frank discussion with upper management about project strategy, and the potential for success of the project in meeting its delivery milestones.
What it will never show, however, is if new feature requests are coming in faster than tasks are being completed. Burn-down charts obfuscate one of the biggest risks to a project delivery date, even for Lean or Agile projects: scope-creep. A Burn-down chart sets the 'destination' as the origin of the graph. What happens when the destination keeps changing? If the Y axis is counted in number of tasks to complete, you have to redraw the graph, pushing the lines upward and recalculating them (a potential source of reporting errors, but not so bad if you set up your spreadsheet correctly). Worse, if your Y axis represents percentage complete, then you have a more serious problem, because your % jumps around from week to week. At a minimum, if you must use Burn-down charts, make the axes absolute. The level of unproductive meta-discussion that can be caused by a relative Y axis on a project that suffers from repeated re-scoping can be astoundingly high. Planning meetings where you are expected to figure out what to do about the information can quickly degenerate into hour-long discussions about what exactly the information is.
What we want to see on the progress graph is the current notion of how much work is left to be done, along with the current state of completion. The human eye is remarkably, if not perfectly, good at processing visual information. With a CFD, enough information is presented in the graph that everyone can make determinations about project trends without the necessity of extensive footnotes or side-commentary. The graph literally speaks for itself.
In some situations, the CFD will reveal a bad situation for what it is long before there's articulate consensus among the team that something is not going well (it's very easy, and indeed common, for developers to complain that a situation is bad, it's much harder for them to demonstrate how bad it really is). If the whole point of the graph is to measure and to report, and hence to know what the hell is going on, why chose a graph that is less capable of achieving this goal?
Tuesday, August 28, 2007
Saturday, December 30, 2006
Red Pen, Black Pen
Or: How to succeed at a requirements review meeting.
If you work in software development (and I include management and testing), then it's safe to say that you have a requirements problem. In fact, if my experience holds at all, most of your problems are requirements problems, whether you realize it or not. Any and every trick that helps with requirements is helpful, but the simpler the better. The simplest one I know of involves pen and paper.
If your responsibilities include digesting requirements documents, then I have a piece of advice that's saved me countless hours and more than a couple follow-up meetings: First, get yourself a red pen. Second, any time there's a reading of the spec documents (group, or individual) bring your red pen AND another pen (blue, black, it doesn't matter). Third, color code your comments.
After the reading of the specifications or requirements, you're going to discuss the outcome with others, and adjust other documents (like the schedule, the task list, the test plan) accordingly. As time progresses, your recall of the review will become progressively fuzzy in your brain. Even walking out of a long review meeting, you've probably forgotten at least one critical detail, and even if you've written it down, it's easy in scanning a document to miss black comments on black print. If all of the critical notes are made in a high-contrast color, then the odds are working in your favor.
The process is pretty straightforward. All of the 'bad news' you find in the spec is either written or circled in red. Bad news usually means one thing: schedule slip. This can include things like:
If you're reading the spec professionally, then you're probably also responsible, in some fashion at least, for time lines and estimates based upon that specification. Every change or discovery in the document that wasn't covered by previous readings represents a three-fold risk to the success of the project. One, surprises represent more work than you previously signed up for. Two, early surprise is much better than late surprise (pain avoidance kills). Three, a high number or degree of surprises indicate a systemic problem with requirements gathering, organization, or hand-off. Identifying that problem should be a high priority for the team, and fixing it should be a high priority for management.
If you work in software development (and I include management and testing), then it's safe to say that you have a requirements problem. In fact, if my experience holds at all, most of your problems are requirements problems, whether you realize it or not. Any and every trick that helps with requirements is helpful, but the simpler the better. The simplest one I know of involves pen and paper.
If your responsibilities include digesting requirements documents, then I have a piece of advice that's saved me countless hours and more than a couple follow-up meetings: First, get yourself a red pen. Second, any time there's a reading of the spec documents (group, or individual) bring your red pen AND another pen (blue, black, it doesn't matter). Third, color code your comments.
After the reading of the specifications or requirements, you're going to discuss the outcome with others, and adjust other documents (like the schedule, the task list, the test plan) accordingly. As time progresses, your recall of the review will become progressively fuzzy in your brain. Even walking out of a long review meeting, you've probably forgotten at least one critical detail, and even if you've written it down, it's easy in scanning a document to miss black comments on black print. If all of the critical notes are made in a high-contrast color, then the odds are working in your favor.
The process is pretty straightforward. All of the 'bad news' you find in the spec is either written or circled in red. Bad news usually means one thing: schedule slip. This can include things like:
- Clarifications
- Addenda
- Surprises ("hey, why didn't I notice that before?")
- Open questions (surprises we haven't met yet)
- Your own commentary on how a requirement should be executed
If you're reading the spec professionally, then you're probably also responsible, in some fashion at least, for time lines and estimates based upon that specification. Every change or discovery in the document that wasn't covered by previous readings represents a three-fold risk to the success of the project. One, surprises represent more work than you previously signed up for. Two, early surprise is much better than late surprise (pain avoidance kills). Three, a high number or degree of surprises indicate a systemic problem with requirements gathering, organization, or hand-off. Identifying that problem should be a high priority for the team, and fixing it should be a high priority for management.
Wednesday, December 20, 2006
Juggling as Allegory for Software Development
Everybody has their favorite complementary activity which they say will make you a better programmer. For many, it's 'learn Lisp!'. My advice for undergrads (dating back to when I was also an undergrad) has always been, "Get a job in Tech Support so you learn how 'normal' computer users think." But now I have some advice for everybody else:
Learn to juggle.
It's something I tried to learn in college, but never really mastered. This Spring, in an attempt to bring some much-needed balance to my life, I did just that. Six months later, I wasn't good enough to perform in the park, but I was at least the best juggler in my social and professional circles. I'm also a bit wiser for it.
They already call project management a 'juggling act'. I suspect if more people learned to juggle, they'd realize that there's far more to that analogy than meets the eye.
Juggling, better than anything else that I've tried, teaches you about one of my hot-button issues: Panic versus Urgency. Every single project I've been on where things were going badly either started out with the development staff in a blind panic, or quickly got there. In Juggling, Urgency is the rule of law; If I don't place my hand just so within the next second, then the balls hit the floor. It makes no difference if I accomplish this in half a second, or one second. It simply needs to be done when the time comes. The moment of panic comes (or tries to come) when one of those deadlines is in jeopardy, or something is not going according to plan. However, if you let panic set in, then it doesn't matter what you do from then on. It will be a matter of fractions of a second before all of your juggling equipment ends up on the floor, hitting you in the neck (ouch!) or landing on the cat. The cause-effect feedback loop is so tight that even an idiot couldn't miss it.
The proper way to deal with imminent failure in juggling is to identify impending disaster as soon as possible. Once identified, there are certain procedures that can be performed in some cases. If you catch a pin backward for instance, there are throws that are guaranteed to fail, and there are throws that are more likely than not to succeed in restoring balance to your formation. If there are no tricks (or you haven't learned them), then your next best goal is to get all of the flying objects safely in hand, take a deep breath, and then start again once you've regained your composure. Slow and steady is the trick, and juggling can teach it. In fact, now when my juggling is going fairly well, a sense of calm descends on me now. This is a complete 180 from what happened when I was first learning to juggle, and what I see happen to many of my coworkers when a project gets serious.
In most of these bad software projects, I've found myself with the sad distinction of being the sole remaining rational mind. I wasn't the one being the most 'productive', at least in the eyes of my panicked manager, but I was the least frazzled, and the one working the least overtime when the project was way behind schedule. Why? Because I only signed on for attainable goals, no matter how unattainable the overall milestone. I complete my tasks, without sacrificing quality, in time for the official milestone. Then when the project slips (and it will slip, because it was always going to slip), the unofficial milestones are set. In theory, this should reduce the level of panic on the team, but at this point everybody (but me) is already emotionally exhausted. In reality, things are about to go from very bad to much worse.
In addition to being exhausted, the project in already tainted because of all of the compromises that were made in order to try to hit the unreasonable (and ultimately fictitious) deadline. Even if this version of the code manages to ship, everybody is now standing knee-deep in the hole they dug at the end of the last development cycle. Which means that when the next cycle begins, panic is waiting just around the corner. After a few cycles of this, the code is so bad that people never stop being panicked. At some point they settle into a sort of shell-shock (aka burnout) that can only be treated by time and distance from the cause, if in fact it can be treated at all.
So I challenge you all to go out, and learn to juggle, or at least learn to learn to juggle. Even the theory of juggling has copious parallels to your professional life. If you don't see them too, I'll be very surprised.
Learn to juggle.
It's something I tried to learn in college, but never really mastered. This Spring, in an attempt to bring some much-needed balance to my life, I did just that. Six months later, I wasn't good enough to perform in the park, but I was at least the best juggler in my social and professional circles. I'm also a bit wiser for it.
They already call project management a 'juggling act'. I suspect if more people learned to juggle, they'd realize that there's far more to that analogy than meets the eye.
Juggling, better than anything else that I've tried, teaches you about one of my hot-button issues: Panic versus Urgency. Every single project I've been on where things were going badly either started out with the development staff in a blind panic, or quickly got there. In Juggling, Urgency is the rule of law; If I don't place my hand just so within the next second, then the balls hit the floor. It makes no difference if I accomplish this in half a second, or one second. It simply needs to be done when the time comes. The moment of panic comes (or tries to come) when one of those deadlines is in jeopardy, or something is not going according to plan. However, if you let panic set in, then it doesn't matter what you do from then on. It will be a matter of fractions of a second before all of your juggling equipment ends up on the floor, hitting you in the neck (ouch!) or landing on the cat. The cause-effect feedback loop is so tight that even an idiot couldn't miss it.
The proper way to deal with imminent failure in juggling is to identify impending disaster as soon as possible. Once identified, there are certain procedures that can be performed in some cases. If you catch a pin backward for instance, there are throws that are guaranteed to fail, and there are throws that are more likely than not to succeed in restoring balance to your formation. If there are no tricks (or you haven't learned them), then your next best goal is to get all of the flying objects safely in hand, take a deep breath, and then start again once you've regained your composure. Slow and steady is the trick, and juggling can teach it. In fact, now when my juggling is going fairly well, a sense of calm descends on me now. This is a complete 180 from what happened when I was first learning to juggle, and what I see happen to many of my coworkers when a project gets serious.
In most of these bad software projects, I've found myself with the sad distinction of being the sole remaining rational mind. I wasn't the one being the most 'productive', at least in the eyes of my panicked manager, but I was the least frazzled, and the one working the least overtime when the project was way behind schedule. Why? Because I only signed on for attainable goals, no matter how unattainable the overall milestone. I complete my tasks, without sacrificing quality, in time for the official milestone. Then when the project slips (and it will slip, because it was always going to slip), the unofficial milestones are set. In theory, this should reduce the level of panic on the team, but at this point everybody (but me) is already emotionally exhausted. In reality, things are about to go from very bad to much worse.
In addition to being exhausted, the project in already tainted because of all of the compromises that were made in order to try to hit the unreasonable (and ultimately fictitious) deadline. Even if this version of the code manages to ship, everybody is now standing knee-deep in the hole they dug at the end of the last development cycle. Which means that when the next cycle begins, panic is waiting just around the corner. After a few cycles of this, the code is so bad that people never stop being panicked. At some point they settle into a sort of shell-shock (aka burnout) that can only be treated by time and distance from the cause, if in fact it can be treated at all.
So I challenge you all to go out, and learn to juggle, or at least learn to learn to juggle. Even the theory of juggling has copious parallels to your professional life. If you don't see them too, I'll be very surprised.
Wednesday, May 3, 2006
All my Spam Comes from Weblogs
It's true. In recent months my rate of spam on a years-old email address has gone from ten a week to twenty a day. And I blame it all on weblog software.
Since I stopped posting my own articles, I've started posting comments on those of others. Some of these sites offer you a choice: You are allowed to comment if you're willing to provide an email address, or a URL. What they don't tell you is WHY they want that information. Some weblogs send a confirmation note to you, asking to verify that you wanted to post a comment. Others simply send out an acknowledgement.
And still others post your email address to their site. That makes the unwitting armchair commentator into fresh meat for the email address harvesters of the world. Hardly an even trade.
You would think that after all the years that were spent learning how to avoid this very problem with web forums, that a conscientious weblog software writers would know better. Sadly, 'conscientious' and 'programmer' all to often don't appear together.
Since I stopped posting my own articles, I've started posting comments on those of others. Some of these sites offer you a choice: You are allowed to comment if you're willing to provide an email address, or a URL. What they don't tell you is WHY they want that information. Some weblogs send a confirmation note to you, asking to verify that you wanted to post a comment. Others simply send out an acknowledgement.
And still others post your email address to their site. That makes the unwitting armchair commentator into fresh meat for the email address harvesters of the world. Hardly an even trade.
You would think that after all the years that were spent learning how to avoid this very problem with web forums, that a conscientious weblog software writers would know better. Sadly, 'conscientious' and 'programmer' all to often don't appear together.
Subscribe to:
Posts (Atom)