The family medical issue has been resolved happily, so I’m free to go back on the road. We’ve thus rescheduled the events I was supposed to do last month in Texas.

• On February 23rd I’ll be speaking at DFW Scrum in Dallas.
• On February 25th ThoughtWorks is organizing a technology forum in Austin.

As is usual for me, I haven’t planned exactly what I’ll talk about yet, but it’ll revolve around my usual topics of software design and agile methods.

Here's a common misconception about agile methods. It centers on the way user stories are created and flow through the development activity. The misconception is that the product owner (or business analysts) creates user stories and then put them in front of developers to implement. The notion is that this is a flow from product owner to development, with the product owner responsible for determining what needs to be done and the developers how to do it.

A justification for this approach is that this separates the responsibilities along the lines of competence. The product owner knows the business, what the software is for, and thus what needs to be done. The developers know technology and know how to do things, so they can figure out how to realize the demands of the product owner.

This notion of product owners coming up with DecreedStories is a profound misunderstanding of the way agile development should work. When we were brainstorming names at Snowbird, I remember Kent suggesting "conversational". This emphasized the fact that the heart of our thinking was of an on-going conversation between customers and developers about how a development project should proceed.

In terms of coming up with stories, what this means is that they are always something to be refined through conversation - and that developers should play an active role in helping that definition.

• spotting inconsistencies and gaps between the stories
• using technical knowledge to come up with new stories that seem to fit the product owner's vision
• seeing alternative stories that would be cheaper to build given the technological landscape
• split stories to make them easier to plan or implement

This is the Negotiable principle in Bill Wake's INVEST test for stories. Any member of an agile team can create stories and suggest modifications. It may be that just a few members of a team gravitate to writing most of the stories. That's up to the team's self-organization as to how they want that to happen. But everyone should be engaged in coming up and refining stories. (This involvement is in addition to the develpers' responsibility to estimate stories.)

The product owner does have a special responsibility. In the end the product owner is the final decider on stories, particularly their prioritization. This reflects the fact that the product owner should be the best person to judge that slippery attribute of business value. But having a final decision maker should never stop others from participating, and should not lead people astray into a decreed model of stories.

We decided to move the Notes from a Tool User blog out from Typepad to a Wordpress platform. From now on, you will be able to find the blog here – at agilepainrelief.com/notesfromatooluser.

You was probably redirected here from the old www.notesfromatooluser.com address which we will no longer use.

Don’t worry, you all the content from the original site is here and you old links will keep working.

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.

This site isn’t quite up and running yet and as such is in a massive state of flux. If you’re looking for Mark Levison – Agile Pain Relief Consultant – send an email to

Time for another update on my DSL book's progress, since I've not been writing anything else recently.

I had my first round of technical review late in 2009 and have been incorporating comments into the current drafts. Progress on this has gone well, in large part because travel is light this time of the year. I'm also integrating my book production process into that of Pearson's.

The next visible targets are a second round of technical review and the launching of a roughcut. We're hoping to get these going in the next couple of months. The roughcut will also allow people other than official reviewers the chance to throw rocks at the text.

After that the material will be gradually readied for production. We're going to use a much more incremental process than I've used before, which will be both good and interesting. My sense at the moment that we'll see a physical book on bookshelves by the final quarter of 2010. It's currently looking at around 500 pages total in a DuplexBook split 150/350

The material currently on my web-site was last updated in June. While I've done quite a lot of detailed work on the book since, the broad structure is pretty similar, so the website gives a reasonably good picture of the scope of content.

Sorry for the missing a week – I’ve got serious business site renovations going on stay tuned for an announcement in the next week or two (Note this is an estimate and not a commitment).

Jonathan Rasmusson offers the Drucker Exercise a simple way to get a team to gel at the start of a project. I think I might use this with the next team I coach to help break down those initial barriers.

The Mostly Free Detroit Agile Conference a great little conference in Dearbon Michigan (a bit far from Ottawa). Which leads to Matt Heusser: Conferences on the cheap – Matt offers ways of doing conferences for much less than the expected rate.

I keep on hearing about Continuous Deployment and while I think that most teams are not ready for this by a long shot – its one hell of a goal. Eric Reis introduced me to a great case study from Ash Mauyra. The downside of being an outside coach is I rarely get to see clients make it to this level. Usually they let go of their outside consultants long before they get to this stage. Way to got Ash.

