Wednesday, November 18, 2015

Feet Don't Fail Me Know - TESTHEAD's Fitness Journey Continues

One of the entertaining aspects of fitness is the fact that there are lots of things we can do to keep us motivated and targeted to meet our goals. Over the course of three months, I've gotten into walking for long distances, using various resistance devices (bullworker, etc.), doing yoga, lifting weights, etc.

A couple of months ago, I added something to my training that I hadn't used in years, but made a lot of sense to put back into play. In short, I broke out my old PlayStation 2 and several volumes of Dance Dance Revolution (DDR) to help get me back into "fighting shape".

This experience reminded me of a testing situation that I got to deal with about 12 years ago when I worked at Konami Digital Entertainment, and how it influenced my purchasing decisions back then. By virtue of working for Konami, and having made friends with several of the people in marketing and distribution, I was able to get a number of the DDR games for free. To that end, I picked up Dance Dance Revolution Konamix (a PS1 game but playable on PS2), DDRMAX, DDRMAX2, and Dance Dance Revolution Extreme (these later three released for PS2, the latter two in development while I was at Konami). The games themselves had their quirks, as do they all. It's funny to look back today and see a variety of misspellings, or menu options that don't flow quite right, but that went to production nonetheless, back in an age when a bug, if released, was eternal. Still the games themselves were, and are, still fun, and the music especially brings back a lot of nostalgia.

The issue that became a big deal was not with the games themselves, but with the dance pads that were made for Konami. These dance pads had a fairly high number of pads that had an odd sensor issue. Over repeated use, if you were to step on the back arrow while stepping on another pad (common for jump steps and just making movement more efficient), the sensor would either intermittently not work, or it would just stop working entirely. This was not an isolated issue, it turned into a big deal heading into the new year in 2004. In fact, I had been "seasonally laid off", after the Christmas rush of 2003 was over (which was, truthfully, expected, and since I was back in school at the time, I didn't necessarily despair at such news). The problem with the number of pads was large enough that I was actually called and asked if I'd be willing to come back in to help them deal with the issue. I said "of course" and subsequently was rehired and worked with Konami all the way through the remainder of my time back in school. The dance pad issue was a manufacturing defect, and it would be a significant portion of my side customer support work for the remainder of my time there.

Because of this, when I decided to pick up these DDR games for my kids to play with, I was happy to have the games, but I opted to buy different, non-Konami dance pads. There were ranges of designs from foldable soft pads that cost about $30, to hard metal and plastic pads similar to what the DDR machines in arcades had, and these cost around $250 each. Through my research, i discovered a set of pads in between made by RedOctane. These pads used rubber mats internally to make the pads semi rigid, but light enough to be moved easily and stored (in this case, behind the couch in our upstairs family room). During the course of a couple of years, the various games were played by my kids, and myself as well, but then, like many things, the pads were tucked behind the couch and sat there for years. the games were tucked away into the PlayStation 2 games drawer, kept for a later date and time (I believe in the replayability of games, so I tend to hold onto titles for years, because I enjoy revisiting older titles to play them again after a long absence). In November of 2015, DDR and the RedOctane pads made their emergence from behind the couch and from within the storage bins, and returned to center stage in my reality.

DDR has a workout mode on each of the games. What's nice about the workout mode is that you can set a number of parameters. By entering in your weight, preferred step settings, and calorie targets, you can customized a workout that can be as short or long as you need to meet your goal. I've experimented with a variety of the settings, with the goal of hitting 1000 calories. Averaged out, it turns out that 1000 calories is about an hour and forty minutes of "dancing", which really is more stepping on arrows in time. Another benefit of workout mode is that you can turn off the "typical game behavior of "failing when you don't hit the steps well. It's a great feature for game play, but a lousy feature when you want to keep going regardless of steps and score (and believe me, after close to ten years, my step accuracy at standard mode and higher leaves a lot to be desired ;) ). Another nice benefit of having this as a workout option is that it allows me to combine workout goals and step goals. Instead of trying to walk 10,000 steps, on certain days I can "dance" those steps, or at least a fair number of them. this does tend to make calorie counting and averaging a little challenging, but I'm not stressing over it too much. If I'm able to burn 1,000 calories by playing, that's plenty for just about any given day.

As of this morning, I am holding at 214.8 pounds, or just over 45 pounds down from 260 when I started this whole thing August 14, 2015. Variety is the spice of life, and today, I am thankful for an old amusement for coming to the rescue and offering me a bit more variety to add to my activity mix. Though I can't guarantee 1,000 calorie burns every day, every little bit helps, so here's to keeping on :).

Thursday, November 12, 2015

Integral Quality - Live at #AgileTD

