Diary of a Soccer Coach: Week 1 - Getting the Players Attention

As I enter my fourth season as a Soccer coach, I can't help but reflect back on the previous three years.  There have been a lot of kids I've had the opportunity to work with.  The prior three years I coached the 'instructional division' as it was first called to me.  In essence I've had the honor of coaching up kids ranging from Pre-K  through Kindergarten age.   I've coached the same level for three years now, and again this year I am stepping up to do the same.

In some ways its hard to be a coach to the youngest in the league.  Some of them are already quite athletic, but lacking in coordination, some are squeamish about falling down, or running into someone else.   Some don't quite know what to expect from this their first athletic endeavor.   It isn't always easy on the coach either.  Sometimes we just barely get a season to get to know the kids before they begin to bloom and are ready to play up to the next level.  Some only get the one year, then are moved up with the other kids their age.   In essence each season is like starting over fresh.  There are always a few faces you remember from the previous years, and you may recognize the growing boys and girls practicing on a field not too far from your own teams, but your focus is now on the next group.

For companies like my current employer, where professionals might work on multiple projects, or bounce  between roles and wear different hats within or between teams as the needs become evident, to a team leader, it can seem quite a challenge to start from scratch with a team.  It can also be a challenge to get the new people involved and fully engaged and invested in the project.  

For the first session of the Soccer season as with any team, it is imperative to set the ground right.   The first practice always starts with a quick introduction and brief overview of the most basic rules of soccer.  Then we quickly transition into a couple of warm up exercises.  They aren't typically long exercises, but are designed to get the players moving, loosened up, and in the mind of being at practice.  Warm-up exercises could be great for team building, or for helping to transition a new team member into being part of the esprit de corps.    Having transitioned to several projects in my career, I feel that many of these warm up exercises did a lot to help smooth my transition into the team.

Of course, practice does not end with these warm-ups, nor should it be the end of the team building process either.  As Michael Larsen (@MKLTesthead) so eloquently put in describing the stages of team development in his emerging topics talk on teams and the EDGE method employed by the Boy Scouts of America - The team is still forming, here, it hasn't even begun to play soccer, nor has the new team or hire really progressed to a state of being fully in tune with the team's software development process.

So the next step of practice, is the first of many drills.  For soccer in the introductory division, the most basic of drills typically involves dribbling, around a pair or square of cones, emphasizing technique for controlling the motion, the tempo of the dribble.  For software teams, tempo, and pace are something that teams struggle to achieve, and hold once they have it.  The same is true for Soccer, and our instructional division is no different. The secret you see to these kids, and I'm betting many other youth organizations, is to keep the meeting or practice as active as possible.   

So we run them through a drill for five, maybe ten minutes, and then may start another.  This gets the players used to moving around, and focusing on one type of task or another.  However, at some point the kids need a break, so we give them a bit of time to run to the restroom, and get a drink before having our mid practice huddle.  More on these huddles in a later entry, but suffice it to say, the kids almost without fail come back refreshed, and ready to do more, but it is still the First practice, and i its important to temper our expectations with that in mind.  

With software teams, the same is true.  Each member needs down time to assimilate lessons learned, to rest from exertion of the mind, and for testers, to de-focus or refocus on whatever the next task may be.  Without this crucial down time, tasking begins to run right into the other so quickly that one may begin to lose sight of where one testing objective ends and the next begins.   It also presents a danger, because as creatures of habit establishing routines that are unhealthy will inadvertently result in inattention blindness, and as tempo and feel for how the project flows is learned, the risk increases that things move at a certain pace simply because they've always moved at that pace, whether the process or project are really at a achieving and sustainin velocity or not.

For my players in their first practice of the season, I see them in the scrimmage we typically run at the end of each practice.  They chase the ball without any rhyme or reason, with out any strategy or objectivity.  They believe the goal is to get the ball, and that to do that they must run to the ball.  There's just one problem.  someone else has that ball, and is accelerating in a different direction. so each player changes their angle to try and chase the dribbler down often from behind.  

At times it can look like  a swarm of honey bees, buzzing to one corner of the field, then changing course and quickly buzzing to another all around and trying to catch the ball each time, and inevitably these kids will trip, fall, or bump into another.   We haven't yet taught these kids how to move laterally, or even backwards when necessary, nor have we shown them the strategy of picking a place between where the ball might go to cut it off, rather than trying to chase it as if chained to the player with the ball like a rail car.  Inevitably the first practice always looks like this.  The older kids may not run into this scenario, as many have years of soccer under them by the time the season has started again, but for these new boots to the field of play, or to their team in the software world, they're a blank slate practically and in need of mentoring and guidance.  

The question you have to ask, is how can I influence them for the better, and help them see their role as more than just chasing the ball, as chasing this bug or that bug, when they may be leaving square feet of the field uncovered that could give them an advantage?   For me, it is important to remember that this is the beginning of a long journey we take together, and for better or worse we are here as part of a team striving to create that which our client needs.  However, even us experienced software professionals can occasionally trip over someone else's toes and fall flat if we aren't careful.  So trod carefully in those first days on a team, until you have a good picture of the terrain you must climb.

Today, I Choose Yellow