Over at Cutter Jim Highsmith has some good reminders around Self-discipline and Self-organization. Short, simple and sweet.

A very large list of on line collaboration tools. Might be useful assuming that you feel you really need distributed teams (see Self Inflicted Agile Injuries).

Brian’s been paying us the compliment of taking our book seriously and working through our extended example, translating it to Ruby.

He has a point of contention in that he’s doubtful about the value of our end-to-end tests. To be more precise, he’s doubtful about the value of our automated end-to-end tests, a view shared by J.B.Rainsberger, and Arlo Belshee and Jim Shore. That’s a pretty serious group. I think the answer, as always, is “it depends”.

There are real advantages to writing automated end-to-end tests. As Nat pointed out in an extended message to the mailing list for the book,

Most significantly to me, however, is the difference between “testing” end-to-end or through the GUI and “test-driving”. A lot of people who are evangelical about TDD for coding do not use end-to-end tests for driving design at the system scale. I have found that writing tests gives useful design feedback, no matter what the scale.

For example, during Arlo and Jim’s session, I was struck by how many of the “failure stories” described situations where the acceptance tests were actually doing their job: revealing problems (such as deployment difficulties) that needed to be fixed.

Automating an end-to-end test helps me think more carefully about what exactly I care about in the next feature. Automating tests for many features encourages me to work out a language to describe them, which clarifies how I describe the system and makes new features easier to test.

And then there’s scale. Pretty much anything will work for a small system (although Alan Shalloway has a story about how even a quick demonstrator project can get out of hand). For larger systems, things get complicated, people come and go, and the team isn’t quite as confident as it needs to be about where things are connected. Perhaps these are symptoms of weaknesses in the team culture, but it seems wasteful to me to take the design experience we gained while writing the features not encode it somewhere.

Of course this comes at a price. Effective end-to-end tests take skill, experience, and (most important) commitment. Not every system I’ve seen has been programmed by people who are as rigorous as Nat about making the test code expressive or allowing testing to drive the design. Worse, a large collection of badly written end-to-end tests (a pattern I’ve seen a few times) is a huge drag on development. Is that price worth paying? It (ahem) depends, and part of the skill is in finding the right places to test.

So, let me turn Brian’s final question around. What would it take to make automated end-to-end tests less scary?

I’m afraid I’ve had to cancel my speaking events in Dallas and Austin next week due to a family medical problem. As I write this, it’s not clear how serious the problem is going to be, but there is a good chance that I won’t be able to travel to Texas next week. As a result we felt it was best to cancel the events, while we still have a few days notice. We do intent to reschedule as soon the as dust settles. My Texas ThoughtWorkers are very keen to have me come out and do these talks, so we want to do them as soon as we reasonably can.

My apologies for this, and I hope you understand. In particular I want to thank the various collaborators in organizing these events for being very understanding under the awkward circumstances.

In December Liz Keogh, Eric Willeke and Jean Tabaka finding themselves in Boulder at the same time got together at the Rally offices. In only a day they managed to draft a statement of the beliefs and respect. If we all agree to follow them and respect each other many of the rifts that have appear in the Agile community in the past year will start to heal (see the comments under Jean’s post: “Escalation” for examples of those rifts. Also see the Cutter 2010 predictions).

The statement is very simple:

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

• reflect and honor the practitioners who make its existence possible;
• provide an excellent experience for its members;
• support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
• exemplify, as a body, the professional and humane behavior of its members;
• engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
• embrace newcomers to the community openly and to celebrate ongoing journeys; and
• thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.

I would like to add to that an echo what Chris Matts and Olav Maassen have already said:

So what is the difference between Leaders and Leadership?

A leader feels like a commitment (something we only like if we have to):
“Do it this way if you want to be part of my club.”,
“My way or the highway”,
“You’re either with us or against us”

Leadership feels like an option (this is what we like as it allows freedom of choice):
“Here is a way you can do it, it worked for me in a certain context.”,
“You might want to check out X it seems related to what you’re doing.”

