Friday, November 4, 2016

Adventures in Empathy - Simulating mild vision loss with the Cambridge Inclusive Design Toolkit

Last year, I spent a fair amount of my presentation time talking about ideas behind Inclusive Design, and how the both enhance and help contribute to performing Accessibility testing. One of the resources I suggested was the Inclusive Design Toolkit developed and used by the University of Cambridge. In addition to a wealth of information on their site, their methods go beyond software. Since they test numerous physical items, they do not rely on software tools only but have actual physical tools that you can use.

One of those is their Cambridge Simulator Gloves. These are rigid pieces of flexible plastic that can be adjusted to simulate a variety of physical issues with hands (e.g. rheumatism, arthritis). These are seriously cool pieces of kit, but they are pricey (£155 per pair, which is at this writing close to $200). Less expensive but also seriously cool are the Cambridge Simulation Glasses. These are considerably less expensive (£30 for a set of five glasses, which is less than $40 as of this writing), and therefore are easier for individuals looking to dabble in Inclusive Design to do so. The University of Cambridge is quick with orders and I received mine within a week of placing it. For shipments coming from the UK to the USA, really, that's pretty good.

Here's the single user Cambridge Simulation Glasses pack.


OK,  so what in the world is this?

The idea behind the simulation glasses is that you as an individual can experience progressive vision loss. Personally, I can already empathize because I have developed classic middle-aged person near-sightedness; I need readers to type this blog post, for example:
Not a fashion accessory, but also not a permanent fixture on my face (yet).
I do need them anytime I try to read or type anything.

If you are not already wearing prescription glasses, contacts, or need readers just yet, you may be wondering how you might be able to simulate mild vision loss. The simulation glasses do exactly that. Just put a pair on, and you will experience a little bit of fuzziness to your vision. If you want to intensify the effect, put on another pair of glasses over the top of the ones you are currently wearing. The kit comes with five pairs of glasses, and believe me, by the time you have put on all five, you will find it challenging trying to read much of anything.


If you wear glasses, you wear these over the tops of the ones you are wearing to give you a graduated simulation.

The loss of visual quality as you stack glasses.

The image above gives you an idea as to how fuzzy your vision gets with these, but it is even more jarring as you actually wear them. aAt the maximum level, you can really see how frustrating it is when you try to look at a screen or an object that has low contrast. Trying to determine what it is, much less how to use it, can be a real struggle. Again, there are software tools that simulate this, but there's something very interesting about being able to put on these graduated "fuzz" devices and try to do everyday tasks I take for granted.

For those who are interested in experiencing your apps, or your everyday products in a new way, and to develop a bit of empathy for your less visually normative friends (and those who live long enough will most likely get to join our ranks), then I do encourage getting these simulation glasses. They are worth the expense, and they do help reshape and reframe the way you see the world... or don't see it, in this case.


Thursday, October 27, 2016

Adventures in Tautology - What Makes a Tester a Tester?

The latest The Testing Show has been released. Some interesting thoughts and comments have been spinning through my head since we recorded this episode. For a number of organizations, the "tester" as we have long identified them, is going away. In this sense, I mean the dedicated person who focuses on testing as a specific discipline, who gets into the guts of an application, who spends the bulk of their time actually testing the product, independent of any other responsibility. For other organizations, testers are a huge part of their infrastructure, as essential and as non-replaceable as a plumber or an electrician. Why is there a disconnect? Is there a disconnect?

First, a little about my history. I can safely say I have worked for three companies that specifically needed to have dedicated testers. That's not to say the others didn't benefit from having testers, but I'm talking about how they were physically structured, staffed and what they made. Cisco was my first experience in the world of software development, but also hardware development and maintenance. That's where I saw first hand the different definitions of what a tester was.

First, there was the tester on the Engineering side of the house, those of us who worked on IOS (Internet Operating System, not to be confused with the much later appearing iOS from Apple), and on the microcode that resided on system boards. These teams had dedicated testers who spent a lot of time working with early automation frameworks or even just running commands via 'tip' to get access to the consoles of these devices to work with them. We also had quite a few of us who were involved with physically building up test labs, configuring the hardware, bringing in diagnostic tools and doing wide-ranging experiments. In short, we did things that the developers just plain did not have the time to do, at a level that provided a lot of feedback to further development and design, as well as to hunt down problems.

Aside from that, there was also the Manufacturing side of testing, which was a very different animal. For the first nine months that I worked with Cisco as a contractor, I was dotted-line associated with both Engineering and Manufacturing, and I sat in on meetings with both groups. It was here that I really saw the difference. Manufacturing testers were often times better described as "rework specialists", in that they tested, but they also rerouted and resoldered boards so that they could be re-deployed. I confess, I often felt out of my league with this group. It seemed they knew so much more about the bare metal issues than I ever could, and they also knew quality issues they had to address within seconds of looking at a particular board. I still smile when I think of going to talk to my friends Winnie, Jim or Azhar, among several others, and just their quick ability to look at something and say "oh, yeah, I can tell you what's up with that!" This was a skill, a craft, that I would say, honestly, only a handful of the software engineers possessed. This was a knack that was inspiring. I would ultimately work on the Engineering side of the company, and I would often suggest that, if we really wanted to augment our test teams, we really needed these people over in manufacturing to join us. Ultimately, several of them did, and yes, our test teams immensely benefitted from them being there.

