Wayne Allen's Weblog

My big fear was that there would be several PMPs there who would want to debate me on the minutia of project management and why agile isn't any good because...

In fact I found an audience that wasn't really familiar with the basics of the agile approach. Most were aware of this thing called agile, and some had agile projects in their organizations. But only a couple actually had any direct knowledge.

The hour went quickly as I outlined the agile principals and took a few questions on metrics and adoption.

One lady was extremely surprised that agile software development actually mapped back to the SDLC concepts she already knew. This is a sure sign that either the agile community is not communicating with our PMP brethren or most project managers are so busy doing, that they aren't learning what is going on around them.

Generally speaking I enjoyed my time with PMI and there was some about me doing another presentation for a larger evening group.

Via Jeremy D. Miller

This post by David is hilarious (warning programmer humor...)

There was a great group at the SAO QA SIG yesterday. Thanks to the organizers, sponsors and WebTrends for the space.

There was a goodly number of people from the QA profession (not surprisingly), but yet a surprisingly large number of non-QA focused people. The majority were involved in some kind of agile effort directly or indirectly which is an interesting indicator of the spread of agile. It wasn't that long ago that the large majority were thinking about an agile project, not doing.

I like to have a lot of audience participation especially when there is a mix of experiences in the topic. After introducing the topic and going over some of the essence of agile I asked for the audience to give me topics they were interested in. Once we have a decent list I ask the audience to prioritize the list so we talk about the most valuable tings first, since we alway run out of time.

I got some of the typical questions that a QA audience asks, such as:

• Should everything be tested by the end of the iteration?
• Should testers automate tests (i.e. write code)?
• What about unit testing?
• What about regression testing?

However, the question that got bumped to the top of the list was "How do we build trust?"

This was not a question I was really prepared to discuss in an agile QA context, but upon reflecting a bit since then it does seem quite relevant, especially since I listed Trust as one of the key essences of agile. Additionally there were a few people in the audience that were really struggling with trust between functions (the perils of letting the audience set the agenda).

I'm not sure I gave the greatest of answers at the time, but have been thinking about it since then. I think I've boiled it down to a few things:

To gain trust, you need to give trust.

That is, you can't just demand trust from someone else if you are not willing to take the risk yourself.

To gain trust, you need to deliver on your promises.

In other words you need to be reliable. In my experience the only way to gain lost trust is to do what you say over and over again. Which leads to:

Trust is not earned quickly.

Try as we might, we rarely gain trust immediately. It is a long term project where we continuously prove ourselves trustworthy. The goal is worthy, as the more we trust each other the more we can eliminate fear, which leads to better cooperation, which leads to better results. Which is what we are all after.

Other articles on trust:

• Trust vs. Camaraderie
• When Trust Goes AWOL
• Developing Trust
• The First Thing to Build: Leveraging Trust on Agile Teams (pdf)