Wow, we are at the closing keynote. Didn't I just get here? Seriously, I know it's Thursday afternoon, but time has sort of lost its meaning to me these past few days. Nevertheless, we are at the final keynote talk, and Olaf Lewitz will be closing out Agile Testing Days.

Have we considered the ways that amazing things get created? Is it all an obvious need that just gets met, or does it happen because we notice something, and then we push forward because we believe in the cause and delivering something to meet a need. I think truly great initiatives start from the latter, and many times, I think serendipity has a lot to do with it as well.

Too often, I think we look at what others do, but we don't turn that lens on ourselves. rather than "what can the organization do to be successful, with me coming along for the ride" perhaps a better question is "what can I do to make this organization amazing?"

Olaf asked us to say what we are grateful for through this conference. It would be too messy to do this in person, but there is something I can do, and I'll do it here :) :

Thank you, Madeleine Greip, and the Agile Testing Days organizers, for inviting me to speak at this wonderful event.

Thank you, Meike Mersche, for being a wonderful tour guide, showing me around Potsdam, and buying me Red Bull Cola, as well as being a bright and happy face to see every morning.

Thank you to each and every person who attended my talk, gave positive feedback, retweeted or wrote about what I said (especially Kim Knüp, who dedicated a full blog post of her own to my talk).

Thank you, all speakers, for your time and your talent and energy. You've given me so much to write about these past few days.

Thank you, Albert Gareev, for being my partner in crime and asking me to make 2015 a year of Accessibility, and challenging me to make it the primary focus of what I wrote and spoke about for the year. I have learned a lot because of that, and I think there's so much more we can do :).

Thanks to the readers of TESTHEAD, for being willing to follow along with me when I go on these mad dashes at conferences and posting a dozen or two posts in just a few days.

One of the interesting comments Olaf shared was the idea that, if we remember back to The Matrix, there's a metaphor of a blue pill and a red pill. Blue pill means ignorance and just going with the flow. Red pill means waking up and seeing things as they really are, good and bad. Interestingly, when we have the ability to make choices, we tend to be solidly on the side of the option that gives us choice, and specifically those options that we genuinely understand what is happening.

"Options have value. Options expire. Never commit early unless you know why."

Quality is, frankly, a bizarre thing. It's not elegant and clean. In fact, quality is messy, nebulous, and wholly subjective. Jerry Weinberg's statement of quality is "quality is value to some person". With the number of persons out there, there are just as many definitions of quality as there are people to perceive it. Therefore, the first person who has to decide that quality is sufficient is me. Point blank, would I want to use the software I am testing? If so, why? If not, why not? If I have a steady litany of why not's, then I have a duty and obligation to voice those concerns, even if I may be the only person who recognizes them as such. In short, I have to know what I want first. From there, I need to know what the organization wants, and then I need to know what my customers want (and by that, I mean what all my customers want).

Human organizations have had several revolutions. First was the Tribal Revolution, followed by the Agrarian Revolution, then the Industrial Revolution, and currently the Information Revolution. If James Burke is right, we are in a period of transition, where what was once known and owned by an elite few, will be available to everyone. The bigger question is... what's next? What's the next big revolution? What will the new paradigm be when it comes? How will we fit in it (assuming it happens in our lifetimes)? We have a chance to shape that new future, and we have the opportunity to start with ourselves and our organizations. If we want to see change and better quality. Let's start with ourselves, and take it from there.

Testing my Biases - Live from #AgileTD

Oana Juncu makes a straightforward statement right out the gate... We make decisions based on our invalidated assumptions that we take for granted facts. Life may be better if we become aware of this.

Every one of us has biases that we use to create a short-hand for our world view and thinking.  Most people are unaware of this, and they feel as though they are being very rational and analytical, when in truth they are reacting via a system that has been honed over eons of time. The fact is, we all cope day by day by making assumptions. We make decisions based on our assumptions that we take for reality. We act on a survival instinct. We can make very quick decisions and we can seem very forceful and decisive, but in fact,  we are often behaving in ways that are wholly irrational.

Each of us has had an experience where we have convinced ourself of a reality, only to be given new information that opens up our view, and when we see the new "reality" we cannot unsee it.

Cognitive dissonance is what happens when we have an experience where an outside "reality" interferes with our own perceived reality. If we are open to the possibility, it may be very low. It may be much higher if we resist the outside reality. The greater the resistance, the greater the cognitive dissonance.