The other two companies that required testers were Synaptics and Konami, for different reasons. Synaptics definitely because it was a blending of the software and the hardware (and truth be told, I think I found more issues with product tensile strength or composite construction than I did with software). Konami because of the factors that are so subjective when it comes to gameplay outside of "correct programming" (and the all important "physics tests", which, frankly, I don't wish on anybody). Oh, and in my case, they wanted to release a singing game, so they needed someone who could test and sing really well. Truly one of the most serendipitous jobs of my life :).

All of the other companies that I have worked for, I'd be hard pressed to say we essentially "required" dedicated testers, but again, I think we were well served to have them. Over time, though, as systems moved on to regular builds, incremental development and design, smaller and more frequent releases, and quicker answering to customer feedback, I can see why it would be easy to say "testing is a role and not a full-time profession, and we can do the testing with a smaller team or, even, with a single person" (which many times was me). Often, my testing role would be used, but I would be asked to do other things as well, such as provide second tier support, perform training, work on automation frameworks or, often, just look at the maintenance tasks within an organization. Side note, if you have not heard the Freakonomics episode about "In Praise of Maintenance", may I suggest you do so, as it has excellent commentary that is quite relevant to this discussion.

Since I've left Cisco, I have, generally, worked for smaller organizations. Those organizations have, at times, been subsidiaries to bigger companies, but usually, the group I work with is the entity that I interact with, so for all practical purposes, they are my company. That means I typically work with teams of around a dozen developers, rarely more, and most of the time, I've worked with me as a lone tester or, maybe, with one or two more testers. Most of the time, we are not just testers doing just testing. We cover a variety of other jobs and needs, and frankly, in smaller companies, that's to be expected. It's not uncommon for a tester to also become a de-facto systems administrator, or a triage support person, or a build master. We still test, of course, but also we encourage others to test as well. I'd say it's not so much that testers are going away, but that the role of testing is being seen as necessary in many places and not encompassed by a single person.

Ultimately, what we come to is that Testing as a discipline and as a craft is an essential part of software development. I still hold to the truism that training in testing discipline and philosophy is valuable, and those who do so will be uniquely positioned to benefit from doing that. I'm also saying "don't be surprised if you find that your job responsibilities are not just testing, or that you may even find you are not ultimately called a tester at the end of the day". At this point in time, my job title as defined by HR is "Senior Quality Assurance Engineer". Time agrees with the Senior part. Having to finagle and discover workarounds begrudgingly lets me consider myself an Engineer (I've never really been comfortable with that title because it means something specific in other industries that I have no chance of meeting requirements for), but Quality Assurance is my bag, even if the words are a little tortured. In short, I work in ways that help to encourage quality. I'm on board with that. I'm also on board with the fact that I often bring many other skills to the table that organizations can use, and that those skills can be leveraged to provide value for my company. Many of those skills have been informed by testing, but are not in and of themselves "testing".

To come back to the beginning, I think all of us test and all of us are testers, but there is a benefit to having a group who pays attention to the testing discipline more directly than others might. I'm happy to be part of that group, but I also understand that that alone will not make me valuable to an organization. Being a good tester is important, but if the desire is to work for smaller companies, do not be surprised if you are asked, "what else have you got?"

Thursday, October 13, 2016

Start Making Sense with Sensemaking - a #TheTestingShow Follow-up

One of the primary reasons that my blog is not as frequently updated as in the past is that I have been putting time into producing The Testing Show. Granted, I could do a quick edit, post the audio and be done with it, but we as a team made the decision we wanted to aim for a show that would flow well, be on point, and also have a transcript of the conversation. At first, I farmed out the transcripts, but I realized that there was a fair amount of industry specific stuff we would talk about that I would have to go back and correct or update, and then I'd have to put together the show notes as well, with references and markers. realizing this, I decided it made sense to just focus on the transcript while I was making the audio edits, so I do that as well.

Translation: I spend a lot of time writing transcripts and that cuts into my blogging. My goal is to make sure that The Testing Show is as complete as possible, as on point as possible, and that the words you hear and read are coherent and stand up to repeated listenings. Also, since it's a primary activity that I do within our little testing community, I really need to do a better job highlighting it, so that's what this post is meant to do. Consider it a little shameless self-promotion with a couple of additional production insights, if you will ;).

Occasionally, I get a podcast that tests my abilities more than others, and this week's episode proved to be one of those. We try our best to get the best audio files we can, but sometimes, due to recording live at a conference, or trying to capture a Trans-Atlantic call, we have to deal with audio that is not crystal clear. Often we get background noise that can't be isolated, at least not effectively. We sometimes get audio that is varying levels between speakers (one is loud, the other is soft, and leveling means introducing line noise to compensate for the low volume of a speaker). This time, it was the fact that the audio stream would just drop out mid-sentence, and we'd either have to repeat several times, or we'd lose words at random places. Because of that, this is a more compact show than normal, and that was by necessity. It was also a challenge to put together a transcript; I had to listen several times to make sure I was hearing what I thought I was hearing, and frankly, in some spots, I may still have gotten it wrong.

