George Dinwiddie’s blog

There were a couple dozen people who showed up at the Fool, last night, for my presentation on A ”Lingua Franca” to Ensure You Get the Right System.  I’d like to thank them all for coming and for such lively participation.

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. (Continued)

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)

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)

I was reading the latest post on Johanna Rothman’s Managing Product Development blog.  In it she says,

Serial lifecycles provide a (false) prediction. And, boy oh boy, is that prediction comforting to your senior managers. “When will the project be done?” might be their most-asked question. Of course, a serial lifecycle provides a prediction that’s almost guaranteed to be wrong, especially if you use a project scheduling tool. The tool provides you a single-point estimate, which is the first date you can’t guarantee the project won’t be done by–the first possible, optimistic date.

I like that characterization of the predicted date.  Another characterization, usually true of serial lifeycles, is that the predicted delivery date is the first day of schedule slip.  I’ve seen many serial projects get almost to that date before they first admit that they’re in trouble. (Continued)

I applied for a new credit card. I wasn’t in the market for a new credit card. I shred credit card offers almost daily. No one sent me an offer that I found too irresistible. No, the funny thing is that my current credit card bank spent money and went to a lot of trouble to convince me to open an account somewhere else.

It sounds very odd, doesn’t it?

Now I happen to know that this particular bank has worked to embrace Agile software development. I know people who have worked with them to do so. And I’m sure that, considering the size of the organization, they’ve made great strides in improving their software development practice. Yet the events that transpired today tell me that they’re missing an important feedback loop–arguably THE important feedback loop–the one that involves the customer.

Here’s what happened: (Continued)

Our teams sometimes have multiple projects. I am wondering what is the best way and what is the SCRUM way of handling this. My feeling is that the best way is to have a single backlog per team (even if this means that in a sprint the team is working on backlog items belonging to multiple projects). I think the purists will recommend splitting the team and having multiple backlogs.

That’s what Gilad Gruber asked on the Scrumdevelopment list. This question reminded me of a client I once had. (Continued)

Esther Schindler, a senior editor and columnist at CIO.com, recently asked on the agile-testing yahoogroup,

If you could get the (client) boss(es) to understand JUST ONE THING about computer consulting and contracting, what would it be?

It would be that software development is not a commodity. The cost-value equation is not just enhanced by cutting costs, but more effectively, by enhancing value. It’s not just a matter that software is produced, but what software is produced. Does that software clearly express the nature of the business? Is it an asset that can be extended and adapted as the business grows and changes? All too often, the only measure applied seems to be the hourly cost of the software production (neglecting even the number of hours required). Too often I get the feeling that I, the consultant, pay more attention to the long-term value to the company than do the employees and executives of the company. (Continued)

There’s a thread on the Extremeprogramming yahoogroup attempting to define Agile. John Roth started this thread with a trial balloon of ways to recognize an Agile project from easily observed practices. I have a bit of difficulty with this definition; I think that it’s too prescriptive and, while it could be a useful heuristic, would miss the mark in numerous cases. To my mind, it doesn’t zero in on the heart of Agile practice.

So what is the heart of Agile practice? In the ensuing discussion, Dale Emery posts a message the turns attention to feedback.

The whole team focuses intensely on producing accurate, relevant, timely feedback about product, project, and process.

I’ve written about the importance of feedback, before. Using feedback is not the defining aspect of Agile, of course. Using feedback is the basic mechanism for any control system. (Continued)

Over on the ScrumDevelopment yahoo group, a ScrumMaster reported problems getting the Product Owner fully involved in the development process. Part of the problem is that the Product Owner isn’t co-located with the development team. The physical distance will certainly make participation more difficult, and less sure. That’s something to work on.

The Product Owner is not following the “rules” of Scrum, and this is frustrating the ScrumMaster. He’s likely right that playing the game by the rules will benefit everyone. He asks for advice on how to handle the situation. (Continued)

What got me thinking about the construction analogy with software development was a recent conversation I had with a design/build contracting company. We’re in the market for a new house. We sketched our design (which we’ve worked on for quite some time) and wrote up a list of general assumptions about level of quality and some details that we wanted. We sent this out as a letter to a bunch of builders.

That sounds somewhat like your typical business requirements document, doesn’t it? It’s too detailed (specifying implementation details) while simultaneously failing to mention important points. But it’s a starting point for conversations. (Continued)