Agile and AA

I just ran across a blog post by Tobias Mayer that compares scrum to Alcoholics Anonymous. Like scrum teams, AA groups are self-organizing with no formal leadership, and the participants of the group work closely together on a focused, shared goal. And of course, both AA and scrum require constant re-evaluation and change. Tobias goes into more detail in his blog post.
To extend this line of thought, I reviewed AA slogans and found many that would apply to scrum. Among them:

  • One day at a time
  • First things first
  • If it works, don’t fix it
  • KISS–Keep it simple, stupid!
  • Live in the now
  • Be part of the solution, not the problem
  • Decisions aren’t forever
  • Let go of old ideas
  • Change is a process, not an event
  • Courage to change
  • Principles before personalities

Conventional software QA engineers and agile

As I learn more about and gain more experience with testing in an agile environment, I’m becoming increasingly concerned about the suitability of conventional QA engineers in agile environments. Since agile methodologies stress that the entire team is responsible for testing and that as much testing as possible be automated, the QA specialist has limited usefulness on an agile team.
I still believe that agile teams need people whose primary interest is ensuring quality. These team members should be primarily responsible for some traditional QA tasks: recommending the types of testing that need to be performed, recommending and/or planning testing strategies, tracking that all the necessary testing is performed, etc. But on an agile team, not all of the test writing and execution itself is necessarily performed by these same team members.
So, what does this mean for conventional QA engineers?
When asked for career advice, I’ve always recommended that QA engineers become as technical as possible: learn programming languages, testing tools, etc. Quality assurance in an agile environment just strengthens the necessity of this recommendation. I don’t think it’s necessary for QA specialists to become capable of writing production code (though it’s helpful!), but a more technical QA engineer can work on a larger portion of the automated test architecture, test writing and execution.
I’m interested to hear others’ thoughts on this.

A social animal?

Jon Williams makes the following observation:

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.

Deconstructing my unofficial career goals

Some of my unofficial career goals up to this point included: 1.) never being in a position where I had to use PowerPoint on a regular basis, and 2.) spending as little time as possible with sales, marketing and advertising people. In the past, I’ve associated both those activities with pointless waste of time.
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.

What does ‘done’ mean?

Here’s a problem that I’ve been thinking about recently. I’d love to hear feedback.
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.

Inside the box

I’m really enjoying my new job as QA architect at Borland. One part of my job is to help some of our agile development teams in the US and Austria to form effective working relationships with our enterprise testing team in Singapore, and then, based on those teams’ experiences, to create a general process that other agile teams can use to implement the same types of changes. This is the enterprise agile testing initiative that I’ve referred to before in this blog.
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.

Enterprise Agile Testing

Sorry I haven’t posted in a while, but I’ve been pretty busy. My primary task at work currently is an initiative to help our agile teams work effectively with our enterprise test engineers located in Singapore. My earlier posts about this initiative (here and here) represent only some of my earliest thoughts. Since then, this initiative has really begun to come together as a strategy for doing enterprise testing in an agile environment. I’ll try to share more of my thoughts soon.

They think they’re ‘doing agile’

In my discussions and reading, I hear a lot of people declare that so-and-so group thinks they’re agile, but they aren’t really. I don’t think this type of either/or judgments are very useful–there isn’t really a checklist of criteria for judging whether a group is truly ‘doing agile’ or not.
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.

On the same page

Throughout my career as a QA engineer, I’ve used the following informal question as a basic sanity check: Does my gut tell me that everyone involved is on the same page? Do the developers, the QA engineers, the technical writers all have a common understanding of what they’re developing? Most of my jobs had no particular defined process, so this sanity check was particularly important.
I’ve found this question also to be useful in an agile team, but the dynamics are a little different.

Continue reading On the same page