Where does this idea come from? From the concept of maximizing the return of capital investment in manufacturing machines.  When you’ve got a costly machine, you may want it to be working as much as possible generating return on your investment.  Of course, you’ve got to have some down-time so that you can maintain the machine.  After all you spent on it, you want it to keep working for a long time.  Therefore you have to take care of it.

Ah, but people don’t burn out like machines, do they?

Is it “hours” that we want? With machines, it’s easy to take the cost of the machine and divide by the number of hours it’s in use.  But is it “hours of machine time” that we’re buying?  Or does the return on our investment come from the ability to sell the results of those hours?  What return do we get if we spend those hours producing the wrong thing?  Or producing “too much” of the right thing–more than we can sell?

Ah, but people don’t produce the wrong thing, do they?  And people don’t get stuck producing the same old thing when they’re pushed to hurry, do they?

What happens when we approach 100% utilization? Go ask your network engineer what happens when the network reaches 100% utilization.  Actual throughput slows to a crawl, but network collisions and retransmissions skyrocket.  Or think about how well your computer responds to you when the CPU reaches 100% utilization.  The computer stays busy, but you can no longer request it to do what you want now.

Ah, but people don’t get mired in rework and rote work, do they?

We should know this by now. Tom DeMarco’s book, Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency came out in 2001.  I confess that I didn’t read it for many years, thinking I knew what it said.  DeMarco makes many more important points than I’ve mentioned.  I thought I knew the topic, but learned a lot when I read it.

André Dhondt recently said on the Extreme Programming Yahoogroup,

The Product Owners look at slack as a way to evaluate whether the team is overloaded–and seek to reduce velocity until we hit slack consistently. Otherwise, we fear we’ll be paying for code debt, bug fixes, and reduced innovation that the team can’t really see until they come up for air.

We should all be so vigilant.  It’s a very sharp knee in the curve when we reach 100%.  As Dickens said in David Copperfield,

‘My other piece of advice, Copperfield,’ said Mr. Micawber, ‘you know. Annual income twenty pounds, annual expenditure nineteen nineteen six, result happiness. Annual income twenty pounds, annual expenditure twenty pounds ought and six, result misery. The blossom is blighted, the leaf is withered, the God of day goes down upon the dreary scene, and and in short you are for ever floored. As I am!’

The same is true of overspending our time.

Why did he make this statement?

He went on to explain, that the design of a dome house depended on a single skin being perfect waterproofing technology.  Traditional houses, by comparison, have multiple imperfect layers.  There are overlapping shingles, which keep most of the water out.  Below that there’s a layer of tar paper, which keeps out most of what reaches it.  Then there’s the plywood sheathing, which blocks or absorbs most of what penetrates the tar paper.  Then the attic insulation….

No single layer of this system has to be perfect.

Software testing works the same way.  If you depend on one method of testing, you’re going to leak bugs into production.

If you do unit testing (or micro-testing, as Mike “GeePaw” Hill calls it) of small chunks of code at a low level, you’ll catch most of the coding mistakes.  Then, if you do small scale integration tests of the code that talks to other systems (such as the database), you’ll catch most of the remaining ones.  Then higher level integration or acceptance tests that check that the whole system is wired together right will catch most of those that have escaped so far.  Then exploratory testing….

Any competent network security professional will tell you that you can’t protect your network from malicious people by relying on perimeter security.  You have to bake security into other levels of access, too.

Again, the same is true of testing to protect your application from bugs.

As Lisa says,

I can’t tell you the one right way to test and develop software….  The one right way for your team to code and test will continually evolve over the years. In fact, I’m sorry to tell you that you’ll never find the one right way; it’s a moving target, but you’ll get closer and closer to it.

This is an incredibly important point!  There may be many “wrong” ways—wrong in that they fail to achieve your objectives—but there is no “right way.”  So I’m happy that Jim and his teams are able to achieve the results they want.  I’m not saying they’re doing it wrong.

At the same time, I’ve seen teams struggle with the increasing burden of acceptance testing and the divergence of understanding between the Customer, the Developers, and the Testers.  And so I continue to explore ways to alleviate that struggle.

Jim describes how the teams discuss concrete examples with the customer.  They then automate those examples (or not) in their own unit and integration tests.  Jim reports that these tests give the programmers confidence that the system is working as desired.  For the customer’s confidence, Jim reports relying on “a reliable track record of shipping defect-free software.”