As testers, we love playing with biases. We try to recognize when they are present, we do our best to de-bias ourselves, and then we feel smugly superior that we have gotten beyond all that. I question that premise, because I think that there are several layers of bias that we need to work through. There's the superficial biases, and then there are those that associate with the core of our beings. Some of these biases are not so easy to set aside. Take belief in a higher power. I have no problem with feeling there is one, regardless of now illogical or irrational it may be. I've had many experiences in my life that have convinced me there is one. For other people, they may have had the exact opposite experience. In a scientific approach, there is a far greater burden of proof on me, in that I cannot prove that there is a higher power. Were I totally rational, I would then say "well, then there isn't one"... and I'm not willing to do that. I understand full well that that is a bias in action, and it is a bias that I can play with, I can consider, but at the end of the day, as it stands right now, I will not put down. Not really. That's how powerful that bias is, and that's why I struggle when I see things that contradict my view, and feel at ease when I see situations that confirm my view.

I sometimes feel smug when I discuss cognitive biases surrounding politics, because it's so easy to see which biases are being applied on both sides (I'm from the USA, so for all practical purposes, there are two (arguably) separate parties with different views of the world). Some people are partisan for one party or another. I've decided to have no affiliation with either, so I can step back and see both the intelligent and ridiculous when it comes to political discourse.  I can see the biases in action, but more important, I am at a point of indifference where I can be dispassionate either way. By having this outlook, I can more readily see the fallacies and biases in action with other people. The more closely I've held a bias, the less likely I will be objective with my observations.

Think of the old television program "Let's Make a Deal". For those who don't remember this old game show, one of the premises was that there was a part of the show where a contestant could pick from three doors (Door #1, Door #2, and Door #3). Two of the doors have goats behind them (iow, no prize). One door has a brand new car behind it. We make a choice, and someone else makes a choice. We see that their choice is wrong. Do we change our decision, or do we hold our place? The Status Quo fallacy tells us to hold on to the value we have, because we have a 50/50 chance at this point, but we will very likely hold onto our original choice, and not change it. Why? Because we've already made a choice, and the surety of our choice is more comforting than making a new choice. The odds are equal either way, but most people will not make a change even though the odds are even that they have made a right or wrong choice.

In the world of finance, we are often affected by the Loss Aversion Bias. What impacts us more, receiving something of X value or losing something of X value. Most people react more strongly to loss then they do to gain. Studies have been done (sorry, don't have them off the top of my head, you'll have to trust me for now ;) ), that it takes an almost double level of gain to negate the feelings of loss. Mathematically, it doesn't make sense, but we value the loss more highly than the gain, or perhaps we more acutely feel the loss than we do the gain.

Imagine that you have a chair in front of you. You are asked to draw the chair. Taking out the relative artistic skill of the people drawing, what might we think the outcome will be? Each of us will draw the chair from a slightly different perspective, depending on where we are sitting, but generally, we will draw a chair, because we know it's a chair. Now, let's imagine that we can somehow lose all perspective of the fact the item we are drawing is a chair. It's a form, we can draw it, but we lose all perspective of the item being a chair... do we end up with something different? Can we separate our view? Do we make something different? Chances are, we make something simpler or abstract; it's just a shape. The strange part of this for me is mentally blocking out a shape that I *know* I am seeing. What's interesting is that, for some, they were able to make a more accurate representation of the chair when they were trying to defocus from what it actually is. Others went with a simpler and more freeform design.

From Reality to Obvious

There are steps and filters that shape what we consider to be obvious. Reality is what exists, regardless of our feelings of it. Obvious filters through our experiences, our fears, our frustrations, and our beliefs. Therefore, what is "obvious" to us may not be obvious to someone else, or at least, not in the same way.

“We don't see the world as it is, we see it as we are”
― Anaïs Nin

If you want to test your biases, here's a process to play with:

- State an hypothesis about how a given product should work to meet a customer’s needs
- Define a set of question to validate/invalidate the hypothesis
- Define metrics in respect to what type of answers received
- Collect facts
- Present results

Does this look a lot like the scientific method? It should, because that's really what it is. If we are applying the scientific method appropriately and honestly, the process behind the scientific method will help us defocus our biases. It may not entirely eliminate them, but it is very likely going to make you aware of them.

Nowhere and Back Again - Live from #AgileTD

Today's middle of the day Keynote is being provided by Thomas Bradford. You have to love a guy that describes himself as "a Certified Software Organization Failure Expert, and has personally witnessed the implosion of dozens of organizations. He is dedicated to creating a world where those organizations don’t drag good people down with them."

Thom worked for PayPal, and was looking for a new opportunity. He was contacted by a friend who was describing a company that needed a lot of help. He declined originally, but ultimately, he gave in and decided "OK, I'll see what I can do to help!" He grilled the company asking what they would be willing to do. They had zero tests, and needed someone willing to come in and help them resolve that. Through some continued conversation (and perhaps a few insults here and there) he said OK, and took the job.