With that, I want to say that this was an interesting re-framing of the testing challenge. Dave Snowden is a philosopher, writer, and principal creator of the Cynefin Framework. "Cynefin" is a Welsh word that means "haunt" or "abode". In other words, it's the idea that there are things that surround you all the time that can give you clues as to what's going on, but you won't notice it unless you "live in it". There's a lot more to the framework than that, and Dave Snowden talks quite a bit about what it is and how it's been applied to various disciplines. Anna Royzman also joined in on the call and discussed her involvement in using Cynefin, and what it might mean for software testers who want to use the framework and approach with their testing. A caveat. This is a framework that has been used in a variety of places, from applications in government to immigration to counter-intelligence and software development. Testing is a new frontier, so to speak, so much of this is still to be determined and very much in the "alpha" stage.  Anyway, if you'd like to know more, please go have a listen.

Sunday, October 9, 2016

The Humans In the Machine - Talking Machine Learning

This weekend was one of the more interesting Weekend Testing Americas sessions I've hosted. Hurricane Matthew was making itself known and people were dealing with getting in and out of a broad section of the Southeastern United States on Saturday, as well as looking at whether or not their homes were OK. Under those circumstances, I can understand getting together to talk testing may not have been a high priority. We had several people ask to attend, but by the time it started, there were just two of us, Anna Royzman and myself. Anna and I both decided "hey, we're here, Anna's never done a Weekend Testing session before, let's make the most of it" and so we did :).