Jim’s argument is that the customer won’t trust the test results before trusting the team.  This is true.  If the customer thinks the developers will fake the test results, then it doesn’t matter how the tests are expressed; you’ve got a serious problem.

I’ve not experienced this level of distrust.  Instead, I’ve experienced customer’s who trust that the developers are working in good faith, but still don’t trust that the developers will ship defect-free software.  And perhaps the developers won’t ship defect-free software.  They’re fallible, just like the rest of us humans.  Maybe they misunderstood the customer’s example.  Or they made an error converting it to code.  Or they didn’t automate that example because they thought it was the same as another that they did automate. Or…

Mistakes happen.  Miscommunication happens.  It’s great that Jim’s developers have that zero bugs attitude, but the customer has the right and obligation to participate in achieving zero bugs.  It can be condescending to take all the responsibility for correctness.

Yes, the customer gets to review the completed software, but we can detect misunderstandings sooner if the customer can read the acceptance tests.  Yes, the developers may produce defect-free software, but miss a test case such that nobody notices right away when a defect is inserted into this feature later.  I want to enable the customer reading the test and saying “Yes, that’s what I meant.”  I want to enable the customer saying, “I’ve thought about another case we don’t have covered.”  Or “We’re changing our business rules and this example is no longer correct.”  Or anything else that’s appropriate.  I want the customer to share that zero bugs attitude.

But is this practice essential?  Obviously not, as Jim and his teams are successful without it.  For many teams transitioning to agile practices, they’ve probably got too many other, more fundamental, practices to learn that they don’t have the energy to tackle this one yet.

Is this practice too expensive in terms of effort?  Maybe.  A lot of people are working on making it less expensive.  If you don’t make it an integral part of the conversations when you first start discussing the story, then it’s likely to seem too expensive.  Then it’s like writing unit tests after the code rather than doing TDD.  To make it work, I think you need to make the customer examples flow from the initial conversation through signaling “done” for the developer.  You’ve got to work at making them maintainable, just like the code in the system you’re delivering.

This is just one small practice in a forest of useful practices.  The forest can survive without any single one.  We can almost always find ways to compensate for things we’re not doing.  That’s a double-edged sword, however.  It can also allow us to fritter away our advantages until we’re working in the same old way we’ve always done.  It can blind us to some of the process improvements we could make.  Jim’s “fix the process description” is

Every escaped defect, whether found in exploratory testing or found by end-users, is a indication of a flaw in the process. When we find one, we fix our process.

The first thing is to analyze the defect, write a test that reproduces it, and fix it. While we’re fixing it, we look at the design of the code and see if it needs improvement, too.

Next, we conduct Root-Cause Analysis. We ask ourselves, “What about our process allowed this defect to escape?” We continue asking “why” until we get to the root cause. Once we find it, we make changes to prevent that entire category of defects from happening again.

Note that “fix the process” could include adding a process of creating Customer Readable Automated Acceptance Tests.  They’re are a tool that I want to keep in my toolbox.

Certainly when something’s not giving you the results you want, it’s time to make a change.  That change can be to drop the practice that’s not working for you.  It can also be changing the way you go about the practice, or changing what you want to accomplish.  Or, instead of changing, maybe the word “refining” is a better fit.

In my experience, teams that don’t do automated acceptance testing quickly get to a point where adding new features goes slower and slower, just because it takes longer and longer to test all of the functionality.  Sometimes they start trying to figure out which functionality they need to retest, and which “couldn’t possibly be broken by this change.”  This starts down a very slippery slope.  As Elisabeth Hendrickson says,

If the customer has an expectation, they have expressed that expectation, they have every reason to believe you have already fulfilled that expectation, they don’t want to have to manually go re-verify that you have actually done the thing that you said you did before.

Is that so much to expect?

In one of Jerry Weinberg’s books [Quality Software Management: Vol 2, First-Order Measurement, pp. 156-158], he talks about how a one-line change is more likely to introduce a defect than a larger one.  This seems counter-intuitive, until you consider how people drop their guard when they think they’re making a trivial change.  They don’t check everything as completely.  When someone doesn’t check some aspect because “it couldn’t possibly be affected” by this change, they leave the door wide open for Murphy to demonstrate his law.

Given that I’m convinced things need to be retested, and that the shorter the iteration the more frequently they need to be retested, I’m not willing to give up on automated tests.  That leaves me looking at what I want to accomplish and how I want to practice it.

Jim describes two problems with automated acceptance tests.

These two problems–that customers don’t participate, which eliminates the purpose of acceptance testing, and that they create a significant maintenance burden, means that acceptance testing isn’t worth the cost.