The company's product was a Java monolith. It was a mess, and it had methods that were five hundred lines long. Ultimately, they decided to move away from the monolithic app and convert it to micro-services.  He also suggested they walk away from the app they are developing, moving off of Java and coding a replacement in NodeJS.

Key takeaway:

If someone told you you could be twice as productive at work, what would you say? Would that excite you, or would it actually terrify you? It's not like you are going to get more money, have to work less, or get any real benefit out of it (well, there is equity, if you are lucky). Truth is, most of us who work in tech aren't doing bad, realistically speaking. We tend to be paid pretty well, but we have also inherited a lot of dysfunction because of this need for speed. Agile itself doesn't really fix that. Not by itself. People have to decide to do better because they want to make their lives better and the lives of their customers better. Sometimes that means doing something totally insane, like burning down your original infrastructure and starting over.

Sometimes it is essential that we break free of our comfort zone. When enough people create comfort zones, they create entrenched processes that are often inviolable. They are safe, but they are non-productive, regardless of what the charts and reports say.

The key to the success is being willing to start over, to stop doing things that are useless, and put the value of people over process. If the organization cares about the process over people, you are not in a good place. Sadly, that's probably 80% of companies, but someone has to be brave enough to say "enough".

Test Management Revisited - Live from #AgileTD

Today's theme seems to be BBST remembrance. Selena was one of the participants in my first BBST class, and Anne-Marie Charrett was one of my instructors for that class. In many ways, I've always considered Anne-Marie one of my favorite teachers, and therefore, I tend to make a point of attending any of the talks she presents at any conference I attend. To date I have not been disappointed, and I have no reason to believe today will be any different :).

The Main Statement for Anne-Marie's talk is "Test Management is still vital for large organizations but it needs to be re-invented to be able to work in an agile context".

In my own world, I have been a Lone Tester more times than not, so Test Management was by default my domain. Today, I am part of a small team that has two dedicated testers, one contractor who does automation almost exclusively, and a bunch of side stuff that I do as well. Test management happens, but it's probably a bit more haphazard than I would like.  In that guide, it helps to think about what Test Management actually means. Test Leadership might be a better terminology.

When Anne-Marie started at Tyro Payments, she joined a team that had five testers as the test manager (and then lobbied to be called the test lead). Tyro prided itself on being a very Agile shop in the programming sphere. As you might guess, the testers were *NOT* Agile (sound familiar? yeah, I'm sure it does). This is what happens when testers are treated as a control, but are not perceived as being part of the overall programming flow. The developers were doing lots of automation and also some of their own manual testing, so why did the company need testers again? Anne-Marie came in to help solve this problem.

The first thing that Anne-Marie focused on was creating a culture for the testers to decide who they wanted to be and what they wanted to be perceived to be. the team wanted to be autonomous, responsible, autodidactic, be able to identify an effective test process, and to be courageous. Anne-Marie introduced a lot of coaching, and generally coaching is focused on specific tasks. As a test manager/leader, the coaching works best when a specific task is being performed, and the coach can be there to give 1:1 feedback. Having experienced Anne-Marie's coaching first hand over the years, I can say that this is probably a really cool experience.

This type of opportunity worked well with a smaller team, but as the team grew and developed, there started to be a break down in the effectiveness of the approaches she was using. Doing 1:1 time with a team of ten is rather hard, if not impossible. At this point, Anne-Marie decided that they needed to look at an alternative to the approach they were using. One of the key decisions they made was to delegate a lot of the traditional test management responsibilities to the rest of the team. They created a Trello board and asked everyone to take over key areas like hiring, training, retros, reporting, etc. so that Anne-Marie could focus her attention on the area she was best suited for, which was coaching and mentoring. She also allowed the decision making to be delivered down to the teams, so that she didn't have to make all the decisions. This worked until the team got larger once again. Delegating the tasks was a help, but now with fifteen testers, the coaching was becoming rote and check list oriented. How can she get back into the key area she wanted to be to help people get skilled up?

Slack was a lifesaver in the company, even though the company was anti-electronic communication. The test team decided to buck that trend, since the team of testers was becoming more distributed. I completely understand this, as my company lives and dies by Slack ;). The other benefit of a tool like slack is that it captures learnings and sideline conversations that can prove to be very beneficial later on.

A challenge of being a tester is that a lot of the work we do goes unrecognized. If we have worked well on a product that is in good shape, who is going to know what you have done. As Anne-Marie points out, if you don't tell your story, someone else will tell your story for you. Reports will likely not be read, but blog posts have a lot better chance of being read (I can attest to this :) ).

And they grew again, and the system started to break down again. Noticing a pattern here? One challenge of delegating and allowing people to make decisions is the fact that they WILL make decisions, and some of them you WILL not agree with. It's vital that you can be OK with that, or at the least, have a chance to share your thoughts but still be willing to step back and let others make decisions and grow. A cool quote to remember is "when a flower doesn't bloom, you fix the environment in which it grow, not the flower (Alexander Der Heijer).