Our topic this go around was a chance to look at a new feature of LoseIt called SnapIt. The purpose of SnapIt is to take pictures of food items, and based on what the app thinks the picture is, select the food item in question and get a macronutrient breakdown. This is a new feature, so I anticipated that there may well be some gaps in the database, or that we might get some interesting tags to appear. We were not disappointed. In many of the pictures, well known food items were easy to identify (apples, bananas, etc.) and some a little less so (a small pear variety that had a darkish green skin was flagged as Guacamole, which isn't really too far of a stretch, since I could see it interpreting it as a small avocado):





Complex and packaged foods it struggled a little more with, but in those cases, if it has a bar code, most of the time, reading the bar code would deliver the information we needed, so SnapIt was less important in that setting, but it was interesting to see what it flagged things like granola bars or shelled walnuts as.





During the session, we did discover one interesting bug. On my iPhone, if a user takes two pictures, and discards them, and tries to take a third picture, the camera button on the screen appears as a half circle. The bottom of the button is missing. Exit the camera and open it again, and the camera button appears complete again. Shoot two pictures and throw out the two, you will get the half button on the third try.



Outside of the actual testing of SnapIt, we had a pretty good discussion of machine learning in general and the idea that many of the algorithms used for these processes are pretty good, but can often have unintended consequences. The past few weeks, I've been listening to a number of podcasts that have featured Carina C. Zona and her talk "Consequences of an Insightful Algorithm" (talk and slides). She has appeared on both the Code Newbie podcast and the Ruby Rogues podcast, and both treatments made me want to explore this topic further. One comment from Carina's presentation that stood out to me is the idea that "math (algorithms) are objective conceptually, but their implementation hardly ever is, because it's people who create them, and we create algorithms with our prejudices, biases and fallacies intact. In short, we do not see our algorithms for that they are, we see them for who we are (paraphrase of Anais Nin, but you get the point, I hope ;) ).

I'd encourage anyone who wants to get a better understanding of the potential dangers of relying too heavily on machine learning, as well as the human aspects that we need to bring to both coding and testing those algorithms, please check out Carina's talk. For those who want to see some of the terrain that Anna and I riffed on, please feel free to read the chat transcript of the WTA session.

Friday, October 7, 2016

In That Moment of Terror, Evolution Occurs

There has been much of interest in my day job as of late. Much to keep me busy, much to ponder and consider, and definitely wondering "where do we go from here?"

In the course of the past two weeks, we've received the news of two, frankly, heavy departures from my company. One of them is for an amazing reason. Our senior software developer, Audrey Tang, has left us to become a Minister without Portfolio in the Executive Yuan of the Republic of Taiwan. Seriously, how does a software company compete with that? The second is of our Vice President of Engineering, who has been with our company for ten years, and has the deepest institutional knowledge of anyone in our company. With these two departures, I've come to realize that I am now one of a small few who are the senior members of the team. In short, whether my role or job title reflects it, I'm now one of the "sages" of my company. Only four other people have longer tenure, and that's measured by months, not years.

To be honest, some people are fearful. What does this mean? Where do we go? Can we do what's expected? Those are completely legitimate questions, and I find it interesting that a number of people are asking me for my "lay of the land" in this situation. I'm not going to talk "out of class" so to speak, but I am going to share some general thoughts that I think are relevant to anyone in any work capacity, and they match my general philosophy overall.

This is a time of uncertainty, sure. How long will it take for us to replace these two people? I'll argue that they can't be "replaced". We can hire people, or promote people, to fill their roles, but we will never "replace" their drive, genius or quirks that made them effective. My answer is "don't try". No, I don't mean give up, I mean don't try to replace them. Instead, forge ahead with new personalities, new ideas, new modes of genius, and dare I say it, insert yourself into the conversation or situation if it makes sense. First, who's going to stop you, and second, they probably are elated you want to help carry the load.

Evolution doesn't come at times of health, well-being, peace and comfort. It comes at times when there is a crisis, or a threat of extinction. We don't learn when things are going well, we learn when things are going haywire, and we need to solve real problems. Over the past few years, I've determined the best course of action is "We seem to be having some trouble here. How can I help?" I came into my current company as a tester, with testing my sole focus. Upon the death of a co-worker and mentor, I took over their role as Release Manager, and became more familiar with our code base than I likely would have otherwise. I didn't get promoted into that position. I saw there was a hole now, and no one there to do that job, so I decided to figure out how to do it. No one said "No, you can't do that, you have to go through channels". Well, not entirely true, I did have to convince a few people I really did learn enough about what needed to be done to get access to resources necessary, and in that process, I did basically declare "I'm Socialtext's Release Manager", when there was no one official to back me up. What happened? The de-facto became official. I became Release Manager because I declared I would be it, and under the circumstances, there was no one in a position to really object.

Today, I see similar opportunities. If I ever wanted to declare myself as the head of Dev-Ops, or to declare that I am now a supporting software developer, or even help chart architecture decisions, that time is now. However, I will not be able to really do that unless I am also willing to put the time in necessary to show I have both skills and willingness to do it. I'll not pretend that I'll be promoted to VP of Engineering. That's a bit beyond my skill set or desire, and we've already got a new VP of Engineering, but they will feel like a fish out of water for awhile. My plan is to do what I've found to be most helpful, which is to say "you seem to be struggling with some challenges... how can I help?"

Thursday, September 1, 2016

This Week on #TheTestingShow: Real Work vs Bureaucratic Silliness

I have come to realize that I am terrible in the shameless self promotion department. I have been actively involved the past several months with producing and packaging "The Testing Show", but I've not been very good about talking about it here. Usually, I feel like I'm repeating myself, or I'm rehashing what I already talked about on the episode in question.

When Matt takes the show on the road, however, I do not have that same issue. This most recent episode of The Testing Show, titled "Real Work vs. Bureaucratic Silliness" was recorded at Agile 2016 in Atlanta. As such, Matt was the only regular panelist there, but he put together a group consisting of Emma Armstrong, Dan Ashby, Claire Moss and Tim Ottinger. For starters, this episode has the best title of any podcast we've yet produced for The Testing Show (wish I came up with it, but it's Tim's title). I think it's safe to say all of us have our share of stuff we like to do, or at least the work that is challenging and fulfilling enough that we look forward to doing it. We also all have our share of "busywork" that is inflicted on us for reasons we can't quite comprehend. Tim puts these two forces on a continuum with, you guessed it, Real Work on one side, and Bureaucratic Silliness on the other.

I think there's an additional distinction that needs to be included in here, and that's when to recognize that some task, behavior, or check point actually is an occupational necessity, and when it is truly Bureaucratic Silliness (BS). In my everyday world, let's just say this tends to grade on a curve. Most of the time, BS comes about because of a legitimate issue at one point in time. Case in point; some years ago, in spite of an extensive automation suite and a robust Continuous Integration and active deploy policy, we noticed some odd things passing through and showing up as bugs. many of these things were not areas we had anticipated, and some of them just plain required a human being to look them over. Thus, we developed a release burn down, which is fairly open ended, has a few comments of areas we should consider looking at, but doesn't go into huge details as to what to specifically do. The burn down is non negotiable, we do it each release, but what we cover is flexible. We realized some time back that it didn't make sense to check certain areas over and over again, especially if no disruption had occurred around those features. If we have automated tests that already exercise those areas, then that likewise makes it a candidate to not have to be eyeballed every time. If a feature touches a lot of areas, or we have done a wholesale update of key libraries, then yes, the burn down becomes more extensive and eyeballing certain areas is more important, but not every release every single time.

Usually, when BS creeps into the system, it's because of fear. Fear of being caught in a compromising situation again. Fear of being yelled at. Fear of messing something up. We cover our butts. It's natural. Once or twice, or until the area settles down or we figure out the parameters of possible issues, makes sense, but when we forget to revisit what we are doing, and certain tasks just become enshrined, then we miss out on truly interesting areas, while we go through BS to the point that we would rather pull our intestines out with a fork rather than have to spend one more minute doing this particular task (yes, that's a Weird Al Yankovic reference ;) ).

Anyway, were I part of the panel, that's part of what I might have brought up for discussion? If you want to hear what the group actually talked about, well, stop reading here and listen to The Testing Show :).

Friday, July 29, 2016

Consider the Source: A Tester Invades Philmont

One of the more entertaining aspects of our trek would have to be the final two days, in that we were joined by an expedition mate that, let's just say, is a little different than the average hiker:


Testhead readers... meet "T.K."

Actually, his real name is "30", which is the number he wears around his neck for identification purposes,  but part of the "Burro Expedition" experience is that each crew gets a burro to join them for two days, and the crew gets to name the burro for the duration of the trek. Needless to say, it would be impossible to keep track of the names changing all the time, so the burros are officially known by their numbers, but are also conditioned to respond to any name they get called. 

During our trek, the boys talked a lot about the Anime series "Angel Beats" (which also happens to be one of my favorites), and we joked a lot about who our favorite character in the series was. That character was "T.K.", a long haired, always moving dancer who would speak in nonsensical English phrases (even in the original Japanese recording). When we met burro number 30, and he came up to us and looked at us with a circular head bob, we all laughed at the similarity to the movement T.K. did in the anime, and we all said "Hey, let's call him T.K.!" With that, T.K. became an official member of the crew, and would help us on the trek for the last twenty miles or so by carrying some of our gear for us.

As we were making our way to the Baldy Skyline camp area, we had a number of choices we could take to get there. As we scanned the area, we saw that there was a road that looked to be a straight shot up to the area, and pretty short by comparison. We started walking towards the camp and for the first bit of the stretch, T.K was walking alongside us and made no fuss. When we saw a fork in the road, and the trail that continued up to the camp area came into view, TK started walking that way, but we guided him back to the main road. Over the course of the next few minutes, TK walked slower and slower, and finally stopped. We tried to coax him forward, and we'd get a few steps in, and then he'd stop again. We did this about half a dozen times, and each time, it was getting to be progressively harder to move TK further up the road.  

Additionally, as we looked at T.K., we had the impression he was looking at us as if to say "hey, you guys are all idiots! Did you see that trail that forked off the main road a while back? That's where we're supposed to go. Trust me, I've done this trek more than a few times, I know how to get there!" Still, we felt confident that our short cut would work and save us time, so we persevered. I've had experience leading horses and burros in the past, so I took it upon myself to hold his bridle and lead rope and coax him up the road, and ultimately, he let me lead him up the road.

The road we had chosen changed. It became steep. It was straight, sure, but it was also a laborious climb to get up to the ridge line where the camp was. It was tiring, it was in direct sunlight, and by the time we reached the top of the road and the ridge line, we realized that, while we were at the top of the hill, the actual camp area we needed to be at was still about two kilometers east. As we trudged to the camp area, we saw the trail converse with the upper road, and we also saw that the trail was coming out of a wooded area, with plenty of shade, the trail meandering through a range of switchbacks that, while longer in total distance, would have been much kinder to our knees and backs. As I looked at T.K., it felt as though he was saying "See, I told you you were an idiot! I could have led you here and saved you a lot of hassle, but no, you had to go your own way. How did that work out for you?"

Does this sound familiar? I know it does to me. I've had this experience with my teams. We are so sure that what we are going to do will save us time, it will be different than all the previous times we've tried to meet a goal, but someone, usually one with a lot of experience, puts up resistance and tries to point out what we should be doing. Often, that advice goes unheeded, only to come back and bite us later when we realize that the insight was valid, accurate, and based in experience, but our hopes and optimism for a faster way (or a looming deadline) blinds us to the hard earned experience. 

I chuckled as I thought about this the following day, when we left the Baldy Skyline camp to head down to the next area and followed the main trail. T.K. just started going, and he barely stopped. He knew where he was, and he knew where we needed to go. Sure, we consulted our maps to be sure, but otherwise, the trail was the most direct route, and he just plowed ahead until we chose to call a halt for a rest break. During the remainder of the trek, as we were debating ways we should go, I'd quietly nudge T.K. to move forward, and I'd see where he wanted to go. Typically, I'd encourage following his lead, and each time, it would prove to be the most direct and easy to navigate route. Sure, it would have been more adventurous to bushwhack, but I'm sure T.K. appreciated not having to climb over or around felled trees or other obstacles.

There are times when new vistas are open to you, and there is no trail to follow, and one way is as good as any other. At times, though, there are those who have gone before us, and instinctively know when we are going the wrong way. It's wise to step back and listen to those who express reservations. Who know how much sweat and toil they might save us if we listen to them ;).

Thursday, July 28, 2016

The Passion of the Champion: A Tester Invades Philmont

A couple of days ago, I shared the challenges that some of our youth leaders faced when they wanted to break camp and get to the next destination. Sometimes they had their act together. Many times they didn't. It would have been very easy for me to play the dictator and push and yell to get the team moving. I've done that before. It's very efficient, but it does nothing to develop actual leadership or confidence in abilities.

This was especially true the third day into our trek. Our Wilderness Gia wanted to do a special ceremony/presentation around the Leave No Trace principles. He'd planned out the whole thing, and was really looking forward to doing it. That third day, we had a late start, and we had to cover a lot of ground, much of which was unmarked and required us to climb and descend a ridge, cross a river, and make our way to that day's base camp. By the time we arrived, we were all bone tired, most of the day was gone, program areas were closing, and one of our boys was exhibiting signs of altitude sickness. Needless to say, I had to tell our Wilderness Gia that the ceremony he wanted to do wouldn't be possible today. Based on the performance of the group today, tomorrow wasn't looking too good either, but we'd figure something out.

The reaction I got back to those comments was both unexpected and slightly amusing. He fumed, looked at me with complete disbelief, frustration and shades of anger. He was really invested in having this ceremony take place. Seeing this, I looked over to my associate advisor, asked for a minute, and said "want to try an experiment?" My fellow advisor was game, and with that I returned back to our Gia and said:

"A sunset ceremony just isn't possible under the circumstances, but would you be willing to shoot for a sunrise ceremony? Look at the ridge line up there. It will take a little while to make the climb to the saddle, but we could do it in about an hour. Problem is, we are going up and over the ridge, so coming back for our stuff and doing it all again doesn't make sense. If you want the sunrise ceremony, you will need to make sure everyone is up, packed, and ready to leave camp at 5:00 a.m. That means waking up at 4:00 a.m. to make the departure time. Doable? Yes! Do I think you all will be able to? Surprise me :)!"

With that, I prepped for dinner, went to bed, and figured the sunrise ceremony would likely not happen. 4:00 a.m. rolls around, and what do I hear but the Gia up and about, waking his fellow trek mates, working with them to get out of their tents, those same tents broken down and packed, and hustling to get everyone ready to go. Each opportunity he came around, I asked if there was any cause I could lend my hands to (a phrase the crew got to know regularly; I didn't tell anyone what they should or shouldn't do, but if they asked me to do something, I was always ready and willing to do so). Needless to say, we got out of camp in record time, and we made the scramble up the ridge line to the saddle, found a great spot to set up, and he led us in an excellent presentation that included meditation, discussion and watching a beautiful clear sunrise come up over the Great Plains and peek through the Sangre de Cristo mountains. What's more, we had an easy downhill descent into the Valle Vidal, a flat walk to our re-provisioning spot, and the ability to arrive at our destination for the day at 10:00 a.m. We had plenty of time to set up camp, relax, make lunch, join in activities at the base came, and basically bask in the fact that today's mileage, while comparable to yesterday's, went faster and so much more comfortably.

What was the difference? One of the youth leaders was on fire. He was on a mission to make this ceremony happen. His drive helped carry everyone else along. He spelled out the importance, what it meant to him, and what he himself was willing to do to make it happen. As an adult leader, I do that all the time, but there's a considerable difference when a youth leader decides something is important enough to push the rest of the group along.

If there's an initiative you think is important, be a champion for it, but better yet, encourage others to champion that initiative alongside you. Our Gia wasn't successful just because he was persistent (don't get me wrong, that helped a lot ;) ). He was successful because he was able to get the other boys to share in his vision. He got them excited about doing what he had planned. That turned into action and results. More to the point, it gave them an excellent contrast between the rushed and harried pace of yesterday, and the nearly effortless and smooth feeling of today. I was able to use both mornings as models for what to do and what not to do. It would be great to say that they always made early morning camp breaks after that, but that would be untrue. We had our share of late days after this, too, but it made a stark contrast for them to see the difference in how they performed, and felt, comparing the late departure day to the early departure day. Over time, it became easy to help them share that narrative, and encourage them to get the early start on the day, but in those cases, someone else was able to champion a reason, and get others to rally around their flag.

Wednesday, July 27, 2016

Pay Attention to Your Team: A Tester Invades Philmont

One of the factors that I had to deal with during our Philmont expedition was paying attention to the health of the participants. One of the more challenging issues, and something many of us were not used to dealing with, was altitude sickness. In a general sense, altitude sickness is the effect on the body of a lack of oxygen at high elevations, and is usually felt by people who have not had a chance to acclimatize to a higher elevation environment. Simple symptoms had to do with exhaustion, hyperventilation, and an overall feeling of nausea. In this environment, we had to weigh how long it would take us to get from point A to point B, but at the same time, monitoring what could be developing health problems that, left untreated, could become serious.

One of the most disheartening things is to watch someone physically suffering through a hike. The smile leaves their faces, there's a grim look to them, similar to the "thousand yard stare" that was often used to describe soldiers, and on occasion, listening to boys coming into camp literally breaking down from exhaustion (in some cases rendering them to the point of tears). We had practiced backpacking scenarios for months, and we had gone through numerous terrain variations as well as carrying heavy loads on these practice runs. We felt sure we had met the rigors required, but when you live at sea level, and the highest elevation in the vicinity is just a little over 3,000 feet, there's just no way of preparing for days at 10,000 and 12,000 feet without going to those elevations and hanging out for a few weeks. We didn't have that luxury, and at certain times, we paid for that.

Be Alert and Attentive to Your Team

Each morning, I would do a simple ritual with all of the participants. While I would not dictate the activities of the trek itself, I did have authority over the safety and health of the expedition, so every morning I ensured that every participant was leaving camp with a liter of water for every hour we anticipated being on the trail (meaning we carried four to eight liters of water each day). Additionally, I made sure each participant had a separate Nalgene bottle that was topped off and mixed with an electrolyte drink mix (Gatorade, All Sport, Skratch, etc.) and made sure that they were drinking from it regularly. It may seem counter-intuitive, but you have to actively think about drinking water when you are engaged in long hikes. I found that, when I got into the zone of a hike, I would go for extended periods without drinking anything. At seal level, that may not be a big deal, but at higher elevations, the body goes through more water more quickly. If you feel thirsty, you are already in trouble (as in you are already dealing with moderate dehydration).

One thing we found helpful, especially on quick elevation rises, was to use a "procrastination dash" approach to the hike. We often struggled with trying to find a balance between keeping a good pace and allowing for adequate rest and recovery (because elevation sickness becomes more pronounced if you do not allow yourself adequate rest). To this end, we decided to do a cadence of ten minutes active hiking and two minutes of "standing rest". We would repeat this sequence ten times, which would give us 100 minutes of active hiking and 20 minutes of rest. At the end of the two hours, we could take off our packs and have a genuine rest for twenty minutes. The rest breaks were mainly so I could ensure everyone was drinking water and actually see them do it. Over time, we were able to shake of the headaches, nausea and other symptoms that were becoming a regular occurrence.

This may seem like an odd story to relate to from a testing perspective, but I see similar parallels when I am looking at skill levels and abilities on our respective teams. Some people are super resilient and can take on anything, while others struggle and suffer quietly. As I watched the participants deal with the challenges of the trek, I came to realize that some would complain easily. They wore their discomfort on their sleeves, and it was easy to tell where they were on a mood level and a health level. The real challenge were my "stoics". I had a few guys who were determined to not let me "see them sweat". They never complained, never gave me any reason to believe they could be in danger, and yet each and every member of the expedition at some point dealt with symptoms of altitude sickness.

For the stoics, their conditions were often more challenging, because I didn't see the signs until they were deep in the hole. Likewise, with our teams, we may have those same stoics among us, willing to shoulder their load and muscle through, but lacking in technique or additional understanding that could make them more effective. Too often, we don't learn about what the stoics need until they have actually cracked or gotten themselves into a situation where they can't hide any longer. From this trek, I realized that it was worth a moment's annoyance to confirm that everyone was doing what they needed to do, and was getting the food, water and rest that they needed. Our work teams have similar needs, if not so physically oriented.

Tuesday, July 26, 2016

A Tester Invades Philmont: Lessons from the Trail

Well, I made it.

An event that I had trained for, lost a lot of weight for, and did a lot of practice runs with a scout troop to help make us eligible to participate in has come to an end. I've been home for a week now, and I've been able to think a bit on the various events, activities and opportunities to learn that I, and my Troop, were subjected to.

Six youth and two adult advisors took to the backcountry of the Sangre de Cristo mountains in New Mexico for two and a half weeks, and we all lived to tell the tale. It's a safe bet everyone who participated in this trek came back changed. For the next few posts, I'd like to talk about some of those changes, and what I learned while I was unplugged from civilization for that time.



First, a little background. A part of my scout troop participated in a trek at Philmont Scout Ranch. Philmont is the largest of the USA High Adventure bases used by the Boy Scouts of America. Other properties used for High Adventure bases are Northern Tier (located in the Boundary Waters region of Minnesota), Florida Sea Base (located in the Florida Keys), and Summit Bechtel Reserve (located in the mountains of West Virginia), but Philmont is the one that most Scouts have heard of, and for many, it's the ultimate destination for a high adventure trek at least once in their scouting lives.

Crews are limited in size, from a minimum of seven to a maximum of twelve. All participant need to be at least fourteen years old. There are weight requirements and fitness requirements for both youth and adults to attend. We quickly learned that these were not suggestions, but genuinely necessary for successful completion of treks. For 2016, Philmont offers thirty-five possible treks for crews to take part in, and encourage early selection of a variety of options. Once you get assigned an Itinerary, that's the one you do, and everything is built around your itinerary. Ours was #10, which focused on going into the Northern part of the Philmont property, as well as hiking into regions of Carson National Forest and Valle Vidal, as well as going into places where trails and trail markers didn't exist, or at least would make the journey longer if we were to follow them.

An expedition is led by a Crew Leader, along with a Chaplain's Aide and a Wilderness Gia (Guide). All of these jobs are held by youth members of the expedition. Ideally, adults advise, but call no shots and get no votes on what the expedition does. Needless to say, what is ideal and what actually happens often doesn't line up, but more on that in a bit ;). We determined that "we advisors" would do little in the way of active management of the trek. We would offer suggestions, we would model behavior, we would give examples of things to do for the boys to learn from, but as much as was in our power, we would not interfere with their decisions or operations. This gave us ample opportunity to teach, but it also gave us ample opportunities to learn about group dynamics and leadership in general.

At the outset, I want to say that I am immensely proud of this expedition and what it accomplished while it was out in the field. I'll dare say I learned as much from them, if not more so, than they did from me. Still, there were some interesting observations I'd like to share.

Leadership is a Walk

If there was any one thing I wish I could go back and help train this expedition better to accomplish, it would be to see how they could execute on the plans they made. Leadership is more than making a plan and telling people the plan. That part is easy. The difficulty was actually getting the group to execute on what they agreed to do, and seeing the consequences of not executing. The two adult advisors shared a tent, as well as some common equipment. We both knew what we had, how much space it took, and what it would mean for us to carry it on our backs for ten days. Because of this, we split up our obligations. We split the gear, including the tent, and we knew what we needed to do. Each morning, we'd wake up 15 minutes prior to designated wake up, because that's just what a leader does; we know we have to take care of our own business before we can be of any help to anyone else.

We'd wake, stow our personal gear, break down our tent, finish packing our packs, put them in the pack line, and then we'd sit in a central area and wait for the boys to do their thing. Some mornings, we'd be waiting an hour or more for the leaders to wake up and get the rest of the group moving. Sure, it would be easy for us to walk over, tap on the tents, and remind the leaders what time they said they wanted to wake up. At times, we would, quite loudly, talk among ourselves to give the hint that they should be awake and active. Simple things that we took for granted seemed to be a challenge for some participants, such as setting an alarm to wake up, or to do something as simple as to ask one of the adults to use their alarm, and follow up with them to get them up on time.

Another stumbling block to execution was the stowing and transporting of shared expedition gear. Bear bags, ropes, carabiners, pots and camp stoves were the property of the entire group, so provisions had to be made for each item to be carried by someone. On several of the early days of the trek, the delay in getting everything packed was "who is going to carry (fill in the blank item)?". Everyone knew what they needed to carry that belonged to them, but allocating items that were expedition equipment seemed to be a recurring problem. Each day, someone waited to see who would make the first move to carry whichever item needed to be carried. Few were the ones willing to just divvy up the items and say "I'll carry this" and be done with it. This often meant that it might take an extra hour or two to sort who would take what.

Sure, I and the other adult leader could have just said "you take this" and "you carry that", but that went against the whole ethos of the trip. We were there as suggesters and as extra sets of hands. Needless to say, we often struggled with this. It's easy to say that you will step back and let the leaders lead, no matter how painful that process might be. At times, it truly was panful, because the solutions, at least to me, were so obvious. I realized, though, that was not entirely fair. I've had years of experience, both on the trail and in everyday life, where efficiency and effectiveness developed from many experiences where I was anything but. These boys were in a new world. They came to realize that saying they were leaders wasn't enough, they had to actually be leaders. At times, they would succeed. At times, they would fail. Usually, they would fail because they couldn't see a larger picture.

Each morning, we'd have to break camp and get to our next destination. Often, that next destination was anywhere from six to twelve miles away. That may not seem like much when walking city streets, but it takes on a different meaning when you are carrying fifty extra pounds on your back, have no set trails, and are at altitude over 9,000 feet. A term that I mentioned often was "hiking in the heat of the day". It was a very different experience hiking at six or seven in the morning than it was hiking at ten or eleven. The temperature could be as much as forty degrees higher (that's Fahrenheit, because we're American's, and we just use that system. I know in the rest of the world a forty degree difference means something significantly more ;) ). Still, that difference had a big impact on the progress of the rest of the day, and what energy reserves were left at the end of the hike to do things in the new base camp area. An early start meant a relatively quick hike, with plenty of energy and time to do program activities and relax a little bit. A late start often meant arriving at our camp late in the day, no time to do fun activities, and a scramble to get done what we needed to to get camp set up, dinner cooked, and to get some sleep before the next day. It tok a few times, but my comment of "hiking in the heat of the day" slowly started to sink in, and the group figured out what it needed to do to get a move on, so it wouldn't have to bake under the hot sun for too long each day.

I see many parallels in the work I do every day, in the way that I often lead testers and other engineers on my teams. It's so efficient to just tell people what to do, but real learning and expertise is rarely developed that way. Often, advising as to a course of action, and then stepping back and letting people do what they need to do is a much better option, but it is also filled with frustrations. It will rarely be done the way we want it to be done, or in the timely manner we would hope it would be done... at least, not at first. However, when people are held accountable for the execution of their plans, especially if they say they will do something a certain way, they will often meet up with those expectations over time.

It requires a willingness to walk a leader's walk, and at times, that willingness means being able to model correct principles, yet let people govern their own ways of actually accomplishing the goals they set. Yes, that includes dealing with the consequences of their actions (or inactions) at times. I frequently told the participants of our expeditions that the adults were ready an hour or two before they were, and as such, we just sat and waited, and of course we suffered through their delays and "hiking in the heat of the day", too. Over time, though, they came to internalize what they needed to do, and they also figured out how to cut their time from waking to walking down considerably. It's a shame we didn't have another ten days, as I think they would have been fantastic on a second leg. As it was, they were getting the hang of it by the time we ended the trek. Maybe they can carry it into the future and other activities they do. Time will tell :).