Agile Sprint Sanctity Valued at Over $13M?!?

During STPCon last week (which, BTW, was fabulous, but more on that in another post, 'cause I've got to get this off my chest) I was a panelist for The Hard Stuff: Questions About Agile. During the course of the discussion, someone asked a question that I heard as the following:

"... but what should I do about our sprints getting messed up when [executive] comes in and tells us to stop what we're doing and add [feature X] before the end of the following week so s/he can finalize the $13 Million deal with [new client Y, but only if the feature X is implemented by then]..."

A Context-Driven Approach to Delivering Business Value

This is Part IV in a series of entries inspired by the following quote from the "about page" of context-driven-testing.com hosted by Cem Kaner:

"...However, over the past 11 years, the founders have gone our separate ways. We have developed distinctly different visions. If there ever was one context-driven school, there is not one now..."

And James Bach's blog update (Context-Driven Testing at a Crossroads):

"I’m the last of the founders of the Context-Driven School, as such, who remain true to the original vision. I will bear its torch along with any fellow travelers who wish to pursue a similar program."

If you haven't done so already, I recommend starting with:

• Part I: Is Testing Dead? Dunno, but the Context-Driven School Is 
• Part II: With the Context-Driven School "closed" what's next?
• Part III: Context-Driven School (of thought): "I'm not dead yet... I feel happy!"

---

So far I've established that I'm a Context-Driven guy. For completeness, I should also share that I'm a guy who is most comfortable operating as part of a healthy team that embraces Agile principles, but who recognizes that Agile is not the most appropriate or effective answer for all organizations, teams, or situations.

I've also noted that I find the notion of "product" in both Context-Driven and Agile principles to be too subtle of a reference to the fact that the propensity of software is developed in a business context for my tastes. This is mostly due to many, many personal observations of individuals involved in the process of developing and delivering software emphasizing some aspect of the software over business value -- from individuals who self-identify as Context-Driven, Agile or neither.

The reality that I have lived in since beginning my career as a technologist is that, business is the primary context-driver behind the development of the propensity of software and that money is the primary context-driver behind business (yes, I know, that's a broad generalization, with somewhat ambiguous qualifiers -- I'm going to ask you trust that I'm happy to support and specify that statement if needed, but for the time being, please accept the premise... at least while reading the remainder of this post.)

Context-Driven School (of thought): "I'm not dead yet... I feel happy!"

This is Part III in a series of entries related to the following quote from the "about page" of context-driven-testing.com hosted by Cem Kaner:

"...However, over the past 11 years, the founders have gone our separate ways. We have developed distinctly different visions. If there ever was one context-driven school, there is not one now..."

If you haven't done so already, I recommend starting with:

• Part I: Is Testing Dead? Dunno, but the Context-Driven School Is 
• Part II: With the Context-Driven School "closed" what's next?

---

Ok, so maybe not "happy" but I couldn't resist the Monty Python reference.

James Bach stated on his latest blog update (Context-Driven Testing at a Crossroads):

"I’m the last of the founders of the Context-Driven School, as such, who remain true to the original vision. I will bear its torch along with any fellow travelers who wish to pursue a similar program."

Is Testing Dead? Dunno, but the Context-Driven School Is

Well, I'm sure this is a bit of a shocker for many of you, but the following quote comes from the "about page" of context-driven-testing.com hosted by Cem Kaner:

"...However, over the past 11 years, the founders have gone our separate ways. We have developed distinctly different visions. If there ever was one context-driven school, there is not one now..."

This is Part I of a series of entries on this topic. Links to subsequent parts will be added to the bottom of this entry as they are posted.

---

Of course, this doesn't  negate or erase the Context-Driven Principles, and Cem has committed to keeping the original content on landing page of the revised site:

"...When you land on this site, you see the context-driven-testing.com landing page (the Principles) as it was when we originally published it. I’ll keep it that way (with the same set of Principles), because several people have found it useful..."

To my way of thinking, the *most* important point made by Cem on the About Page is the following:

..."This notion of evolution comes with a built-in assumption: If my thinking will evolve to something else in the future, it must be wrong today. Progress on my path to better understanding and practice of testing (and of anything else that I’m serious about) includes discovering what needs to be changed in my thinking, and changing it.

This is an important aspect of science. We don’t run experiments to confirm what we already know. We run experiments to prove that what we think we already know is wrong. And to help us develop something better..."

This is the point I'd like folks to focus on.

Testing vs. Checking ... my 2 cents.

I was pleased to see Michael Bolton's series on Testing vs. Checking. If you haven't been following, what I consider to be the central thread of the topic (and the unfortunately inevitable fallout that seems to happen in "testerland" almost any time someone says something that makes sense).
From Michael:

• http://www.developsense.com/2009/08/testing-vs-checking.html
• http://www.developsense.com/2009/09/transpection-and-three-elements-of.html
• http://www.developsense.com/2009/09/pass-vs-fail-vs-is-there-problem-here.html
• http://www.developsense.com/2009/09/elements-of-testing-and-checking.html

From James Bach:

• http://www.satisfice.com/blog/archives/358

From Scott Barber:

• http://www.perftestplus.com/resources/014PeakPerf.pdf Original, ST&P Magazine, 2005
• http://www.logigear.com/newsletter/investigation_vs_validation.asp Reprinted by Logigear, 2007

How to Ask (and Not Ask) for Free Consulting

James Bach has posted a great blog about how to and how not to ask industry leaders for assistance.

http://www.satisfice.com/blog/archives/70

This rang true with me and my experiences, but some folks seemed to find his perspective to be arrogant or rude. Below I've copied a representative quote and my response.

But the way he handled it, and because I know that James Bach is a very experienced person in answering forum like questions, it looks as if Bach planed it all and maneuvered the poor guy to this corner, maybe to show him how he should behave. The way Bach handled it is IMHO was one of the worse that I have seen. Instead of getting healthy results (the guy understands his mistake, apologizes and learns from it) it looks like Bach did what ever he could to insult the guy in order to get that kind of reaction. I can learn a lot from James Bach but I am not going to take this approach as a good example to learn from. As Linda said, it doe’s him no credit. 

I have to disagree. I admit that I consider Jim to be a close personal friend. I further admit that my first impression of James Bach was that he was a pompous ass. It was only after meeting him that I came to absolutely adore conversing with him for all the reasons that can be taken as "pompous ass" to anyone who approaches him with defensiveness and self-righteousness.