Infographs were a modification that they started to use rather than create standard status reports, and they were able to visually represent things that were oftentimes hard to describe or demonstrate in other means.

As of today, Tyro has twenty two testers (up from five) and the changes and modifications are consistently coming. They have to keep adapting and changing their approach, and ultimately they want to break down barriers. In short, they have learned how to pivot, and going forward Anne-Marie hopes to look at listening to her organization and better understanding their needs.

Ultimately, testing is a practice, like medicine. It's not up to the doctor to keep you healthy, but they can help you if you decide you have something wrong and need help. keeping healthy is ultimately the person's responsibility, and in an organization, testing is everyone's responsibility as well. Test practices are there to help when help is need, create information and sharing that information. The test team is a brand, and it needs its own sales pitch. It's vital to think about how you and your team is perceived. Doing good work is not enough.

There's a lot of things we can do to make test management effective. Ultimately, that needs to be the primary goal.

Agile Leadership Lessons - Live at #AgileTD

Selena Delesie and I have known each other for about five years. I met Selena as one of my co-participants in the BBST classes, and we have had an ongoing correspondence and bumping into each other at events over the past few years. Selena has focused on being a coach and a consultant. She has a broad range of experiences and a unique presentation style, and I'm excited to see her delivering a keynote today :).

Ask yourself, if you could have dinner with any person alive, who would it be? Why? What do like about them? For me personally, I'd like to hang out with Gerald Weinberg and earn a bit about how he got where he is today. I'd also like to hang out with Larry Winget for awhile because I think he's a hoot and his personality is bigger than life.

Selena emphasized that her "must meet" is Richard Branson, and while she didn't get to meet him directly, she did get to interact with him at an event she was attending. She said that some of what she admires about Richard is his ability to listen deeply. We tend to want to make our views known, and by doing so, stake our claim on our knowledge and experience. More important is being able to listen deeply and learn to understand the challenges people are facing. My expertise doesn't matter if the expertise I have won't help the people I'm conversing with or hoping to lead or help.

How can we improve on collecting information and ideas? In general, the best thing is to just stop and listen to the people we are working with. Ultimately, it's all about the people on your teams that you work with. It's important to realize that, if you are going to be a technical leader for a team, your goal is not to make yourself shine, but to make the entire team shine. As a leader, your goal is to help other people be successful. If that's not your thing, you need to consider a different line of work. Additionally, do all you can to make people smile. When people smile, they open up and amazing things happen.

Who can you improve your relationship with? For me, I think it is important to have a good overview of the business as a whole, so foster relationships with people outside of your immediate team. Build relationships with people who can help you understand what is happening in the entire organization. As you learn what other people in your organization deal with, and what their pain points are, we can help alleviate that pain, or look at our work differently.

Be addicted to learning. Discover what domain knowledge exists in your organization, and be prepared to go where the needs are, rather than just what you want to do. For me, the most pressing need in our organization at a time was to understand the entire build process for our software, and that led to me becoming the release manager for our company. Do i know everything about the process? Hardly, but I have a chance to learn and experiment regularly, and provide basic improvements to the process here and there, and that's made a world of difference in my work reality this past year.

We don't learn by following rules. We learn by experimenting, by doing, and yes, by falling over and getting back up again. It's a challenge to learn new things, especially in areas that are not comfortable to us. It's also important to carve out the time to get good at what we do. Part of that requires us being willing to say "how may I be of service to you?" It's not enough to just show up and do things for our benefit alone, we need to be wiling to be of service to each other and our organizations.

Another question to consider is "what problem are we helping to solve?" One member of the audience said "harnessing all of the brainpower of the organization". Another said "to get a better shared understanding of the software we are developing". Another said "hiring more team members". For me, it's "making sense of the infrastructure and feature needs to help identify the real critical issues that our customers need".

Agile means being adaptable and flexible, and yet we still find that old habits die hard. We may think our teams are agile, but in many ways, there is a lot of tradition and process to overcome, and many of the methods we use are often counter-productive. Remember that change is a given, but how you respond is a choice. Don't be afraid of adapting and trying something different.


Early Morning Pub Chats - Live from Agile#TD

Day three. Lots of conferring, lots of fun, way too little sleep (LOL!).

It’s always a challenge going to these events because my body fights the local time. It’s frustrating to realize that it’s two AM local while your body still thinks it’s 5 pm at home, and regardless of what your body thinks time is, 6 a.m. local time will arrive and it doesn’t matter what your time back home is, you have to get up and go.