My goal is not to tell you who to develop software. My goal is to help you deliver great software and to challenge you to do more than you ever have before. Whether we use Scrum, XP, Lean, Kanban or some new technique doesn’t matter to me. What does matter is helping people achieve great things.

“Mark is a great person to have on the team, very knowledgeable on Agile /.Net, always happy to discuss best practices and make excellent recommendations. His ability to get down in the low level details added great value for our team. I highly recommend Mark as an Agile Coach.”

Roger Fortner, CEO, Secure Software Solutions Inc

“I was lucky enough to work with mark in building our Agile Unit Testing, TDD, and refactoring community. It grew in size to over 400. Not only does Mark have keen technical skills, a gift for explaining topics, Agile in his DNA, but what sets him apart is his ability to grasp and drive towards the right strategic direction. He was so key to our Agile/TDD group Some folks with Mark’s insight and intelligence are hard to communicate with. Not so in his case. He’s great to get along with, and speaks well. The good thing about working for a large company for 25 years is you meet a lot of smart people. That gives me the perspective to know that Mark was one of the best. I’m sure anyone who gets to connect with him will be benefit right away.”

Bill Krebs, Senior Agile Software Consultant, IBM

“Mark is very knowledgable regarding Agile approach, methodologies and engineering practices. His strong technical skillset and background provide him with a good mix for coaching and/or implementing Agile in an organization.”

Don Miller, Project Manager, Export Development Canada

“One of the greater rewards of moving up the ranks is the chance to work with extraordinary people. I had the pleasure of working with Mark on rolling out Test Driven Development to all of IBM. Mark is highly intelligent, knowledgeable, and has a great sense of humor. Mark’s knowledge of Agile, TDD, and his insights into education and organizational transformation, were all key to our team’s success. If you get a chance to work with Mark, don’t pass it up.”

Jim Brisson, Lead Agile Teacher and Coach, IBM

Where is the dead wood?

How can we get them to work harder?

Who are A/B/C players?

How can we trim the fat?

How can we make them (the developers and testers) go faster?

How can we cut costs?

I’m back in the saddle after having taking a couple of weeks off the internet.

This week we open with a pair of posts around TDD. First up Scott Miller of Atomic Objects ran a simple experiment: Faster, better, cheaper! TDD wins in a simple experiment and then earlier this year Mike (GeePaw) Hill wrote: How TDD and Pairing Increase Production a good explanation as to why it works.

Xavier Quesada Allue aka Mr Visual offers: Build a taskboard in 10 steps.

Not a blog post but a useful tool: Sonar from Codehaus may give a way of measuring some (but not all) of your technical debt.

Dean Leffingwell uses Little’s Law, Queuing Theory and Starbucks to show us why large backlogs are not Agile: An Agile Illusion: How That Nice Backlog is Actually Decreasing Your Team’s Agility

Anyone who has taken Agile Training from has heard my remarks about team size. Johanna Rothman gives us: “Ideal” Team Size and Ratios – I’m with her more 9-10 people on a team and you will get separate sub teams forming. On the subject of how many testers/writers does a team need? I like to start with one of each and add developers until they’re at capacity.

Richard Lawrence is chugging away and creating new versions of Cuke4Nuke – a version of cucumber that allows you write your step definitions in .NET: Screencast: Testing Web Applications in .NET with Cuke4Nuke and WatiN

Michael Dubkaov shows us why its a good idea for developers to have some slack time: Kanban Psychology. Can You Say No?

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.

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.

The world is slowly recovering from a major financial meltdown.  People blame the collapse on a number of different things: a bubble of inflated housing prices, relaxed requirements for qualifying for a mortgage, predatory lending practices, greed on the part of mortgage companies and investment banks….  There are certainly many places to point fingers.  Each of these places, however, was doing what seemed logical when looking at a small piece of the puzzle.

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.

• http://nodejs.org/ - Evented I/O for V8 javascript
• http://www.jaxer.org/ - Ajax server
• http://narwhaljs.org/ - Cross-platform, multi-interpreter, general purpose JavaScript platform
• http://commonjs.org/ - A group with a goal of building up the JavaScript ecosystem for web servers, desktop and command line apps and in the browser

The year we make contact with javascript as a platform in its own right?

Twitter has totally clobbered my ability to express any thought that requires more than 140 characters. Must get back into the blogging habi

