Everybody wants to get full value for their money. I can pinch a penny as hard as the next guy, maybe harder. But I’ve learned in many ways and many contexts, the very things I do to get more for my money, often result in actually getting less. How can this happen? Read More
Jim Shore has posted a response to the reactions about his previous post on Acceptance Testing in which he defends the way he and the teams he coaches are working. About the same time, Lisa Crispin posted her thoughts on the topic.
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. Read More
Recently, Jim Shore wrote about The Problems With Acceptance Testing. I like Jim, and respect him a lot. Because of my respect for his opinions, I found it quite discouraging that he said, “I no longer use [automated acceptance testing] or recommend it.” Gojko Adzic has posted his response to Jim. This is mine.
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. Read More
Maybe you’re starting your first Agile project. You’ve read books and blogs. You’ve had training. You think you’re ready, but it’s still a daunting prospect. There’s just so much to remember—so many details.
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! Read More
Yves Hanoulle asks, “If you could change 1 thing today what would it be?” as the first question in his Agile Retroflection of the Day project. Today being the first of the year, it’s natural that I look back over the past year as I consider this question. And so I answer,
That people could ask for, and could accept, the help they need and want. Read More
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 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.
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: Read More
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! Read More
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:
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.
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. Read More