Agile development practices require a developer to be social. There's a daily scrum, pair programming, end-users on team, kaizen meetings and the like, all situations which require high social interaction.

I can agree with that. He then follows with these questions:

(a) Does Agile push developers out of their comfort zone to be more social, OR (b) Did Agile come about because developers want to be more social?

My answer is neither one; for me, context is the deciding factor in my sociability. Like many software engineers, I'm an introvert. Put me in a large group of people whom I don't know well, and I will clam up and try to escape as soon as possible. But if you put me in a small group of people I know well, I seem like the life of the party.

For this reason, I love working in an agile environment! I'm part of a small team who I know well and trust. I thoroughly enjoy interacting with my team. In fact, at my current job, I've taken on the role of social organizer and of helping others to form more personal relationships. My wife finds this role amusing since I'm pretty closed down in many mixed social settings with her.

Well, since I assumed my new role as QA Architect here at Borland, I've violated both those goals. However, the good news is that I don't feel either one has been a waste of time.

As for PowerPoint, I'm in the role of designing and implementing processes throughout the company, and PowerPoint is one of the tools in the box for that roll-out. Granted, some of the people who attend my presentations may still have my previous association, but I try to make my presentations as short, painless and useful as possible.

And sales and marketing folks. This morning, I spent over two hours in a meeting with representatives from sales, marketing and advertising. That meeting was also not a waste of time for me. Those folks are trying to figure out how to get the word out on how we've improved our own software development process (using agile) and changed our own tools to support those changes. I've been a big part of that process improvement, so the sales, marketing and advertising people were actually listening to me and others from R&D this morning.

Scrum dictates that each user story that a team commits to in a sprint should be complete at the end of the sprint, and the story’s acceptance criteria define what ‘done’ means.

Certain types of enterprise testing can pose challenges to this principle. Performance requirements, for instance, are often based on scenarios that transcend individual user stories.

Here is an example: the application under test supports two different user roles, and the performance requirements stipulate the required performance of individual functions when certain numbers of users of both roles are using the application concurrently. User stories A, B and C cover functionality performed primarily by one user role and stories D, E, and F cover functionality used by another role.

If the team implemented stories A, B and C in one sprint, the team would not fully know whether stories A, B and C meet performance requirements until stories D, E and F are complete and the entire scenario is run with all user roles.

Certainly, the scrum team can minimize these sorts of problems by changing the order in which they implement stories or other strategies. And the team gains a certain amount of value from performing partial tests, but fundamentally, enterprise testing poses these types of challenges, and scrum teams have to deal with them.

If the scrum team cannot work around this sort of challenge, then they should consciously acknowledge the challenge, figure out a compromise to agile principles or scrum practices in order to deal with the challenge, and specify the risks involved in the compromise. And most importantly, all of this should be communicated to the customer at the sprint review.

Using the example above, a portion of the sprint review would go something like this:

Here’s the challenge we faced: in this sprint we completed stories A, B and C to the best of our ability, but we cannot fully know whether these stories fulfill all performance criteria until we complete stories D, E, and F.

Here’s the compromise we came to: we have completed these stories to the best of our ability. We did as much as we can, short of the full performance testing scenario, to verify that the stories meet performance acceptance criteria.

Here are the risks involved in this compromise: It’s possible that the stories do not perform as well as expected in an enterprise deployment. But since the missing variable pertains to unfinished functionality, users will not be executing that functionality at this time anyway.

Here’s how we plan to address this compromise: we plan to complete stories D, E and F in the next sprint. At that time, we’ll be able to run the entire performance scenario and verify that stories A, B and C meet performance requirements.

At that point, the customer would be able to accept or reject the stories. However, if the team has been working closely with the customer from the beginning of the process, the customer should have known about the challenges and have worked with the team on how to address them. The risks presented at sprint review should not come as a surprise to the customer.

Anyway, while reviewing my proposed process with our company's agile evangelist, I realized that my proposed process works very well within the given constraints of our company, but that I had given no thought to questioning the constraints themselves. Most of those constraints are very much outside my control, but my coworker pointed out that there is value in thinking how much more my process could adhere to agile principles if some of those constraints were changed or removed, and then presenting that information to the people who do have the power over the constraints.

Without making this blog post a therapy session, let me just say that I think this ability to work well within given constraints goes back to my childhood. As I was growing up, there were many not-so-great aspects of my family life that I couldn't change, so my coping strategy was to excel within those limitations.

This inclination to make things work within given limitations served me well earlier in my career, when I was just in the position of implementing process. But now that I'm also in the position of defining processes for others, I need to keep this inclination in mind so that I can make an intentional effort to think outside the box.

I think there's a more useful question to ask: has a group understood and embraced the principles of agile or have they viewed it as just a set of practices to be adopted (e.g., short iterations, daily stand-ups, etc.)?

It doesn't do any good to tell a group, for instance 'To be agile, you need to do X' without explaining the principle behind the practice.

Unfortunately, this sounds like a group that doesn't grasp the principles of agile. I really feel for the tester who posted the frustrated message to the forum. He seems to be trying to embrace the principles with team members who don't see them too clearly.

I've found this question also to be useful in an agile team, but the dynamics are a little different.

According to British author Antony Jay, there are centuries of evidence to support the idea that small groups are the most efficient. In “The Corporation Man,” he talks about how humans have worked in small groups, usually five to fifteen people, as hunters and farmers for hundreds of generations.

But what I found most thought-provoking was one of the comments to the post, written by Michael Bolton:

It’s unusual to hear that the customer learned something and used the information obtained from creating the test. . . This is much closer to my view of what is really important about testing: discovering and revealing information so that people can make informed decisions. Most of the time, we hear about something different: confirming and validating information so that people can feel reassured knowing that last week’s tests are still passing this week. That might be reassuring, but it has enormous potential for self-deception. We need always to ask if our tests are helping us to learn, not just helping us to sleep.

I'll have to think about how sharing tests with customers can enhance quality.

As a QA engineer, unit testing has been one of the most difficult testing areas for me to deal with. As a non-developer and significantly poorer programmer than the developers I work with, I just don't have the skills to review unit tests myself. And because unit tests traditionally fall into the developer's task list--even though they are testing tasks--it's been difficult to motivate the developers to think like QA engineers in order to implement unit test reviews or other means of testing the unit tests beyond basic code coverage stats.

It seems like this sort of process improvement should be easier to implement in an agile environment, due to the team focus and to the softer separations between roles. But so far, I haven't had much success at fostering interest in delving into the types of issues raised in this article.

I'd love to hear how other non-programmers have helped to improve unit testing in their organizations.

In this post, I'll share some specific practices that we're working to implement.

This post outlines some of the changes that we're implementing in regard to the enterprise testing group.