Offshoring is frequently promoted as a way to produce great products for far less money. So many software development companies boast about sending large amounts of their work to India or China to reduce costs. Unfortunately in doing so they’re often reluctant to pay the price to create and maintain high performance distributed teams.

Agile works on the basis of a few simple principles:

• Short Feedback loops – which leads to iterations, TDD, …
• Radical Transparency – which leads to daily standup, demo/review, …
• Face to Face Communications – which leads to high trust, group problem solving, …
• Value – which leads to eliminating waste
• Continuous Improvement – which leads to retrospective, adoption of engineering practices.

Thinking back on every project that I’ve ever worked on (Agile or not) the quality of communications was a good predictor of the success. So when we run distributed teams there has to be a focus on making the communications work.

At best the typical approach to this problem is to buy web cams, fancy video conferencing software and conduct our meetings sitting in front of them. But that misses the point – these devices improve the quality of communications but not enough. They don’t build trust. To really build trust you have to meet face to face for at least a week. Unfortunately trust is weakened through the course of the year, so it has to be renewed. At a minimum team members need to visit each other twice a year.

So if you really want to get a high performing team – don’t underestimate the real costs, budget for travel – a minimum of twice a year to build and maintain trust. Don’t short change your distributed teams.

This edition of the Agile Quick Links is being brought to you from a hotel room in Santa Clara.

Matt Heusser takes on one of my favorite recent peeves with: The Fishing Maturity Model.

Gojko Adzic writes about a recent XPDay 09 session: Shock therapy agile adoption at 7Digital. The good news with this shock therapy is that no humans appear to have been harmed in the process.

High Performance teams (see: "The Wisdom of Teams" by Jon Katzenbach and Douglas Smith) is important background for Agile teams. In “What makes a true team” The Financial Post has effectively done a good job of summarizing Katzenbach and Smith.

Looking for good Lean games, I was reminded of the Theory of Constraints dice game: What is the Dice Game or Match-Bowl Experiment? (quick description) and The Dice Game(s) – better explanation and a chance to fire people if the dice don’t their way

Like clock work every 2-3 months someone on the Scrum Development mailing lists asks: “Can the Product Owner and the Scrum Master the same Person?”. Thanks to Boris Gloger we now have 10 reasons to say no.

We’ve all seen the results of individual rewards – pay someone to fix bugs – you will breed bug writers. Reward Firefighters (on a team) and you will get firefighters. Laszlo Szalvay wrote: Personal Heroics vs. Team Success.

Almost exactly three years ago I was trying to use David Allen’s "Getting Things Done" (GTD) system and I wasn’t seeing the benefits he promised. In the end I just found that it helped me thrash. I suspect the problem was more my focus than his system – but at end of the day his approach just didn’t resonate with me.

Today my system is a little closer to a hybrid of Mark Forester’s AutoFocus and Francesco Cirillo’s Pomodoro Technique. I still use MLO as my task manager but on a more granular level than I used to. Instead of slaving over MLO constantly now I use to help generate my list for the day. I use MLO to keep track of a large list of tasks. Mostly I just use the outline to remind of thinks I want to tackle. Daily I glance at the TODO view to make sure that there isn’t anything that is date sensitive that I’ve lost track of. Once it comes to committing to tasks for a day I often use Index cards using MLO, email and anything else as inputs. At the end of a day (sometimes two) I take anything that remains in the card and put into MLO. Then I tear up the card that’s probably the most fun part.

Other habits

• I sweep my tabs in firefox every few days and move stuff to reading lists in MLO.
• Once/Twice a week I go offline and go through my email.
• Once a week I take some time to reflect – what is going well; needs improvement; what need do I have the energy to improve; what one thing can I do next week to improve it. Aka a retrospective. This is the hardest one to maintain – because you’re tempted to skip it and get more "work" done. Yet its the most important because it drives real improvement.

I use the Pomodoro Technique for:

• a reminder to stay on task
• a way of doing rough estimation every morning

Also on a two monitor setup under Win7 I dock MLO on the far left and leave it in outline mode where I can always see other things I want to do.

Other tools I use: ClipMate Clipboard Extender – because it allows me handle more than one item in the clipboard and to clean (i.e. remove html etc).