Sometimes the smallest things can be inspiration for test ideas.  Sometimes they make you sit back and pause and consider.   After enjoying a nice lunch with my family, my wife presented me with a colored page of Dora the Explorer, with my daughter's name and the date on it.  I took it to work and proudly displayed it on part of my cube wall.   I examined the picture and considered how she had gone to work coloring it.  Now she's not even two years old yet, so staying within the lines is not something I'd expect from a soon to be two year old.

However, two things jumped out at me.   For this page she had chosen a single color: Yellow.  It wasn't any particularly stark or bright shade of yellow, just a plain almost mustard color.   So then I began to think, why Yellow?  Dora isn't blonde, she has brown hair.  Her shirt is usually pink, and she wears orange pants.  Her backpack is a shade of magenta or a light lavender.  So there isn't a lot of Yellow there to work with as inspiration as far as I could tell.

So when I ponder why she selected those colors, as a Tester, the initial thought was that she had a reason for choosing that color.  I wasn't present when the picture was colored, but when I think back to the beginning, of other pictures she has colored, then the reason becomes clear.  My little one you see, isn't logical yet, her mind not quite fully developed.  She's bright and smart, charming even in her own way, but she's not even two yet.   More than likely she chose the color yellow because that was the first crayon her hands came around, and then, instead of changing colors for different parts of the picture, she continued until her mind felt she had colored as much as she dared too, and then moved onto something else.

How many of us as testers and software professionals do that?  How easily do we grab a hold of an emotion or an idea in any particular day and then view and work the entire day as if through that color whatever hue it may be?  Does that emotion and idea affect everything we do that day?  Do we let it bleed into our code, our testing, or our conversations with others?  When they look at you that morning, will they see the color yellow?

I learned from a book "Anger is a choice", that many emotions, anger in particular, are neither negative or positive.  It is how we react when those emotions come up that determines how we are viewed.   How many of us as Test or Software Professionals have encountered something, maybe it was minor at some point and we let it go, but it nagged at us.  As much as we tried to ignore, or deny this one thing, there it was the color of red, that our mind didn't want to ignore.  At some point, do we then find our focus so deeply on the color that we begin to see everything as if it was tinted that shade?

There's a danger here for Testers.  When our reaction and emotional make up begins to bleed through into our work, into our analysis and observation of systems under test, there is the possibility that it could lead us astray.  It could cause us to miss something that we'd see if our attention were not partially focused somewhere else.  It could cause us to react reflexively to something someone said that was intended in all good fun, or perhaps to help us with something with which we are grappling.

It's important I think to remember that Testers, like the clients for which we test software, are emotional beings as well.  Maybe our clients will see red when this one really annoying malformed feature crops up again and again.  Maybe they've ignored it thirty times through the application, then one day, when their emotional system is already spent from something that happened on the way to the office, or at home, and bang that one annoyance becomes the lit fuse that sets them off.  Ever know any people like that?  Ever had a client like that?

Now let's turn this on its head.  Maybe there's some issue, some flaw, that the team doesn't really classify as a fault in the software, some piece by which something is not as correct as it could be, but in your mind you, or the team in general have decided that's not important.  It's a minor, non-critical issue, and why would a user care if the time and date are displayed in YYYY:MM:DD form vs DD:MM:YYYY form?   Maybe on a normal day they won't, but do we ever consider how emotion on the part of the client, may play to what bugs they see as critical or important?

Furthermore, do we as Testers always try to enter into our testing sessions with as blank an emotional slate as possible?  Do we try to be like the Vulcan's of Star Trek utterly devoid of emotion, and creatures of pure logic for the duration of the test run?   If so, why do we do this?  Do we think a user will view the software with such a dispassionate view of how it works?

If, like me, you have ever had the chance to work the support lines for a company, then you know what I mean when I say that the customer has a personal way of dealing with his or her own emotions.  They may be struggling to get the software to perform, maybe they've had training and have used it successfully in the past, but one little nook, one little detail escapes them as they are partially distracted by some emotional atrocity they have endured this week.

Michael Bolton, no not the singer, or guy from office space, gave a keynote talk at the 2011 Conference for Association of Software Testing.  Michael talked at length about the history of testing, and at one point described how decisions on quality are "both political and emotional."  Another tester there, Michael Hunter (@humbugreality) in one of the emerging topics or lightning talks also talked about the 'emotional tester'.  I was able to follow some of these talks online, and I can't give enough kudos to the organizers of CAST and the hard working volunteers that worked to have those talks and the keynotes available online for those of us who were unable to attend.

How much role does emotion really play in our craft?  Do we allow it to simply be, to drive our assessment, to harness, or control it?  Do we inject it intentionally to see how it may color our opinion of an interface, or to see how our perception changes when our mood has changed?  Those are questions I'll probably ponder for a while.  It's funny how something as simple as a colored picture of a cartoon character by my youngest child could bring me back to contemplate these ideas in testing, but then maybe these ideas have been buzzing in my head since I first heard them, just like the color yellow.



(Edit: Thanks to Justin Hunter (@hexawise) for remembering it was Michael Hunter who gave the emerging talk on "Emotional Testing""