This is the third Lean Coffee of the conference, and will sadly be the last. I enjoy thee gatherings because we have a totally impromptu discussion on topics I might not have considered asking about, but I learn new things each time.

Target Coverage and How to Get There:

What do we do when we have a long term team that seems to work everything out of their heads? The challenge is when we are trying to get a baseline understanding of the coverage that is being applied. How much testing is actually being done? Do we know? can we figure that out? How do we implement an approach that lets us see what is being covered? There are a variety of Code Coverage tools out there, but that helps if the people doing the primary testing and the code optimization are the same people.

However, in the case of the person presenting their dilemma, those are not the same teams. They are automating acceptance tests as they are creating them, but their legacy system doesn’t have much in this regard. the trick is that coverage is often hard to quantify. If the idea is statement coverage, that’s easier to get a handle on since unit tests can give you statement coverage, but test coverage is a bit more nebulous, since there are so many potential permutations. Using an API testing approach can help to fill in the blanks here. Buy setting up tests that utilize the service layer, many of the business rules can be automated or exercised through the API rather than trying to use the UI for this. visualizing coverage (drawing diagrams of the workflows) can help to make the visibility of areas to test more clear.

Coaching Developers to Test Earlier:

With the idea that Agile encourages testing being an activity rather than a role, many developers are getting into the role of doing testing as well as writing code.

Kim mentioned that there has been a challenge in her organization with trying to help the developers get into the habit of testing. From my own experience, there needs to be buy in from the programmers to ensure that testing is happening with the programmers. There's a benefit to asking the programmers to share their unit tests with you, the tester. By asking about the unit tests, and saying that we need to see what is happening so we understand better what is being covered, it sends a clear message.

Also, in our organization, no story is considered done if there are no unit tests or integration tests written by the programmers, so that helps make sure that unit and integration testing are done. For many programmers, they consider that "enough", but there's a lot more we can encourage them to do to test as well as having us do explorations and cover other areas. It's really helpful to communicate that we are trying to not be a bottleneck, so having the group work together to cover testing needs and to spread out the testing effort among the whole team helps encourage that philosophy. Some programmers will be resistant, but if the cultural expectation is that everyone tests, then we can get everyone else involved easier.

Distributed  Testing and Team Integrity:

A challenge with teams that are distributed is that many people fall through the cracks and the sense of team unity disintegrates. When testing gets spread among a number of groups, and people are assigned to different groups for differing periods, there's a struggle to get everyone to share what they are doing, specifically domain knowledge. The idea of sharing ideas and developing a "community of practice" can help here.

Having a rotating book club, or getting the testers together to say "what are you all working on, and would you be willing to give a quick summary of something you are learning?" Lean Coffee is actually a great mechanism for this. It can be a challenge to have teams that report to different managers, so it may be helpful to get the managers on board with the community of practice concept. The key is that there needs to be  real knowledge exchange, not just another status meeting to have to sit through.

What's New in Agile Testing?:

The area of DevOps and Continuous Delivery is an interesting avenue that is becoming more prominent. Containerization is a hot topic, and the tools discussion are able to become a runaway train very quickly. there's always something new and shiny to get involved with, but the principles of testing in an Agile context are still pretty consistent. The real newness is the experiences that people are bringing to it. Agile itself is not exactly "new". It's fifteen years old now, which in technical terms is fairly ancient. For each organization, though Agile may be brand new to them, and there's lots of opportunities to go in and have a broad range of experiences. Tools come and go, and what's the new hotness one year may be old hat the next, but each organization gets the ability to try those things as they mature and determine what matters to them.

Sad to realize I won't be doing this tomorrow morning, but fun to realize I have lots to ponder and consider when I get back together with my team. Thanks for following along, day three proper is about to get underway.

Wednesday, November 11, 2015

We're all Searching - Live from #AgileTD

One of the interesting things about being a member of the “Twitterati” is that a lot of people can get to know you and what you represent, and they can get a good idea of who you are and what you look like. Mike Sutton spotted me from about 20 yards and yelled out “hey, it’s Michael Larsen, the TESTHEAD! Good to see you!” When I noticed it was Mike, I gave him a big hug, and we chatted for a bit. It was an awesome experience of two people who knew each other but never met knowing enough about each other to be fast friends in person.

Mike started his talk from the premise of asking “How much do you really care about your organization? Do you really care enough to test beyond the basics of your product? Are you willing to really go down the rabbit hole?"

Can you say that your work has an enormous impact on your personal growth and joy? If so, that’s awesome. If not, why not? Do you have the power to shape your work so that it can bring you joy? Mike’s not trying to make this sounds like some twinkly stardust idea, he’s saying that we put so much of our life energy into our work, we should do all we can to make it be something that brings us joy and purpose. If what we do is making us miserable, we should do what we can to either find joy in it, or break free and find a place where we can experience joy.

