What is an Agile Coach?

Recently a friend asked about the definition of the title, “Agile Coach.” Googling “agile coach” informs me that there are about 205,000 pages with that term. Obviously the term is in widespread use.

I don’t typically call myself an Agile Coach, though I’ll use that term informally if it’s the term used by those with whom I’m having a conversation. Instead, I call myself a Software Development Coach. To me, the goal is developing software more effectively, not becoming Agile. Agile processes and practices happen to be excellent tools for effective software development, but lousy goals in themselves. Or so it seems to me.

This morning, I got a call from a recruiter looking for an Agile Coach for a client. They were a bit unhappy when I gave them my daily rate. “The client has a budget and will never pay that much.” When I asked what rate they were expecting, they said $50/hour, all inclusive.

I made more than that a decade ago as a contract programmer. I cannot imagine finding a competent experienced coach for that rate. I’m sure that you can find a body to sit at a desk, though. Is there value in that?

This low rate, and the fact that cost is a primary factor, but value isn’t even mentioned, makes me wonder about what this role of “Agile Coach” has come to mean to organizations looking to hire them. (Continued)

Losing Customer Focus

Southwest Airlines has long been known for two things: low prices and attention to customer service. Since they instituted the “reserved place in line” so I wouldn’t have to stand for a long period of time, I have come to check their website first, and only rarely look for alternative flights. Sadly, they’ve taken their eye off the ball. I suspect that the focus on customer service has been replaced by a focus on growth (given their in-progress takeover of Airtran).

Some months back, I noticed that their website had become bandwidth greedy with javascript doodads. This made it painfully slow on many hotel internet connections. They seem to have backed off from that a bit, but have now broken it in a way that prevents me from buying the ticket I want. (In addition, when I call the “Southwest Airlines Customer Representative for assistance” as prompted on the website, I find they no longer have enough to handle the call volume. I wonder if they’ve reduced the support, or if the call volume has increased, or both.)  There’s a lesson here about considering all of the important user stories when implementing new functionality, so it bears describing. (Continued)

Podcast: Acceptance Test Driven Development and the 3 Amigos

Also while in Las Vegas for the ADP/West Conference, Bob Payne and I sat in the Agile Philanthropy booth and recorded a podcast on Acceptance Test Driven Development and the 3 Amigos. This is the latest in a series of Tips and Advice podcasts that Bob and I have done.

A Lingua Franca between the Three (or more) Amigos

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)

Long term focus

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)

Defect Prevention

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)

Agility and Predictability

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)

A funny thing happened today

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)

Combined backlog for multiple projects

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)

Software Development is not a Commodity

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)