About the first problem, lack of customer participation, he says,

The planned benefit of those tools is that the customers are supposed to write the examples themselves, thus improving communication between customers and programmers. In practice, I found that customers (a) weren’t interested in doing that, and (b) often couldn’t understand and didn’t trust tests that were written by others. Typically, responsibility for the tests gets handed off to testers, which defeats the whole point.

I also have found that customers are not interested in writing tests, themselves.  I don’t blame them for that.  Nor do I think they would, in general, do a very good job by themselves.  Sending testers (or developers, for that matter) off by themselves to translate discussions into test examples isn’t any better.  They have the same problems that face the customer, plus the problem of the customer not trusting tests they don’t understand.

I don’t, however, think that’s the way it has to be.

I’m still working on demonstrating long term results, but I’ve had some success using automatable examples as a tool to enhance the conversation between the customer, the tester, and the developer.  Not to replace the conversation, or to send one person off to write tests, but to add precision to the agreement about what needs to be accomplished.  The goal is for the customer to look at the test and say “Yes, that’s what I want.”

Once we’ve got that, there are lots of tools available now, and getting better all the time, to help us turn that automatable example into an automated one.  Yes, maintenance is still hard.  Dale Emery has an excellent article on this topic.  We, as an industry, have far to go getting this difficulty under control.  I say, let’s work on it.

If we approach the development of the examples with the customer and in the terms of the customer, then we’ve accomplished the hardest part.  It’s worth spending the extra effort to put these examples to work preventing defects rather than finding them after the fact.

Agile requires the courage to make mistakes in front of others and the maturity to admit them when they happen.

Surely this is true.  Agile is all about paying attention to what happens and adjusting for it.  We learn most when when thing are a little off from what we want, we notice that, and we correct for it.

Brian Marick responded

I now think that Agile requires the creation of an environment in which admitting mistakes doesn’t require courage.

Surely this is also true.  If we want people to notice when things are a little off, so we can make a correction, then we have to make it easy to talk about our mistakes.  If we don’t, the little mistakes get swept under the carpet and we continue on our way–until the mistakes grow so big that we can’t ignore them any more.  By this time we’re way off the path we want.

In other words, well, in my words,

I think Agile requires creating environment where admitting mistakes requires no more courage than you have.

We can’t eliminate the need for courage to admit our mistakes.  It’s human nature to gloss over even tiny ones, and hope no one noticed.  But we can reduce the stigma of making mistakes.

How fascinating!

was the comment by Willem Larsen.  Willem and Evan Gardner are spreading Evan’s “Where Are Your Keys” language fluency game.  It’s expected that you’ll make mistakes when learning a language.  The response to such a mistake is “how fascinating” signed by raising both hands in the air.  Everyone laughs.  No one feels badly for making a mistake.  In fact, it feels good to share your mistakes with a laugh and helpful colleagues rather than to hide it inside.

Is that the way it feels when you make a mistake in your team?  What could you change so it does feel that way?

These are exciting times.  The tools of acceptance testing and behavior-driven development are progressing beyond the domain of the techies.  They are entering the realm where they can help the Whole Team.

Using these tools, or even better ones to come, the Three Amigos, Developer, Tester, and Business (and User Experience expert, and Manual Writer, and …), can invent their own shared language, specific to the system under development, to talk about what the system is supposed to do.  The acid test: that the Business representative feels comfortable reading the examples written in these terms and definitively say, “Yes, that’s what I mean” or not.

After the presentation, Uncle Bob Martin showed me the Given When Then capabilities he’s added to Fitnesse since I last looked at it last fall.  Other tools mentioned included Cucumber, SpecFlow, JBehave, easyb, GivWenZen, Morelia Viridis, StoryQ, and StorEvil.  I’m sure there’s more to come.  And, as we use these tools more and more, I’m sure that we’ll develop patterns beyond Given When Then and language specification tools beyond regular expressions.

Just remember, it’s not the technology that’s important.  It’s the communication between the Three (plus) Amigos.

Here’s a little cheat sheet.  Forget all the details and the various ways you can implement Agile for the moment.  Let’s simplify the picture.  There are just three essential legs that your Agile project needs to stand.  Get those in place, and you’ll do OK.  Keep improving all three, and you’ll do fantastically!

Arranging the work.

