George Dinwiddie’s blog

It has come to my attention that the PMAC (Project Management Association of Canada / Association de Management de Projet du Canada) claims that I support their certification program.  This is a lie.  I do not support their certification program.

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.

I’ve had numerous discussions with Michael Bolton where he makes the claim that scripted testing (whether via automation or a person following written directions) is not testing but checking.  He quotes Cem Kaner’s definition of testing: “testing is an empirical, technical investigation of a product, done on behalf of stakeholders, with the intention of revealing quality-related information of the kind that they seek.”  Running a script that validates certain desired behavior certainly fits this definition. (Continued)

Ever since I experienced the “Where Are Your Keys” language fluency game with Willem Larsen, I’ve been thinking about how to apply the concepts to learning other than languages.  One of the fascinating concepts I gleaned from this game is the separate dimensions of proficiency and fluency.  The proficiency scale that Willem uses is based on the ACTFL guidelines of Novice, Intermediate, Advanced, & Superior.  Willem gave a memorable colloquial description of these guidelines in relation to a party: (Continued)

A few weeks back, in a conversation with a colleague, I raised some issues that were important to me.  Well, I tried to raise them.

“Don’t worry about that.  Besides, I’m working on these other issues that are more important.”

That response reassured me–NOT! (Continued)

Since learning about them some nine years ago, I’ve found User Stories to be much handier for expressing what the system should do than the monolithic requirements documents I dealt with in the past.  User Stories have a number of advantages:

• They can easily be shuffled into a different order.
• You generally know (by the acceptance criteria) whether or not they’re done.
• They don’t contain a lot of duplicated or contradictory detail.
• The detail gets elaborated when it’s needed (rather than a long time prior, letting the details get out-of-date and/or forgotten).

I’ve created a two-page handout on writing and splitting User Stories.  I’m publishing it here in case it helps others.  And I would welcome any feedback on it.

My good friend, Steven M Smith, tweeted

AGILE methods emphasize realizing short-term OBJECTIVES rather than creating long-term objectives and trying to satisfy them.

I completely disagree with this statement.  I don’t agree that short terms objectives are the emphasis in Agile methods and I don’t agree that short term objectives are preferred over long-term objectives.  I think that Steve’s misunderstanding is rooted in the fact that he has only read about Agile methods, and not practiced them.  I think that it is impossible to get a deep understanding of Agile methods by reading without experiencing.  Therefore, I’d like to encourage Steve and others talking about Agile methods to try to get some experience before making such statements.  I’d also like to offer an explanation that attempts to clear up this particular misunderstanding. (Continued)

Another conference has come and gone.  I’m home.  I’m exhausted.  I’m glad to have good internet connectivity again, and time to sit alone with my thoughts.

I had a fabulous time.  Through conferences such as this one, I now have dozens of friends from around the world that I rarely get to see.  I really enjoy getting together face to face.  Missa vitussa se poro on. (I hope I’ve spelled that correctly.)  And I spent time with friends that I previously only knew from Twitter and email.  And I met new friends that I’d not known before.  All of that was thrilling.  (I also didn’t get a chance to talk with some friends whom I know attended. Life is like that.)

I attended some great sessions.  (Continued)

Jim Shore posted a nice Introduction to Agile for QA People on his blog.   I thought it was great as far as it went, but it didn’t explicitly mention some of the things that I have found to be extremely important, at least, in the corporate IT environment.  I tried to leave a comment there, but I was too long-winded for his comment system.  (If you’ve not read his post, please do so now.  I’ll wait.)  Here’s the full text of my comment:

Jim, I think you’ve left out, or under-emphasized, an aspect here.  It’s perhaps not explicitly called out in the XP literature, and isn’t mentioned by Scrum (neither of which mention the QA department as an entity), but it’s an important aspect in successful Agile adoptions in corporate IT environments, in my experience.  That aspect is Defect Prevention. (Continued)

From time to time, a discussion rattles around the internet about “how can you tell how Agile you are?”  Over and over, I see people tout some variant of the Nokia Test as a way to tell if you’re Agile enough.  For the most part, I think this is hogwash.

Don’t get me wrong.  I’m all in favor of an Agile Team using something like the Nokia Test (or, better, Nationwide’s “Agile Tea Leaves”) as part of a self-examination and retrospection.  But any sort of discussion of conformance to practices is way too low-level for the executive team, or even middle management, of an organization.  Agile is the tool, not the goal.  The goal is to accomplish the things the organization wants to do.  Agile is a tool to allow the organization to accomplish its goals more reliably and in a more timely fashion.

With this in mind, I thought about what a high-level manager wants from the organization’s projects and the process used to develop them.  How can this manager tell if the development staff is doing a good job, or could be doing better?  I came up with this Do-It-Yourself Project and Process Evaluation Kit that such a manager can use, no matter what process the organization uses for development.  I think it will also be useful for Project Managers who need to report upwards.  Report in these terms, not in the details of the development process.

And here it is: (Continued)

Thanks to Esther Derby’s amplification on Lining Up Priorities, I came across Tony Tjan’s blog posting, Four Simple Ways to Make Your Employees Happier.  Tony says,

There is a very simple secret to long-term employee loyalty and retention and it is not money, perks, or stock options. It’s giving them meaningful roles.

This is not an idealistic motherhood-and-apple pie dream, but rather a basic condition of human behavior and psychology that many businesses and leaders often forget: people are driven as much or more by intrinsic meaning as they are by extrinsic rewards.

This is, I think, a little-discussed benefit of the self-management that’s found on successful Agile teams–the employees are motivated by creating value rather than just by pay and perks.  People want to do well for you.  Give them an opportunity and an environment where they can do so.