Mike’s core point of his talk is searching. Growth is challenging, it can be painful, and it can be frightening. but growth is what brings us new experiences, and new experiences can bring joy if they are positive. Companies do the same thing. They make be searching for revenue, for people, for markets, and each level of growth makes the search that much more intense.  If everyone is searching, and everyone is, what does that mean about what we are searching for? What does this search impact? In short, what do we care about, and how far are we willing to go to follow through on our search?

To be frank, most of the time, when we make a business decision, we are effectively making a guess. It may be a really well educated guess, but ultimately, it’s still a guess. There’s enough variability in the world that we don’t really know what will happen when we do most things. Chemistry is one thing, emotional economics is something else entirely. Agile teams are ultimately places we can roll with different guesses. We don’t have to take the safe gamble or structure things in a rigid fashion. Agile asks us to experiment, and if we fail, let’s learn quickly from it and regroup. Great in theory, a little more chaotic in practice. Development may be agile, but what about the rest of the organization? Are they harmonious or are they cacophonous (yes, I’m referencing yesterday’s keynote ;) ).

Think about what you are great at. Most testers love exploration. We are curious as cats. We have a passion to collaborate, and ultimately we want to make things better. That’s second nature for our software, but why isn’t it second nature for our organizations? Are we as willing to poke at the holes of our organization? If not, why not? Is it from an informed place, or is it from fear? Are we scared of what might happen if we explore our organization? Do we run the risk of offending others? Possibly, but we might discover something important.

We don’t nee to ask permission, though we may want to make sure we’re not breaking something that could get us arrested. Be OK with the fact that some people will not approve, but if you are willing to test the organization, you may find that you discover something deeply valuable to that organization. Counter intuitive? Maybe. Start asking what value we provide. Why do we exist? Beyond the money we are earning, why does our company exist? What kind of organization do we want to have?  Dare to ask, and let's take on the ultimate testing project. Find out what makes your organization tick, and find the bad points as well as the good points.

Ask questions. See where they lead :).

Designing Inclusively - Time Delayed from #AgileTD

As you might guess, it is not possible to live blog and present at the same time, and the network has been dropping frequently with the number of participants, so I'm a little late getting this one out ;).

My talk was about Accessibility foremost, but I also made some recommendations to consider using Inclusive Design to help the process. With this being an Agile testing conference, it fits well with the idea of moving the testing forward. Rather than trying to shoe-horn Accessibility after the fact, what about designing up front with the idea that you will make your products effective for the broadest number of users as possible. Wouldn't it be great if you didn't have to make special accommodations for that, or have to make multiple paths to make that happen? Inclusive Design makes that possible.

Accessibility deals with the absolutes on the disabled scale. The fact is, an app that is visual will be unusable for a person who cannot see, unless special accommodation is made to allow for interacting with assistive technology. For many of us, we may be able to see, but we may be developing challenges around the clarity of that vision. I fit that model right now. Readers are a part of my reality, whether I like it or not. Anything three feet away from me? Crystal clear. Anything within three feet? I start to lose clarity. Text? Ugh!!! I've gotten to the point where I have to have readers to interact with my phone.

What I've described is what would be considered a secondary, or situational, disability. I'm OK in most cases, but for a particular range of interactions, I need help. I don't need Accessibility level of interaction, but there are some methods of displaying information or controls that would make my life a bit easier if I don't have to dig for my glasses every time I want to look at my phone or my computer.

I highlighted an app I am currently using, and that several people have heard me discuss on my blog in the past couple of months, called LoseIt. It's been a terrific app for counting calories and tracking exercise, and it's helped me meet a key goal, that of losing weight and getting into better physical shape. Additionally, I appreciate the decisions that LoseIt has made, intentional or not, to make many parts of their app usable by a broad group of people, even those of us who struggle to read small screens and even smaller type. The main screens are accessible with a side swipe, and the main displays are based on dials, sliders, pie charts and bar graphs. What does this mean? A lot of information can be communicated in that small space without my having to hunt for my glasses. Yes, the areas where I have to interact intensively I still need them, but for a quick glance at overall stats, the displays are such that I can look at them and get feedback that is meaningful even without my glasses on. That's a good example of inclusive design in action. I have no idea if LoseIt did that for that purpose (and truth be told, if they did, they could use some bolder contrast options) but it's appreciated nonetheless.