Know what is the goal.  Everybody should know this.  The “things to be done” should be fed smoothly to the development team.  Iteration cycles should respect the capacity of the team.  So should release cycles.  Doing these cycles smoothly will allow the team to maximize their capacity better than pushing for higher productivity.  Delay making decisions until they’re really needed, and make use of what you learn in the mean time.  Get the flow going and measure progress in real terms—working software.

Doing the work.

Working in iterations, alone, won’t get the project done.  The team has to do a competent job at doing the work.  If they had trouble delivering before, then better focus on shorter term goals may help, but you still have to work at it.  In addition, the sharp focus of short iterations and measuring working software makes it harder to sweep problems under the rug.  The team could look worse until they get a handle on things.  Set a high standard with your definition of done and keep to it.  This is the real capacity of the team.  Work to improve skills to increase the capacity.  Work to eliminate unnecessary work.

Working together.

An incredible amount of productivity improvements of an Agile team comes from the synergy of working effectively together.  Build a team, a real gelled team, not just a work group assigned to a project.  Support each other.  Help each other grow.  Leave no team member behind.  Solve problems together.  Respect each other.  Respect the differences, the special abilities, the varying perspectives.  These things give the team strength and resilience.

These three legs are enough to stand up a new Agile project.  Use these three categories to organize all those details we put aside at the start of this post.  Use those details to help you steady these three legs.  Experiment and practice until you feel you can succeed at each of these three aspects of your project.  And then keep improving.  Keep looking for things you can do better.  Keep re-evaluating.

It’s really that simple.  I won’t promise that it’s easy.

Usually in different phases, workload for tester and dev is different. E.g. when a project is coming to the end, most of the tasks will be test.

There are a couple of big red flags waving at me in those two sentences.  One is “different phases.” Why should a software development project, especially one only a couple weeks to a couple months long, have phases?  The other is, at “the end, most of the tasks will be test.” Postponing testing to a phase at the end has never worked very well.  It always results in the testers being behind at the end.

Does this situation sound somewhat familiar to you?  If so, what can we do about it?

Many teams try to live with it.  I’ve seen teams institutionalize “being behind” by implementing in one iteration and testing in the next.  When they do that, they generally find that problems are found in the testing, so the implementation really drags across two iterations.  The rework in the second iteration bumps new work planned for that iteration, so things continue to slide.  And since it’s hard to tell when a bit of work really is completely done, it’s hard to know how much work fits into an iteration and when the release will be ready.  Often things feel the same as they did before going to time-boxed iterative development.  That’s no surprise, because this really isn’t time-boxed iterative development.  It’s waterfall phases in sheep’s clothing.

Just don’t do it.  Get things completely done and tested before moving on to the next thing.

But how?  Don’t you have to wait until the code is written before you can test it?

No, you don’t.  Start when the product owner is describing what is to be done.  Distill that down to the essence of the user story.  Make sure that the product owner agrees that this potentially automatable distillation is what is desired.

Then, while the developers are hard at work implementing the functionality, the testers should be automating the test that verifies it.  To be sure, this is often something the testers, and the organization they work for, find unfamiliar.  It’ll go a little slow and shaky while you learn.  It’s completely understandable that testers will need some assistance from the developers as they automate the tests–after all, test automation is a form of programming.

The bottom line is that the story isn’t ready for acceptance until both the implementation and the test are done, and the test passes.  That’s the minimum, but take a further look, too.

Over time, this will get easier.  The testers will learn to do more test automation with less help.  The resulting set of regression tests will grow, giving quick feedback that functionality that worked before, still works.  Instead of the testers getting further and further behind as they continue to check the same functionality iteration after iteration, they’ll get further ahead because running these tests takes about the same amount of time.  They’ll have more time to do exploratory testing, and less of that exploratory testing will have to cover basic functionality.

It’s hard work to make automated acceptance testing a success.  In the end, though, it’s the only thing that can make testing a success in time-boxed iterative development.  If you don’t make it work, I guarantee the testers will get further and further behind.

One reasonable definition of good design is testability.  It is hard to imagine a software system that is both testable and poorly designed.  It is also hard to imagine a software system that is well designed but also untestable.

I greatly sympathize with this statement, though I wouldn’t go quite that far.  I don’t think it is so hard to imagine code that is testable, but poorly designed.  For a trivial counter-case, there could be rampant duplication of testable code.  I would call that poorly designed, but it doesn’t affect it’s testability.  Therefore I would soften Uncle Bob’s definition to “One reasonable component of the definition of good design is testability.”

