Expertise, Skills and the Whole Team

I am not a "major name" in software testing, or Agile or, software anything.  I'm OK with that.  I would rather focus on things local to me and get people to see there may be a better way.  Of course, without being a "major name" that, too, presents problems.

This may cause me some problems among my colleagues in the Agile community.  It may ensure I don't speak again at another Agile conference.  Then again, it may serve for someone somewhere to consider some of the truisms that get bandied about when it comes to Agile development.

An Open Letter to Those Espousing a "Whole Team" Approach 

Dear Respected Colleagues,

Over the last several years, I have heard and read many instances and places where people are citing this authority or that authority over the need or lack of need for testing specialists in an Agile Team.  Many denounce the concept as being counter to the "whole team" approach (since everyone is responsible for "quality"), others cite examples of how their projects did just fine without people with determined, specific roles and responsibilities.

Everyone can help with everything.  Everyone can contribute to everything.  Everyone can help anything better,

Yup.  Agreed.  When there is a shared vision and understanding of the point of the application, the reason why the project is being undertaken, people working together can do wonderful and amazing things.  It will be beautiful.

As long as we get it right.

"Right" in this context, is not meant to be anything other than whatever measures we choose to determine success are met or exceeded.  Of course, if we have rubbish measures for success then our "successful project" will still be rubbish.

This works fine as long as the context we are working in allows for people to adapt their views to accommodate the needs of the project and the organization at large.  For larger companies, where software is not their primary concern, this can be problematic. 

When there are large systems the new product must integrate with, it is probably a good idea to actually get information from the experts on those systems that our new system will need to work with.  We must realize that some skill sets may not be contained within the team.

Enough Chicken and Pig 

I can hear the roar already - "But that's the whole chicken and pig thing, right?"  Wrong.  There are people who may be able to assist us in our efforts.  We must recognize they have other priorities.  We must recognize that for them, we are just another request for their expertise.

We may want to do X all that we can possibly want in sprint N.  And if we need the help of some specialist outside of the team, we may not get it when we want it.  Someone needs to contact these external (to the team) experts and figure out their schedule needs, the kind of lead times they typically need for service requests and what kind of information you will need to provide, and when.

I know it is cool to run as clean as possible - as little overhead, plan then work/code right now.  The problem is, if we need people to wield their magic sauce, right now may have had to be planned a month ago.  It does no good to rant and rave if they are running at capacity and can not get to our project when we want them to if we have not done our homework.

A lack of planning on our part is not their problem - it is ours.  And it has nothing to do with who is all in or not. 

Essential Skills

The obvious solution is to engage said experts from the outset of the project, no?  Get them or their boss or some other proxy the information you have for what they will need to do as it is developed, no?  We may get one piece in Sprint 1, possibly as a note that when you get to Story M there will be help needed from Group Q on some feature.  In Sprint 3 we may have a little more information on this.  Make sure it is recorded, possibly passed on, and then made available when Group Q can do their bit.

Simple, no?  It is part of recognizing that not everyone is skilled in some technique needed to ensure the project is a success.  Pretty basic.

It also recognizes that some people have skills that are anything other than ordinary.  It recognizes that some skills are not (yet) considered commodities to be picked up with an hour or two of training or that "anyone" can do.

Why do we presume that others skills are not that way as well?  Sure, we can do some things - we have some shared skills on some level.  Frankly, I would not trust any code I wrote in Java or Java Script to run correctly in production.  What little skill I once had is now quite rusty.  What about the business owner or business representative?  Can they write production quality code?

Some may be able to, others likely consider it magic.

Recently I encountered someone who asked why I was spending so much time on one page in their really simple app when, to them, things looked "fine."  My response was to show her the list of odd behaviors I had encountered simply by flipping back and forth on the elements on the page and leaving and returning to the page.  She stopped and blinked.

Wow. I never would have considered looking at any of that.

That, my dear colleagues, is why a person skilled in setting aside expectations of how the code behaves, expectations of  how the person using the program behaves, confidence in the ability of the team to match code development and business expectations and needs and look at what is.

It strikes me that an awful lot of people read an article or a bit of a book or hear a snippet of a conversation and figure that anyone can do this.  It is challenging.  It takes courage of convictions to not give in to political or other social pressure.  It takes perseverance when everyone around you claims something is easy.

I call people who have those skills "testers".

Yes, everyone is responsible for quality of the software.  The whole team.

It takes specialized skills people may or may not have in varying degrees to make that software more than an idea.  Among those skills are those typically found in a person who has selected software testing as a profession.