I’m working with a client who runs a documentation team, so I was delighted to discover: HeraTech a  new blog dedicated to applying Agile to Techinical Writing.

Preparing for TEDxOttawa this past I saw a couple of great talks: Dan Pink on the Surprising Science of Motivation (hint individual rewards don’t work) and Dan Gilbert on Our Mistaken Expectations (he demonstrates that we’re really bad judges of value).

Henrik Mintzberg revisits Dan’s point to say: No More Executive Bonuses!

I love seeing Agile applied in interesting places and seeing how it adapts – so I offer you the Agile Lawyers Association – it seems like a great idea but the website needs a bit of work.

Michael Sahota visits one of favorite topics – Joseph Pelrine and “Coaching Self-Organizing Teams”. I wrote about this last year: Coaching Self Organizing Teams and Part II.

Finally Ilja Preuss gives a some great tips on keeping time in a meeting (Agile or otherwise).

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.

Michael says that checks “confirm existing beliefs” and tests “find new information.”  If a “check” that was passing now fails, is not that new information?

He says that checks are machine decidable, but tests require sapience?  I think that both require sapience.  It takes sapience to create the script. Michael admits this much in his posting, “Merely” Checking or “Merely” Testing.  He also admits that there is skill required in reporting and interpreting the results.

What he doesn’t mention is the action that might be taken in response to the results.  If we’ve got a failing test, then we might try exploring the application manually to see what’s going on. We might write some more tests to understand what happened. We might check the log files for information. We might call someone to see if other systems, on which ours depends, are working correctly.  We might do any of a large number of things.

And really, this is no different from exploratory testing other than in terms of the time delays between various actions.  In exploratory testing, we decide how we want to exercise the system, we observe what happens when we do so, and we use the information we gain to decide what other ways we might want to exercise the system.  We do the same thing with automated tests.  The difference is that there are delays between these steps (and we’ll likely do many of the “exercise and observe” steps before going to the “decide what to do next” steps).

It’s that “exercise and observe” step (and making a decision as to whether the observation is cause for concern or not) that Michael calls a “check.”  But that’s only a part of scripted testing, at least, if you’re doing it right.

To be sure, there’s great value in speeding up the cycle between observation and deciding what to do next.  And there’s great value in noticing things along the way.   There’s also great value in speeding up the time it takes to observe a lot of details.  And there’s great value in not forgetting some of those details.

There are other relative strengths and weaknesses between exploratory testing and automated scripted testing, of course.  And both can be done badly.  But both are testing, both in terms of Cem Kaner’s definition, in terms of finding new information, and in terms of requiring sapience.  If you’re not thinking about it, you’re doing it wrong.

This week I’m leading off with a pair of items on the Brain and recovering from challenging Cognitive tasks: Cognitive Recovery Time and A Dream Interpretation: Tuneups for the Brain (NY Times – login required). The first suggests that your brain needs some recovery time after doing something “challenged” your brain. The second reinforces the importance of sleep and dreams in integrating ideas and information. What this says for TEDx attendees next week – I’m not sure expect that we presenters will have to work hard to make our ideas stick. I also think its a bad sign for the typical two-three day Agile training course.

Joe Little shares his: Agile Principles – examples: all WIP is bad, bad news doesn’t get better with age, You learn the fastest by small mistakes.

Ilja Preuss says something that’s been on my mind for a while: Index Cards are Tools, too!

Johanna Rothmann tells “How Not to Win Friends and Influence People” – I’m only disappointed that she didn’t name names.

Finally Abby Fichtner reminds us: Agile Leadership: Methodology Ain't Enough

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.

There are still a few places left for the London XpDay, an event designed by practitioners for practitioners.

We’re trying the half-Open Space format again, with a day of prepared sessions (some promising experience reports this year) leading to a day of ad-hoc sessions. This means we can have a conference that’s more responsive to the needs of the attendees in the room—if I want to cover a topic I can propose a session.

And we have some interesting keynotes. Apart from Mark Striebeck, talking about scaling up some agile techniques as only Google can, we’re continuing our tradition of bringing in ”outside“ speakers to trigger discussion. We have Doron Swade (who built the calculating engine in the Science Museum) talking about Babbage, and storyteller Terry Saunders.

Nat and I will also be using the opportunity to launch our book in the UK.