I had some fun questions after my talk, and a really good point was made by one of the participants, in that she told me she was working with a company that developed games for young children, and that try as they might, they were not able to effectively test the games at a level that was effective for their target audience. She likened this to the limitations of testing with personas for other disabilities, where we can imagine that we understand the issues, we can empathize with the issues, but we can't really be stand-ins for those individuals and the challenges they may have or the development level they are at. I agree completely. At the end of the day, I will likely never be able to listen to a screen reader at the speed that a friend of mine who is sightless can listen to it and make sense of it (literally ten times faster than the default setting). We can be surrogates, but we are ultimately poor surrogates. Our experiences in their shoes can help, but it can't replace the feedback they can give.

In-Famous Plethora of Piñatas - Live From #AgileTD

Oh, come on, did you really think I could attend a workshop based on the Three Amigos Principle and not reference the Chevy Chase, Steve Martin and Martin Short movie? All right with that out the way ;)...

Sure, we all have heard about the principe of the Three Amigos meeting. Many of us may actually participate regularly in those meetings (it's a core part of every story kickoff where I work) but do we really utilize these meetings in the best way? When I saw George Dinwiddie and Stephan Kämper were presenting a workshop on this topic, I had a good feeling that this would be time well spent.

What does the Three Amigos mean to you? In my organization, three amigos are fairly well represented and consistently so. In our organization, we have a programmer, a product owner and a tester. Each kickoff has a review of the story in question, and we look at the story in question to voice questions and concerns. It's a time to talk about basic implementation, but not specifics. It's a time to ask testability questions, and to see what assumptions have been made and what ones haven't been made. After we have all had our say, we consider the story kicked and away we go. That's fairly typical for us. It's worked pretty well, but could we do better?

Though I think we have done a pretty good job articulating the stories and their details, we might be more prone to rubber stamping when we get the same people together too often. I'm not saying this is deliberate or in some way nefarious, but it's a natural by-product of how we work together and get to know how each other works. Occasionally, we can all miss something because we've gotten a little too comfortable with the process.

Several questions to consider when it comes to the Three Amigos approach are as follows:

  • What might happen if you have fewer or many more than three participants?
  • What is different about the viewpoints of the business, the programmer and the tester?
  • What other roles/points of view might be useful, and why?
  • What could you do if one of the the roles was not available? What are the dangers to avoid?
  • How should decisions be made? Based on merit? Democratic? Other? Why?
  • Should the Amigos document something? Why or why not? What? How?

One of the more telling examples we shared was the ability to communicate requirements "blind". In the process of trying to share requirements, three easels were set up, one with a diagram of the requirements (a triangle, a square and a circle that overlapped). The goal was for one of the participants to describe the shapes and their placement, and their ability to communicate the requirements effectively to others. As you might guess, no one had the same image. When all was said and done,  Communicating requirements is hard.

We are on a break at the moment, so more when I get back (this is the first part of a two-parter :) ).

In the second part of the hour, we are looking at a Global Parking example. This is significantly more involved than the simple example we tried before the break. While we worked through and tried to discuss the requirements and semantics of the document, we started considering a broad range of questions. Among them were:

  • What was our Shared Understanding?
  • Did we use a Common Vocabulary? (short answer: no ;) )
  • Could we describe the rational of our decisions?
  • What are the "rules" of the system?
  • Do we have examples that illustrate those rules?
  • What assumptions do we have based on these discussions? Do we have questions that developed by reviewing the document?
It's been interesting to me to see how many of the interactions with my team in similar situations were much smoother because we had a shared set of tacit knowledge. I could imagine our meetings being much more involved if we were to bring someone in cold in one of the roles who had never been part of the process, more so because they don't have the shared history of the team to draw upon. That's a powerful undercurrent, and it should not be underestimated. This exercise took significant time to clarify meaning and make sure we understood each other and our assumptions. I can see in teams that are more in sync with one another that friction being much less. 

One thing that was very helpful is the idea of "Example Mapping", where we too the basis of the story, determined rules of the story requirements and created individual examples that mapped to each of the rules. By doing this, we were able to block out the needs of the app, and some questions that we developed by blocking out the examples and mapping them to the rules. This is a technique I have never used before, or at least not in this manner, and it looks like something that would be tremendously helpful as a preparation for a Three Amigos meeting. As a tester, it could be very helpful to confirm if the rules are essential, or if there are things that are out of scope. If you notice you have a lot of examples, maybe the story is too big. Could you split the story into one story for each rule? How about one story for each example?

This Example mapping is a method of "testing before development", or as Jon Bach once described to me, an example of "provoking requirements". He doesn't mean that he's being deliberately confrontational, but that he is looking to talk out the requirements, and be sure that we understand if the requirements as we think they are presented are understood, as well as communicated.

the last part of the workshop was an example showing how to use Cucumber to automate a test scenario. Though this workshop is not a Cucumber workshop, it's a good follow-through to describe how the process could be used to generate test steps and the automation that could happen based on the requirement requests.