To me, the notion of “testable code” is the same thing that “testable circuit” was back when I worked on a custom integrated circuit.  Mostly, that depends on the ability to put the circuit or code into a known state, exercise it, and see the interactions with its collaborators and its resulting state.

For ICs, the first level of making a circuit testable was to the internal state predictable and discernible.  Sometimes this was accomplished simply, by having the power-up state known, rather than random, and by being able to clock internal nodes into a shift register to be read out on an output pin in a special test mode.  That was enough to make it testable, but not generally enough to make it easy to test.

Being able to drive internal nodes to various known states gave a lot more power, allowing “unit testing” of various blocks of circuitry.  This generally required some additional hardware added just for testability (a point germane to the original question), but paid handsome dividends in reduced time to test units in production.

With ICs, much of the expense is in the packaging, and that expense was significantly related to the number of pins.  Testing equipment evolved to do the equivalent of “the bed of nails” used on circuit boards, but applied to pads on the circuit die that were never bonded out to pins.  This allowed easier access to internal nodes, both for driving state and for reading it, prior even to slicing the wafer into individual chips.  The heads that probed the circuit had a small nozzle to spray dye on failed circuits so they could be discarded before packaging.

With software, the ability to drive and access internal nodes is much easier–often not requiring any additional logic.  Sadly, many programs manage to make these internal nodes inaccessible, in spite of the lack of cost to do otherwise.

So, when I talk about testability, that’s what I mean.  And that’s why I quibble slightly with Uncle Bob’s assertion that testable code is necessarily well designed.  The converse is pretty easy to believe, but there are cases where, for no apparent reason, the design still sucks.

Well designed code, like well designed circuits, contain the complexity better and are therefore easier to adequately test.  This is, to me, an important point.  We’re very likely to miss stuff.  Let’s make it as hard as possible to miss stuff.  And let’s make it as easy as possible to notice when we’ve missed stuff.

In the words of C. A. R. Hoare,

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

Adam Sroka stated his discomfort with calling code testable unless it was, indeed, tested.  Again, I’ll be happy with a slightly lower standard.  It can be apparent that some code is testable even when not tested.  Generally, that code needs to be simple enough that testability can be obvious.  In most cases, though, code that isn’t tested is also not clearly testable.  To a first order approximation, both Uncle Bob’s and Adam’s statements ring true. I’m not terribly concerned with the absolute truth of either of them.  I do, however, prefer Michael Feathers’ assertion that there is a deep synergy between testability and good design.

That people could ask for, and could accept, the help they need and want.

The first thoughts that prompt ths response are the client inquiries I’ve had that didn’t really go anywhere.  Some of these, of course, had to do with money.  If the client couldn’t afford to hire me, and I couldn’t afford to work for less, then that’s one way that people cannot accept the help they want.

Even if I could afford to work for free, then it probably wouldn’t help them accept help.  People need to have some skin in the game to effectively make changes.  If I work for free, the best I can offer is advice.  And people usually ignore advice. It’s not consulting without the client indicating the value by paying something for it. (I once read a study that showed that free psychological counseling was extraordinarily ineffective, even compared to counseling that cost only a dollar a session.)

So, when a potential client calls me but isn’t prepared to pay (what I consider) a reasonable rate, I wonder how much do they really want to improve their software development organization.  Will they accept the need to slow down enough to learn new skills and behavior?  Will they be willing to do things differently, themselves, in order to reap the benefits they desire?  Often people want the quality and speed to go up, as long as they don’t have to make any changes.

Or they’re willing for other people to make changes. “Teach my developers to do Test Driven Development so they won’t ship bugs.”  This seems like a fine sentiment on the surface–Test Driven Development is, in my experience, an excellent tool for preventing the shipment of bugs.  But I have to ask myself, what’s keeping these developers from practicing Test Driven Development on their own?  If it’s lack of knowledge, then I can help them with a course.

Often there are other forces at play, however, that maintain the status quo even with new knowledge.  Perhaps the organizational culture frowns on people admitting that they don’t already know everything important.  Perhaps bugs, while deplored in words, are not given the same attention in actions.  I’ve seen rushing to ship take priority over shipping good code. I’ve seen heroics to fix a problem be given more accolades than preventing the problem in the first place.  Are people willing to change these behaviors so they may receive the needed help?

Of course, while it’s easy for me to describe these issues in others, I see the same difficulties in asking for, and accepting, help with the thinks I need, too.  I had the pleasure, recently, of working with Dale Emery on an engagement.  You may know Dale as the recipient of the Ward Cunningham Gentle Voice of Reason Award.  One of the things I truly love about Dale is his skill at asking questions.  And when he does, I’m frequently surprised both by the answers he receives and at my recognition, yet again, of my own tendency to make assumptions rather than seek and accept helpful information.

It’s not easy.  And that’s why it’s my wish for the day.

As is often the case, we must back up and take a larger systemic view to see further.  Once upon a time, people borrowed money to buy a house, paid it back over time, and ultimately the bank was able to lend that money to someone else.  With the creation of the FNMA (Fannie Mae) in 1938, the income streams of those mortgages being repaid were converted to bonds, so that they could be sold to other investors and the banks to re-lend their money more frequently.  This allowed many more people to afford houses.  In the 1970s, private banks got into the business of creating their own bonds based on debt repayment streams.

Nothing ever stands still, of course.  People continued to look for new wrinkles on these themes to allow them to expand the business, or to increase the profit on the business they had.  Some of these investment vehicles got very complicated, intended only for professional bankers who could understand and evaluate them where the mass public could not.  Or, so went the pitch at the time.

As it turns out, many of those professional bankers couldn’t fully understand and evaluate these instruments, either.  And this is in spite of reams of financial reporting about the quality of the underlying mortgages, the default rates, and other things that might affect the debt repayment streams.  No one has time to read the reams of financial reporting.  Instead, they simplify it, and boil it down to a relatively few values and ratios that they do read.  These derivative indicators became proxies for a real understanding of the risks and rewards of bonds based on mortgages.  And then there were derivative financial instruments based on the bonds based on the mortgages, and they had their own proxies for the risks and rewards.  I don’t know how many layers there are to this particular onion, but I do know that, at some point, the proxy measurements diverged from the real understanding of the risks and rewards.

Where have I seen this phenomena before?

I’ve seen it in businesses that couldn’t quantify the actual value of the software systems they were building, so they substituted the cost of building them as that value.  I’ve seen it in project managers who couldn’t quantify the actual productivity of their developers, so they substituted proxy measures such as “hours worked” and “lines of code” as an indication of productivity.  I’ve seen it in project managers who couldn’t quantify the actual progress of a project, so they substituted conformance to their original plan as a proxy.  And for individual items on that plan, when they couldn’t discern the actual progress on an item, they substituted reports of “percent completion” as a proxy.

All of this makes perfect sense at the time.  There is some correlation between lines of code and productivity.  And by using proxies that are quantifiable, we can crunch the numbers and come up with a few key indicators to let us know how we’re doing on productivity, progress, and value.  And we can calculate the amount of risk we have, at least, the amount that we’ve anticipated.  We end up with a handful of indicators that make us feel on top of things and in control.

And, like in the financial industry, as long as things keep going well, these numbers seem to work for us.  But we have no way of knowing how much and in what ways our proxy measurements vary from the things that really concern us.  And we have no way of knowing what risks are not included in our numbers.  And we have no way of knowing in what ways the future might differ from our increasingly successful past.

There were those who took a systemic look at the financial industry and predicted that trouble was coming.  As the system mutates over time, it rewards behavior that varies from what we really want.  The increase in that behavior then drives further changes in the system.  It’s a lead-pipe cinch that the future will differ from the past.  But looking at proxy measures won’t tell us that.

“The prudent mariner will not rely solely on any single aid to navigation, particularly on floating aids.”  This advice used to be printed on all US nautical charts.  It’s good advice for the prudent manager, also.  Proxy measures are like floating aids to navigation.  They only give an approximate position, as they drift around their anchor point.  And sometimes, unseen by us, the anchors themselves drift from the known location where we set them.  As we reward lines of code or hours worked, these measures drift further and further from a representation of productivity.  As we measure conformance to plan, then that conformance becomes more important and accomplishing the goals that the plan was created to accomplish becomes less immediate.  That conformance then becomes a poor proxy for accomplishing our goals.

So, look around.  Find some other aids to know where you are, and where you’re heading.  Don’t wait until it’s too late to prevent disaster.

Their claim seems to based on a mailing list posting in which I said,

I applaud your efforts to educate the “traditional project manager” in Agile techniques.  I hope that you are very effective in doing so.

• I did not say anything about their certification program.
• They did not ask me if they could use my words on their web site.
• They have fraudulently quoted me as if I have endorsed their certification.

I am all for education. I am suspicious of certifications. I am angry that I have been so misrepresented.

I consider this misrepresentation to be a sleazy trick. It give me the impression that PMAC is not to be trusted. I suggest that you be wary of them.