Live from Potsdam, Day 3 - Agile Testing Days 2017

Morning came at the usual time in Potsdam on November 16, however many of the conference attendees missed its arrival as they had been having much fun following the Agile Games and ATD Cabaret. Much singing and music and jokes and fun was had, and SOME (ahem) were feeling the effects a bit more than others....

Still, that is one of the aspects of this conference, and many conferences. People getting to know each other, swapping stories, asking questions, sharing ideas and sometimes sharing advice.

One aspect of this, beyond the evening events and other random conversations that grow organically at events like this, is Lean Coffee (introduced at ATD by Lisa Crispin & Janet Gregory). I mentioned this in the Day 1 blog and today, after inhaling a quick breakfast (someone was up later than intended... ahem) I wandered in to see how Lean Coffee was going, and was pulled into moderating a table. OK! Dive in head first!

What is Lean Coffee? It is a time blocked method of discussing ideas, problems or exploring questions where people bring topics, vote on them, then discuss them until a resolution is reached OR the energy for the topic has been expended. The idea is to share ideas, investigate things the original person had not considered and come to a take away.

**

I've moved into the main hall for the morning events. Jose is going over "lost & found" items (including someone's tablet - THAT will be missed!) Ash Coleman is talking briefly about the events later today around inclusion and diversity. AND we're getting ready for this morning's keynote, The Pothole of Automating Too Much with Paul Holland.

Paul is kicking off his message that (for the opening aspects at least) is challenging the conventional wisdom held b y many: Automated tests are not likely going to give you all the benefits that many people believe it will.

Automated scripts will only look for the things it is programmed to look for. It takes a vigilant human to find other things. He uses a metaphor around the roads of the United States for software.There are so many raods (paths) we can't really "test everything.


Right.

Problems - 
There are more kinds of problems that an automation can be programmed to recognize...
  -  Vigilant testers can observe and evaluate a very large variety of outputs and also vary the inputs let us find more problems than we can predict.

There are more checks to automate than can possibly be written;

Some things are too difficult to automate effectively;
  -  Complex pass/fail algorithms;
  - perhaps it can be dome more quickly by a human;

Investigating reported failures takes a long time;

Automation is expensive to build and maintain;
  - High cost to value ratio;
  - Sunk cost problem (so much spent so far, abandoning it is hard)

What about -
A strategic mixed approach:
  - Automate critical paths;
  - Automate paths with the highest use;
  - Do NOT write automation for all failures found in the field;
  - Consider the cost of automation vs benefit -
     Difficulty to create;
     Difficulty to maintain (frequency of changes)
     Difficulty to analyze failures;
  - Augment automation by performing human testing
  - Automation is excellent at showing that the code CAN work;

**

Grabbed some lozenges, and a coffee and headed into Toyer Mamoojee's session on "Coexistence of Legacy and Cutting Edge Technology Systems". AND - the conference staff bring in a birthday cake for him! Yeah. these folks are awesome.

I met Toyer Monday evening, after having been told I needed to find him and have a chat - and we did! Bright tester from Cape Town, South Africa. I am really looking forward to this.

Here we go -

For this discussion Toyer is defining legacy systems as:
Business Critical;

Lack of support;
Skills shortage;

... and a couple others I was too slow to type...

so why keep them?
Customized over time to the Org;
Change could negatively impact business

Their environment looks a bit like this:

Problems?
Oh yeah...

Deployments are manual (very manual);
Achitecture - Too much logic build into legacy systems to easily update/decouple;
Processes - Slow running processes, including tewsts;
Delivery Process - Some teams less Agile than others...
Skills - Different systems required different skills.


Solutions -

Their approach (over time and not this neatly - Pete comment - they never are...)

Deployments - Automate, automate & Automate;
Achitecturally - Built APIs, Micro-services, Rewrite complex batch processes;
Processes - Faster Running processes, quicker test execution;
Delivery Process - Functionality, Freeze, E2E meetings, SOS (Scrum Of Scrums)

Skills - Internal vs External recruitment (right skills for the right system)

Testing -

Automated Testing -
  Automate what you can with commercial tools for legacy;
  Open Source for Cutting Edge/newer tech
  Push to get CI/CD;
  Automate at different levels!

E2E Cross System -
  Centralized E2E testing tool;
  Daily SOS meeting
  E2E Meeting before stories get developed (measure the impact on teams)

So, what was the result?
Originally, they had Excel for test case tracking  & QTP.
and now...

And the result?
Cross skilled workforce;
Everyone engaged, relevant & up-to-date;
Get the right people on the right system;
Maintain/expand buisness competitive edge with less risk;
Faster delivery time - monthly releases instead of quarterly

**

Some good chats, dealt with some minot work items AND slide into "An Alien Visiting MY Office" with Viktorija Manevska. (a little late... sorry)

Starts a new job - AWESOME! And she hears they are going to do Scum - AWESOME! And she learns how they are doing it - AWESo... uhm

So, she went and took on the task of reading and learning about Scrum. She found the typica; "THIS WILL SAVE THE WORLD" articles and then some that were less than enthiusiastic.
So, she looks at what is around there. And how people look at things -
So, since she knew that things weren't quite right - so she decided to get a certification (cultural thing - certifications lend greater authority - your mileage may vary).
Except, things still weren't quite right. Stuff wasn't happening the way it seemed like they were supposed to be.

Except - Scrum is not a problem fixing framework, It is a problem FINDING framework.

Key question...
Is the value of the product developed by Scrum?  -  Hmmmmmmm

Except Scrum is a bit like the blind men and the elephant...You see scrum based on how it is exposed to you. Hmmmmm.

So, if we know what the customer wants and we have some ideas on how to make this happen, does the development method/model really matter?

So, if we focus on the end result, what can happen? Working together, not worrying about the ritual forms, what if we share ideas and collaborate and not worry about what to call it? Instead of doing a daily stand-up, particularly when people are all working in the same room, what happens if we just do stuff?

THEN she lands a new position (same company) and finds out that.... not so happy. The rainboes & unicorn thing was more a tangled mess. She began looking at items, making mind maps and researching the intent of the such things and.... "that is not your job - you are a tester."

Quotes Paul Feyerabend - "The only principle that does not inhibit progress is: Anything goes."

So, she let them go and do their thing... Allowing people to fail, then supporting them when the problems arise can help them begin to change their minds from fixed positions to a more flexible one. By working with them to find shared spaces - they began coming to her to find potential problems before deployment, then pairing then... everywhere.

By looking at things from an external viewpoint, like an alien, she was able to see problems, then share the means to help people see things the same way.

**

LUNCH!

**
Slight change in plans. After an amazing chat with Cassandra Leung over lunch, have I mentioned how remarkably bright she is? Right - I must rest a bit... and deal with stuff from work - yeah, day-job stuff. I hope to spend some time in the open space shortly.

See you all in a bit!

**
And Congratulations to Jose Diaz - the master behind the conference - for officially becoming a German Citizen today!
**

Sometimes taking a nap is an excellent thing. Other times, having a nice relaxing cuppa (or 3 or 4) and conversation with interesting people Can be just as good, if not better. Thanks to Rob Lambert, Alex Schladebeck and Chris George for giving me much to think about.

Open Space is an excellent way to explore ideas and have a chat with people about items you may not have considered.
**
Sliding into the LAST track talk of the day (refreshed and ready to go!)
Our Journey to Reduce Manual Regression Tests - presented by Thomas Fend and Trinidad Schmidle.

They work at Bachmann Electronics, a company with a broad product portfolio, long lived products, a development team of around 40 developers and 12 testers. The majority of their software products are released at the same time, typically once a year.

There is a fixed issue verification system that tends to go straight to the tester. The were massive numbers of bugs being reported, however, when the development team reported a as "fixed" it went straight to the test team, not to the person who reported or raised the bug.

By changing that loopm so the person who raised the bug had first crack at the fix, or at the lease, had the change explained to them, they were able to streamline the process and reduce the amount of rework. THIS lead to more time to work on more new features.

Now, with a common acceptance criteria definition, the team & product manager are in agreement as to what needs to be done.

Then there was the "feature veto" issue - Features are completed very lat with little time for thorough testing. When everything else seems to be better, the tester might raise bugs, get very unpopular and get told to leave them alone.

By getting testers involved early in the process, this has been reduced.

Then there was automation. Yeah. Some tests are executed each sprint. The BIG ones are run after feature freeze - once a year. Not all the tests are fully automated - there would be manual configuration before starting some tests. Because, well.... yeah.

Each sprint, testers present test results in the test department. As an incentive, the number of tests being run each product cycle, through automation.  Result was increasing to around 65% of the tests.

This helped improve stability, helped find bugs when there was time to fix them, and help find and fix "blocker" bugs.

There was limited time to make regression test really happen. So, they pulled in developers to help. This was PL, but...

By working together, working on some basic action - the time to regression test dropped dramatically. They also reduced distractions during "test weeks:, no meetings, etc.,

By introducing a mix of static and dynamic code analysis to check out the changes that have been made, they were able to restrict the interruptions, limiting meetings, encouraging test pairing, etc., They were able to reduce the amount of effort to do regression tests and do them far more efficiently.

Conclusion - Through communication, teamwork, detailed planning and focusing on things needed RIGHT NOW, they were able to make this improvement where they can run the full suite in under 2 weeks!

***

And NOW the lights come on in the room. It is REALLY hard to see to type with no lights (ahem)...

 

Right - something else is coming up, - AH yes - the closing keynote of the day with Liz Keogh.

**
Jose is back up with a few announcements and introducing Liz...

Liz Keogh will be speaking on "How to Tell People The Failed and Make Them Feel Great."

And asserts that Failure is Essential. Whilst on a project, a couple of developers had tried to install a tool to help do testing. It took a couple of days and they gave up. And got yelled at. And new rule was implemented that NO one did anything without getting permission from the BAs. Except - they made that rule for EVERYTHING.  All creativity ceased. And it became a far less fun place to work.

Enter Cynefin - (the new version)

Obvious Domain - sense-categorise-respond ; Best Practice(s) -
Complicated Domain - sense-analyse-respond ; Good Practices ;
Chaos (Chaotic) Domain - act-sense-respond ; No effective constraint ; Novel Practices
Complex Domain -probe-sense-respond ; Enabling constraints ; Emergent Practices ;

Dan North - deliberate discoveries
Unknown unknowns - 2nd order unknowns

You failed - but we expected to because... and that's OK...

We want to help people improve. Before we go nuts with this, consider what do you like about the person - how about respect them? What is it that anchors the relationship? What is it that  you value them for.

There's the sandwich thing - where you put "the problem" between 2 good things. That's ok - sometimes...

But why - if they screwed up, they probably know it. Let them know that you know, and that they have succeeded in the past and will be awesome again;.

Radical Candor/Care - come out and tell people something is wrong, but come from a place of care. Let them know the person is valuable and valued, and they can make some small corrective action and be awesome. Because SOMETIMES not doing that will lead to much bigger failures.

Failure only "hurts" because of the impact. Safety lines can help - and can help people explore safely. Always work toward buying time - making time - by avoiding the trap of "running out of time" - allow yourself options, just in case.

Remember that "root cause" is misleading. There are usually (often) multiple contributing issues. Sometimes they may not be obvious. What can these things be?

Try scattering around ideas. They MIGHT just land and be able to be acted on immediately. OR, they may lay dormant for a long time, until the context changes. THEN it can take root and grow.

Etsy - home of the blameless review. This is an interesting idea - let's see - often times this gets translated as "the testers screwed up." One thing in the "blameless reviews" - or "learning" reviews - instead of  "who did what..." try "what happened" and "when were decisions made."

Take the blame out and look at the steps and decisions made. That might show opportunities to isolate the issue and act as a fail-safe. You will always miss SOMETHING - so mitigate the risk.

Most organizations struggle with Agile stuff, because stuff is hard. Changing directions can be a challenge. Supporting the ability to change direction is a challenge.

-- The best way to tell someone they failed is to not even mention the failure.
Come from a place of care. Anchor what is valuable. Show what is possible - the bright future ahead. Work on building safety nets.

All of this is part of solid, positive growth... unless England is playing in the football match

**

There are a couple of other items coming up this evening, but first, supper!

**

Live from Potsdam, Day 2 - Agile Testing Days 2017

Wednesday, November 15 dawned... well, not really. It was pretty foggy when the sun rose, so I'm not sure there actually WAS a dawn. However, it did get lighter. Conference attendees and participants made their way to the morning activities of Lean Coffee, a morning run and yoga (yeah, I know I did not mention the run OR the yoga in yesterday's post - mostly because I do not do either.)

There is a full slate of activities for today - keynotes, track talks, workshops - AND! Games! TESTING GAMES! Great fun.

Jose is finishing morning announcements and the keynote from Claudio Perrone is about to start - Popcorn Flow.

Interesting title slide - with "Change is hard, make it continuous!"

Here we go!

Operational excellence is not enough, Most ideas for software ideas (and others) are really... crap. Too many times we end up with crap ideas getting delivered really, really fast - because we get told that faster is better. Innovation is key - so you get crap delivered by jet engines or crap on a stick (with spikes)

So - we want to improve, Except Improvement, real improvement, takes change. and CHANGE is a bit like Godzilla. So, don't worry about Godzilla - he's pretty big. Look at single cell organisms, they are changing ALL THE TIME.

Popcorn Flow is an anti-fragile philosophy -

Popcorn Flow Principle 1 - If change is hard, make it continuous;
Popcorn Flow Principle 2 -Everyone is entitled to their own opinion, but a shared opinion is a fact;
Popcorn Flow Principle 3 -

OK - it is too dark in here to really type... so changed seats and now I have a bit more light - maybe I can keep up

Problems & Observations - What is getting in the way of innovation (or anything else)?
To beat inertia, everyone will see problems - when multiple people share the view that something IS a problem, it goes from an opinion to being a FACT. There is a shared view of an issue that is supporting inertia and getting in the way of not delivering crap.

You can form shared observations to create and elicit options (get a bunch of people, like 3 together and explore the ideas around. Experiment - like - "We might try BDD or Code Reviews or Paired worked to maybe make things better..."
    - pull quote! If there is salt in the cake, it is already too late! We can't fix it!

We can talk and agree on experiments, look at their expectation then TRY them! What is the result?

Set an expectation - then see what happens . Not meeting the expectation is not a failure - it is a correction of the anticipation.Be prepared for that form of failure - but - learn from each one.

Fail fast is not the point - LEARN fast is the goal!

The thing about "being agile" vs "doing agile" is not something to worry about -

(I perhaps celebrated a bit too much with my friend Huib... sheesh)

If there is a continuous flow of experiments (the core of agile) then what limitations are there? Some may work really well - KEEP DOING THEM - some may not work - STOP those, try something else.

Try "Here's a problem as I see it and some ideas that might help..." with the manager - then experiment with the experiment model.

DING! Quality is something we worry about - what about the value we get from something? Like, a conference talk? Does a "high quality" talk deliver value to EVERYONE? Or is value to the customer without regard of the "quality" of the presentation - or software (ahem).

Set yourself up for learning - Do something - oberve what the results are (for you and your customers) Is there a correlation between the 2? There may be, but not always - so look for the gaps.

And he slides into an example - His (then) 5 year old son had an idea - he could sell snails!

First few experiments failed - welp - give up? What about trying something else?.So, instead of giving up after the 1st 2 tries - he launched a 3rd idea - a comic book about... snails. Launched - landing page - AND... collected 1 Euro per donation, and send updates with pdfs in the future.

First night - 24 Euro. and it just kept going up - 1 in 6 conversion ratio (that is pretty astounding)

 Don't be afraid to think big - really - like - end world poverty...

Keep thinking - keep innovating.

**
RIGHT - sat down and helped a speaker prepare for her session (SOME one changed all her slides.... last night) I know, I still have not loaded the images from the keynote - I'll get to them a bit later - I promise.

**
And HERE we go!

Wearing Hermione's Hat: Narratology for Testers - with Marianne Duijst.

Narratology is the study of stories - the narrative and other aspects of any story. (warning academic theory stuff coming)

The Fabula is the series of related events - logically or chronologically - the "plot". There there is the Story - the presentation - ANY presentation, the manifestation and colouring of the fabula - the plot.
The TEXT is the medium these are presented to the oberserver or reader -

Building blocks to consider -
The AUTHOR (the one who write the narrative) who is likely NOT the narrator - they are not the same person (usually).

So - J K Rowling presents the story, but the Narrator herself is unnamed.
We experience the actions thru the experience of the characters (Ron, Hermione and Harry) - THEY will experience things based on the different perspectives.

For example - 1st quidditch match - Harry nearly falls off his broom, etc., and we see the story thru Harry's perspectives - however Hermione sees something else.- the change in perspective.

Hermione's Role is to understand and figuring out the fabula / plot /events of the story...
HOW? She gathers and interprets information from MULTIPLE sources - multiple stories. She stores this information and retains it for use.

This is usually not obvious to people who read the story once - usually people read the story once and leave it. Multiple readings will shed more light and reveal more information as we can get past the mechanics.

This works for software as well! Code? how often do we look at code? Maybe once? What are we missing? (We never presume we miss anything - just as we don't believe we miss anything when reading a story - once.

The question is - can we work around this?

Who do we trust?
Rita Skeeter does this weird thing of talking with people - and twisting anything she gets into something else. Hermione, by observation, realizes how Rita works - and finds a way to present an alternate story to the same facts - the same detail.

She - Hermione - listens to all sources - including those that appear to be minor r insignificant - like, House Elves. She realzies that elves such as Doby and Creature have extremely powerful magic - magic stronger than hers. She also is able to retain and present this to others because she gained the understanding needed.

This can set up shifts in understanding from the various perspectives - we change the realities - based on this shifting perspectives. The change in paradigm follows this all - for example - Snape kills Dumbledore in book 6 - and is slagged as irredeemably evil - until we see the reading of Snape's memory.

We are actively NOT looking for all the pieces of the information that can be used - because they do not meet OUR narrative - what things do we hold that we are not considering deeply. Our closely held beliefs/stories /understanding can we wrong. We don't like that. It is uncomfortable.

Context drives everything - Time is part of the context - as is place - The Time Turner allows for shifts in time to allow us to see the actions Place is another context. We know what we know because of where we are.

The challenge to Harry - which Hermione takes on - is to enable others - where Hermione teaches Harry about the information needed - aqnd shows Harry, Ron and others on how they can do the same thing.

The problem is, Hermione does not always have all the information needed to make the best decisions. She builds a model based on incomplete, if not faulty, information. Just as we do with software.

For software people, we need to find ways to think differently - what happens if we do this - what can we infer from THIS. What happens if we change...

**

Lunch and many excellent conversations. More on those later -

Now it time for the 2nd keynote of the day - A Practical Guide to Testing in DevOps, being pesented by Katrina Clokie - the AWESOME Katrina Clokie.

When she was young, she had a teacher named Miss Perfect (really, that was her name) who taught the kids in the class about Atoms - and how they are everywhere and make up everything - including how they could move atoms around by moving their hands in the air - which is made up of... Atoms...

So, when DevOps began to be a thing, many testers looked at that and said "Oh, that is for Devs and Ops folks, we're not in there..." Except... well, Atoms

In Agile, we have everyone helping with testing and helping with quality.  And then we have others added in the mix of Agile to come back as .... Dev Ops - so Infrastructure, Support, Analytics - everything, no?

Citing the equally awesome Dan Ashby. his model - where testing is involved everywhere...

And STORIES!

Once upon a time.... Katrina's org was having a lot of issues. Specifically big red lights going off when builds were made - and things went wrong regularly.  Machines dying and stuff happening and conflicts and - ick.

By splitting the Selenium Grid from the Jenkins Slave, ...

Things got better - - a LOT better.

Now, while this was not a typical "DevOps item, the fact was, that Testers led the drive to make things better. Awesome!

They also test in production. Ummm - yeah - Did I mention they are a bank. Testing in production? Really? Dangerous. Not really.

Monitoring. watching - looking for behaviors that might inform us on what is actually happening.

Because - in a mature DevOps environment, the testing is all around - at every level. Because testing is not looking for bugs - it is looking to see how the organization can be informewd about the bahvior of the software - before and after it goes to production. Really.

 

And a post to the LeanPub site! YEAH!

***

Sliding over to Getting Ready for the Cloud with Sabina Simons. Sabina is a very bright, intelligent young woman from the Kitchner-Waterloo area of Ontario - practically a neighbor of mine! Only around 4 hour drive and an international border crossing away.

And we're underway - OH YEAH!

She is a Development Manager at D2L Corporation. She was given an option of 3 choices for next position in the company - 2 of which she had already done, and the third (the one this story is about "scared the crap" out of her...

What does "the cloud" mean? Welp - their background was to move to an AWS single tenant instance - fine - why?

They wanted to be able to move faster and serve customer needs more quickly and focus on getting product out to people and not the logistics of how to do that. Their customers are educational institutions at all levels, from pre-school to universities.

Can they get this to work? Locally? Globally? How does this actually WORK? What in the world does this look like?>

Change infrastructure - except they have a heap of a mess of legacy... stuff.many, many, many levels of ickiness (my word - family friendly blog)

Some 20 streams of work present, their code base was comparable to... a park with trash everywhere. No test instances, not test cases, not automation of any sort. With a mindset of getting it sorted - their goal was stated as "leaving it a little cleaner" each time they did something. Addressing immediate legacy needs by making incremental improvements.

Experiments! Canary Testing - small actionable instances, small changes to track what is being done. Leave benchmarks and small unit tests documented in the process - and set changes up and run things in the perf lab... things are awesome! Except the code path they were interested was not executed.

Complex scenarios sometimes take unusual solutions - like, how to set things up and how the conditions exist in production. Really.

Benchmarks are fine, making them drive forward. The set the throttle and exercise it.
Things worked great! Except - when they opened it up - stuff hit the fan.

So, now they have a significant problem. Loads of people pointing fingers and loads of "YOU SCREWED UP!" So, deal with the situation as it is - look at what process flow can be tweaked to improve the situation and open conversation. Stepping away from the blame game and being open in communication can actually help calm everyone down and make things better.

Home grown automation tools - (looks like some instrumental graphs she is displaying - and yeah, they were were instrumental stuff - which is awesome - I get to ask a question!)

Tracking behavior through various models - good solid reliable information. Watch what is happening and look for leaks - Really look in the corners, the places that appear to be OK - particularly when things are ... a little odd.

Use the code analyzer to track what is being used - presumptions & beliefs are grreat - BUT - go prove it.

Failure mode testing -

Always sounds great until people realize what that may mean. In short - How do you figure out how the system will behave in different "suboptimal" ways - usually catastrophic!

These start with What If? stuff - and working through it. Sabina's team worked through the issues as a team - (YEAH!) the question is always figuring out the stuff that is likely to happen.

Enter the Master of Disaster - writing alerts to handle with some level of grace things that are likely to go wrong.

Takeaways -
Lead by example. Move boldly and show actual results;
Experiment - What Happens if I Do BLAH!;
No Excuses (really) - everyone has stuff that needs to get done, make things happen;
Share your story - internally, externally - make the world a better place....

**

Right - I snuck off to a corner for a few minutes quite time, then sat with some new speakers and had a lovely chat with them on talking in public and working up the guts to stand up and bare their souls in a way that many people don't realize novice speakers do.

I then did some preparation for the Agile Games night, where I was running a table of mixed small games confusing people and offering puzzles that required them to set aside their preconceptions and immediate beliefs and look at the "call of the question" and the words actually said and written.

Great fun for everyone. I gave away many stickers for prizes and people had fun. There is some socializing going on right now that I intend to return to - with a "tester cabaret" which seems to be great fun. IN the meantime, I've had excellent conversations today and tonight which have given me much food for thought. More on that later.

Live from Potsdam, Day 1 - Agile Testing Days 2017

Tuesday, November 14. A nice day dawned in Potsdam. Just a bit of fog (which strikes me as fairly normal this time of year, from what I recall.)  I had a nice lie in followed by a good breakfast (the Dorint Sansucci does a lovely breakfast, really), a nice coffee followed by getting ready for the day.

I did manage to snag a bag from the conference volunteers, with a t-shirt, conference goodies and the various sundries one might expect (although a postcard from Agile Testing Days is a fun idea!)

Lean Coffee is going on right now and if I scurry, I might just make it!

HAH! Full house! I have NEVER seen a Lean Coffee THIS WELL ATTENDED on the first day of Agile Testing Days. I am astounded - and very pleased for Janet Gregory & Lisa Crispin, who pioneered the idea here several years ago, and it has simply grown since.

What is on after Lean Coffee? The opening keynote to the conference followed by my talk in the  same room!

Jose Diaz is presenting announcements and introducing people who are working very hard. The committee and volunteers are still in the lobby working to get everyone in the conference - IT PAYS TO COME EARLY! Your volunteers would appreciate it! You would too. (I've been on both sides of the table - it is easier if everyone helps out.

The Afghan Girls Robotics team are here. There is a drive to raise funds for medical help for Linnea Nordström the daughter of Kristoffer Nordström, a frequent speaker and friend of ATD. (https://www.savinglinnea.com/)

OK - WOW - Next year is the 10th edition of this conference AND Jose just announced there is a special discount available - 30% off the registration fee for Agile TD 2018 - if you register by 31 December!

Now - the Keynote!

Jez Humble (@jezhumble) is talking on how people make excuses (and call them reasons) why continuous delivery wont "work" for them in "Continuous Delivery Sounds Great But It Won't Work Here."


Jez "wrote the book" on Continuous Delivery in 2010 and was told the idea was crazy. SOmehow, many (not all) companies have begun doing just that. The goal is to make releases boring (his words) so they can be pushed out any time, and not stuck working  over the weekend (ahem).

The goal is to push to production in a simple manner, simply! with no interruption of service and even be able to upgrade hardware infrastructure - remotely. - If it is not possible for you - it is not a problem with CD or Continuous Integration - it is a problem with your infrastructure - or worse, your configuration.

"We all know the 'works on my machine certification' is useless."

He's walking thru the basics of how most shops do development, check in, integration, etc., The KEY is knowing if there is an issue. If you can't fix what you just merged in - revert. If need be, blow it away, stop what you are doing, rest and do it again. Really.

Citing Brian Marick & testing matrix.

Automated testing - using a machine to help you do what you need to do and don't want to waste a human being's intelligence.

The point of CD is NOT to replace testing or testers. It IS about using people wisely - using their talents to advance what the work is supposed to be! THIS IS REALLY, REALLY IMPORTANT.

The case he is making is that you should be able to reproduce you production environment configuration(s) FROM VERSION CONTROL. Data is different, yes - but the configuration should be able to be pulled. Need a test environment? Pull it, run an instuall, run a simple check to verigy the build was good - and BOOM - Bob's your uncle.

"Reasons" why people don't adopt CD -

1. We're heavily regulated.
Hogwash (not his word, this is a family-friendly blog)Amazon is a fine example (look for a nice photo when I geta chance) Amazon is HEAVILY regulated (although most people don't realize or think about it - and they are releasing every 11 minutes...

He's moved on to his experience with GSA (in the US) setting up Cloud.gov. to assist US government organizations to release software FASTER. How? 269 of 325 mandated security checks are done through cloud.gov. Make them common and stuff simply will WORK.

WHY? The US Federal Government is the most heavily regulated environments there is - and until January, they had successfully deployed tools to speed secured delivery on a regular basis.

Most change management is about covering your ass in case things go wrong. For MOST organizations, Change Management is nothing more than CM Theater - it looks good but is worthless.

2. We're not building websites.
Ummm, you know that that is hogwash too, right?

Most of the time, people have a problem - not what they think it is, but they are spending more time doing things related fixing problems than to catch them before they get deployed and end up spending a fraction of the time on new features. For example - HP Laserjet products @ 2008.

Ummm - firmware.

The issue was - simply - "we don't have time to get this automation stuff written, we need to make new features so people want our stuff."  Sound familiar? Except the features were simply dependent on too much stuff.

Their solution (not recommended for most orgs) was to scrap everything and start over.

OK - He is going really fricking fast. REALLY Fast - the pictures that are getting loaded later.

The issue - ISSUE - is HP - ended in 2011 with 23% of their "dev" budget being dedicated to automated test development. It was astounding - (there is a slide going in here shortly)

Architecture is key to making continuous delivery work - no matter the structure or environment (runs a short video of a mainframe-based - green screen system using automated tests against it - AND CD concepts.

(he skipped reason 3)

4. Our people are too stupid.
"Where do you get your really brilliant people who do this work?"
"I get them from you."

Teams create outcomes - Bad systems & processes will overwhelm good people and good teams. The POINT is to get people to a point where people can excel.

Make the environment one where people feel free to excel and discover innovation. When you give people the opportunity to do great thing, they will.

"When you say "our people are too stupid" you are absolutely right. Except, the stupid people are not the ones you mean..."

And he is plugging "This American Life" - thisamericanlife.org/radio-archives - awesome radio show on NPR and a fantastic podcast. - The John Shook episode in particular. It is a great episode (I listened to it when it went out originally.)

Make things better - ALL THE TIME. Management needs to focus on helping people MAKE things better. This is the crux of the issue. Really!

Wrap up -

Agree & communicate on MEASUREABLE business goals (not handwavy rubbish)
Give teams support and resources needed to experiment;
Talk to other teams (particularly the one that piss you off - go buy them lunch and LISTEN);
and quote Grace Hopper -
"If it is a good idea, go ahead and do it. It is much easier to apologize than to get permission."

and into questions...

{I'm a little disappointed that Susan Bligh is delivering her talk AT THE SAME TIME as I am giving mine. She is talking on QA/Testers and their relationship with BAs. Sounds really good to me. I hope to catch up with her and chat on this.}

Bailing for now - I am about to present. Be back later!

**

RIGHT - talk went - we'll see how the feed back comes, it seemed really short and really fast (I might critique myself later)

Grabbed a quick drink, chatted with some people and slid (late) into another track talk.

**

Sitting in Elisabeth Hocke's session on "I am Groot."

Came in late so I missed the introduction. Talking about fear of failure and concerns around that. Slit into finding inspiration - boss gave her a copy of "Agile Testing" but Janet & Lisa - then the company began getting into social media, including Twitter - so she joined Twitter and found .... Lisa and Janet - which set up conversations there and her learning grew. (she is giving ideas around key ideas - I'll be listing them briefly as she goes)

She has now slid into Job Titles and how ephemeral they are. In short, don't let the words define who or what you are. Be what you are and find the right words to describe it.

Behavior drives change. You can change your behavior, You cannot change OTHER people's behavior BUT you can begin the process with yourself, and see what the influence is.

Mix up your learning - look to other tools around how people learn and how you learn. Drive yourself to force understanding. Don't get comfortable (ahem) with what you are and do - keep forcing change on yourself.

Constantly reinvent yourself. Really. Change things that you do - find things that are new to you - blog posts, interesting ideas in twitter streams or other social media - look for things that look interesting but you know only a little (or nothing) about. Reach out around that and try it.

Share responsibility. Work with your team/co-workers on what testing is and learn from each other. The "whole team" thing does not mean not being a tester anymore - it is instead a way of continuous learning.

GAH - had to bail on Lisi's talk (sorry! We'll catch up!)

**

Couple of maintenance things then back with Cassandra  on test automation.

Her topic is "5 ways test automation is like sex..."

Right - THAT might get people's attention.   The real question is, do I have a future in software testing if I don't do/know automation...

 This grew out of a question in Ministry of Testing discussion forum... and here we go!

1. All the cool kids are doing it.
Well, yeah, this ties in with an assertion she made on twitter, that test automation is a bit like high school kids - they talk a lot more about it than they are actually doing it. Most job adverts in the UK (where she works generally) focus on automation testing experience. So, she went looking - 1st 5 posts she found, 4 mentioned automation straight up, the 5th, down in the sub context, was "we don't have automation in place, but we have a need. If you want to do this with us, come apply and help us.

2. There's pressure to "do it."
General press shows that "automation" or "robots" are replacing people - except they aren't really doing it. Things like "AU could threaten up to 47 percent of jobs in two decades - reports."

Yeah, cuz adding the word "report" to the end of a headline makes it real, right?

There is "fake news" and "fake information" and "alternative facts" - and always has been since the beginning of time, including the fake "studies"  Assertions need to be followed up.

The thing about test automation, are precisely the same as was said about self-checkout in grocery stores/shops.  Right.

3. There's a lot of MISinformation.
Loads of myths and urban legends but real, measurable information is harder to come by. People may cite other people - those considered "reliable" and still, somehow, they have not checked sources either.

References Alan Page - references Richard Bradshaw. Should testers write automation or should "tool smiths" write test automation? Page & Bradshaw think the later. (I'll find the references in twitter - I remember the conversations from a few months ago...)

4. Good people are wanted with or without automation.
The "community" may be the bubble - and may be an echo chamber.
Yet, the community of testers give a solid presentation

5. It (automation) is not the enemy (or is bad)
We need to find ways to contribute to it and find ways to make use of it to make better products. Tinkering with tools and dealing with people are flip sides of the same coin.

Lessons from Cassandra -
Don't believe the hype (it's mostly rubbish anyway);
Understand you reasons for wanting to "do it" - or not;
Benefit from and contribute to it;
Don't let it be your excuse;
Understand your value and have confidence.


** Be a successful testing with or without automation. **

RIGHT. I completely missed the 2nd keynote of the day because I was talking with the very intelligent and engaging Susan Bligh.

I am now sitting in the video replay of There and Back Again: A Hobbits/Developers/Testers Journey.

In the beginning - the start of the Hobbit clarifies what a hole is, by challenging the assumption that a hole is something known by rejecting that "known".

This sets up the core message - People know what they know, but it is fallible.

Testers tend to become quite comfortable. Many like being in that nice safe spot. Testers tend to react to the class bias instituting their OWN bias.

OK - I'll fill in the rest later...

Had some good questions/discussion and headed out of the room for a longer discussion. That took a while! THEN I got pulled into several enjoyable conversations with people who were asking questions around what my presentation had to say.

Short interview and sneak into Ray Arell talking about Safe-to-Fail.... Failure. Yeah. awesome!

He's asking questions around "Who in the end is afraid to fail? What does failure look like? Wgeb bugs (failues) are found in production, who is it they managed to get there? Persistence? For example - let's talk about Fail Safe (speaking of oxymorons)

What if the failure was something... odd. But the issue was not us, what if our experiments were flawed. What if we create a naive experiment? What if we have an issue with people being afraid to fail publicly? What if the concerns of the people is not physical but emotional safety? What if they are both?

High degrees of uncertainty - do we have an issue with the core way we do things?

We are defined by how we find value - by helping other people over come challenges and fix problems and drive conversation, which drives ideas....

**

Getting a bit tired. Sat for a moment & chatted with Mike Sutton. He's been having a busy time of it at the Open Session/chat area. Frankly,

GAH Battery is going!
OK - temporary replacement - Let's GO!

**

Closing keynote of the day - Poornima Vijayashanker is presenting on ... ick
onboarding...

How to Onboard and Train New Hires into Happy and Productive Employees.

OK, starting with the story of how she started - the new grad, lands the first job and finds herself in... not the world's best gig. The CHALLENGE for new employees is often the company, not the employee. Most organizations are pretty top down (that is why there are vbosses, right?

THe problem is, when the immediate boss is absent (physically or emotionally) or a bit of an expert in everything. The one who is telling people his or her version of how awesome they are.

So, what does this mean? Well, consider this, most people want to be good employees and contribute, etc.,

Consider this - What does the 1st day/week/month look like?
How soon does the new person feel they are contributing?
Watching cat videos does not count. Really.

Consider, how long does it take to get the new person to meet their new team - not the department, just the folks they are going to be working directly with.
Also, how long will it take, how much work will they have to get their machine and environment setup and WORKable - if you make it a screening process, you (the boss) screwed up.

Don't be that boss - help coach people, get them in contact with people to guide them. Really.

Get them involved - and WARN them if there are ... issues ... that might trip them up. Biff works well with most folks, but clashes with Dorf. Also, consider inter-departmental challenges - these guys like showing THOSE guys how in-control they are. Sometimes a word of warning can help people not walk into a minefield early on in their gig.

By getting people involved, they can make things work FOR THE COMPANY.

Given a new hire will feel connected early on, ask them what they think of the org, Ask them what problems they see - maybe at 60 or 90 days from start Maybe 100.

Ask them what they would suggest about direct problems they see. Why? It gets them involved and INVESTED.

**

Right. Tonight is the MIATPP awards and banquet. With a theme of "Super heroes" - yeah, people are encouraged to come dressed as a super hero.

This should be ...

interesting.

Loads of Cat Woman costumes, wonder woman costumes, super man, super girl, captain america and some costumes I have no idea what they are.

Big news is, my friend Huib Schoots was named as the Most Influential Agile Testing Professional Person (MIATPP) for this year. I am very happy for him. He's a good man.

**

Live from Potsdam, Day 0 - Agile Testing Days 2017

I arrived in Potsdam last night (German time) after a long travel day with a few adventures, but nothing significant and nothing negative. Arrived late, was forced into the pub for a beer and conversation before I even made it to my room. One thing led to another and I found myself staying up far later than I intended too.

It was a good thing I had nothing scheduled for this morning as I slept in late and had a relaxing conversation with George Dinwidde, Meike Mertsch over a leisurely breakfast. breakfast.

I took a nice long walk around the city, past Sansoucci (the summer palace of Frederick the Great) and back in time for the first of many open sessions, in this case, for speakers. Mike Sutton was facilitating the discussion which was aimed at answering questions of new speakers or speakers new to the this conference.

We have had several deep conversations around people's being concerned about aspects of presenting that many speakers have experienced - everything from imposter's syndrome to concern that people will not like them as a result of the presentation. The discussion was free formed and free wheeling. Mike did a fantastic job getting people to relax and open up.

Much of the time was spent getting to know each other and find areas we can help improve each others presentations and build relationships for the future.

There are so many people here with much to share. My intention is to record as much as possible and present the conference as I experience it. The level of serious discussion even now, is staggering - and the conference proper has not yet started.

I should note it is not ALL unicorns...

 and teddy bears.











Watch for Updates!

Had a lovely dinner for speakers, with conversation with the irrepressible Tony Bruce, Anna Chicu, Victoria Manevaka and others (and as soon as I am certain of the spelling of the ladies' last names, I'll add them. REALLY!) All in all, a great evening with excellent food, good wine and conversation that left me with much to think on.

Returned back to the conference center and having a chat with George Dinwiddy and a few others and the Afghan girls robotics team arrived. Poor dears looked exhausted, but gamely allowed to have their pictures taken with "fans."

I expect tomorrow will bring more.

For now, I need to practice my talk one more time, then to bed.

On Conferences, Again

I've written more than one post with tips for people going to conferences, usually aimed at those who are going for the first time or rarely have the opportunity to go.

Normally, these consist of things I think of as "good ideas" for conference attendees. Ideas like:

• Be well rested before the conference (many will keep you very busy physically and mentally so be prepared for short sleep and very long, albeit packed, days);
• Bring business cards, even if your company does not issue them to you (this is less important than it was a few years ago given the continued increase in social media, still, I bring them because I find them handy);
• Bring an open mind willing to discuss topics you might not normally discuss (you're there to learn, after all - so LEARN);
• Comfortable clothes in general and comfortable shoes in particular;
• Devices for taking notes - note pad, laptop, tablet, smart phone - THEN USE THEM!;
• Courage to walk up to people and introduce yourself - particularly if the person you are walking up to is someone "famous" in our world;

These came from watching people look rather lost and sit like bumps on a log while conference stuff was happening all around them and they were not engaged in any way.

This post is not aimed at those people. It is not aimed at first time conference attendees or even first time speakers. Instead, I direct my words to colleagues who speak fairly often at conferences on testing or... anything else.

Hey folks, I'm Pete. I'm sure we've met before. I know I have seen you around and some of you I've heard present. How ya doing today? Conference going well for you?

So, I have a question. How many new people have you gone out of your way to meet here? I don't mean the folks who come up looking a bit star-struck and in awe of meeting you. I mean how many people have you walked up to and started a conversation with?

It doesn't need to be about anything really serious. It might be something really mundane like, oh, the food in the buffet line or the quality/quantity of coffee or tea.

It MIGHT be something like "I must have that t-shirt! Where ever did you get it!"

It could be something more direct like "I thought that was a great question you asked in the session on.... can we walk about that idea a little bit?"

I know MANY of you are a little shy walking up and starting a conversation with a complete stranger. Still, maybe step out of the comfort zone a bit and see what happens.

Related to that, I know I tend to sit with laptop open looking something up or reading something or trying to write something, maybe an email or finishing a live blogging post or maybe just get some notes in order. I might suggest this (as one of the things I need to work on myself) - Try not having the laptop open quite so much. Instead of isolating from the activity around you, maybe work for a "pleasant observing face" while sitting with a coffee or tea and look up - actually watch the folks interacting with each other.

I know my "pleasant observing face" sometimes makes me look like I am about to inflict great bodily injury on someone, or some group or people (I am working on changing that, really - terrifying small children without trying is not something I aspire to... really) - and I am strongly suggesting people try and do the same. (Not the bodily injury thing or terrifying small children.) Make yourself available so people don't need to work up more courage to walk up to you than it takes to jump out of a perfectly good airplane with a parachute the first time. You never know who you might meet that way.

One other thing. I know many of you, like me, have friends we get to see in person ONLY at conferences. It is great to catch up with them and laugh and tell jokes and stories and talk about what we're working on now and what is next. The challenge I see is, when you get so wrapped up in who you are with RIGHT THEN, most of us close down the opportunity for other people to approach us.

Make sure there is always room for one more to join the conversation.

Right, That is it for now. Thanks for your time and I'll see you at the next conference.

Cheers!

On Leadership, Power, Authority & Bullies - pt 1

Maybe you've heard or read some version of this:

Power tends to corrupt, and absolute power corrupts absolutely.
                                                                    John E.E.D Acton, 1st Baron Acton

Most of the time I've heard it, or read it, the first clause tends to get mangled or at least changed, to "Power corrupts..." Instead of shifting from a possibility it becomes an absolute. Perhaps that is part of the reason I disagree with the generalization.

Avoiding the question of the definition or nature of "power," which is less a tangible thing than a description of a relationship, I prefer to examine why people seek, or do not seek, power, authority or the trappings thereof. (For now, and for simplicity, I will refer to these things as "power" while recognizing the ambiguity.)

Do people aspire to positions of power because that is the natural order of things? Are they a "born leader?" Or, do they seek positions of power, or authority, for some other reason? Maybe for their own ends?

I suspect there are plenty of examples of each of these. There are other examples of people being in the "right spot" at the "right time" and being pushed into a position of authority or power.

I tend to think of "power" and "positions of power" as being something akin to Tolkein's character Aragorn, speaking of Galadriel and the forest of Lothlorien.

There is in her and in this land no evil, unless a man bring it hither himself.
                       J.R.R. Tolkein, "The Fellowship of the Ring."

I do not believe it is power that corrupts. I suspect, strongly, that the individual's nature is exposed more readily when they have the opportunity to exercise that power, with little or no oversight.

That may be unsettling to some people. The idea that their favorite manager, athlete, TV-personality or politician has actually been an ass all along, and has been hiding that reasonably well, can be a tad off-putting. Simple fact is most people working in some form of entertainment really like the positive response. From personal experience, it is fantastic to get a standing ovation and called back for an encore or two or three. It is a huge boost to the ego. Feel the endorphins rushing through the body? Great, isn't it! Loads better than playing to polite applause.

Musicians and actors live on those moments. Yes, I know - art matters.The challenge matters. Still, while the money can be good (or really crappy) it is the applause and approval that drives many people.

Politicians are fairly similar. They really like talking in front of friendly audiences who cheer madly and read huge importance into the slightest thing. People who are critical or asking really uncomfortable questions? Not so much.

I once read somewhere that the greatest problem with hereditary monarchies is you sometimes get a reluctant monarch. The greatest problem with democracies is the people WANT the job. Always ask yourself "why?" when someone talks about public office. The "5 Whys" work depressingly well with politicians and their motives.

These examples are pretty obvious, right? People seek stardom or "higher office" usually for their own ends. They are often couched in grand language about being an artist or serving the public interest. Having met and dealt with many, I don't buy it so willingly as I did 40 years ago.

And don't get me going on athletes or "TV personalities". SPEAKING of self-aggrandizement and self-importance... right.

And Managers

If you are fortunate, you have had a manager or supervisor or two you could count on to always have your back. That same manager probably also found ways to inspire you to heights and feats you never dreamed of being able to achieve. If you were really lucky, that manager also looked out for your development as a professional craftsperson and, in some unique cases, as a more-developed person.

If you are really, really lucky, you've had managers like that without having to deal with other, less desirable managers in the office.

You know the type.

The ones whose employees flop back in the chairs at their desks after meetings. The same "resources" go through the motions as they are told to with no variation. Because if they do, they will get in trouble, whether the variation is important or not - it is a variation.

These managers have determined that positional authority is a justification for "motivating" their "resources." They demand people do stuff RIGHT NOW. They insist that they have the answers to the questions and don't ask them questions because doing so means you were not paying attention. The ones that belittle people in meetings.

The ones whose "resources" are terrified of losing their jobs.

And?

I've seen both types of "managers" in the same company - in the same department, no less. They both claim to be working toward the good of the organization. It is possible they are and simply have different views on that "good" is. However, in the instances in my memory, at least one type was working for his own glorification.

While the idea of a "servant leader" is certainly not new, a fair number of Managers I can recall would reject that concept out of hand. Their job was to direct actions, our job was to make them look good. Period.

You saw that readily 30 or even 20 years ago. From my experience, 10 years ago they tended to be more nuanced. All velvet to people they needed something from, and were out of their direct zone of influence, and crass and abrasive to others.

When confronted, their job was to "get things done." At least twice I caught one of these folks in outright lies - and called him on it. In a meeting. With other managers. And the VP they all reported to. That afternoon, when no one was around, it was yelling, ranting, profanity streams, threats on my job.

That was probably the first time I did the "scary big white man" thing. He backed off.

I out bullied the bully.

Bullies

That is what those "leaders" are - bullies.

If threats and management by intimidation is your leadership style, you are a bully, if not a dictator.

Positional authority in any context is not absolute. There come certain trappings with those positions. These are part of the "power" fears people have. This authority, this power, in the vast majority of situations should be limited. It appears to be unlimited, or "powerful" only when no restraints are present either by watchful oversight or by concerted, proper resistance.

It is not a writ to make people's lives miserable for any reason, and corporate profits are probably the worst reason to make the lives of people who make the product that drives those profits miserable. People who are in fear of losing their positions and the means to support themselves and their families will rarely speak out, until the pain becomes unbearable. This is where the trade union/organized labor movement grew from - the refusal to be beaten down (quite literally in many cases)

Being "in charge" does not give you the right to be an ass. Ever.

Being "in charge" does not mean you are the one who "has all the answers." In the "over 30 years" I've been in software development, I have NEVER seen a software project where one person knew all the answers absolutely. Never.

Leadership, Power and Authority can be used for good or ill. They are not inherently one or the other. The good or evil, comes from the individual people themselves who hold them.

Community, Conferencing and a Call to Action

Over the last ten weeks I have had a series of conversations that I never expected to have. This does not mean I should not have had them, but some two months and more ago I did not see the topic as one that was observable around me, and was something I could do nothing about.

I was seriously wrong on both of those counts.

Boorish Behavior and Code of Conducts

At one time, I read the many calls for conferences, professional organizations and other groups that existed as a well-intended but ultimately futile effort to direct behavior. It seemed to me the hope was this would control or redirect boorish behavior - the frat-boy-esque shenanigans that I saw people engage in when I was working at large Universities. You could pick them out fairly easily by a couple of things - Money was never a serious problem (their protestations to the contrary notwithstanding) and their utter rage at not getting their way on something that should have been trivial.

It is akin to some folks who lived across the street from me, briefly, when I asked them to turn down their music, just a tad - just enough so I could not hear it in my house over the television... with the doors and windows closed and the central air going... at midnight.

Utter rage. DO YOU KNOW WHO I AM?!?!? No, I don't. Frankly, I don't care. DO YOU KNOW WHO MY DAD IS?!?!?!? No. I don't. And, unless he is in the house with you right now, it is completely irrelevant. YOU'RE GOING TO WISH YOU HADN'T PICKED THIS FIGHT! Not picking a fight. I'm asking nicely. Really. This is me being polite. YOU'RE BEING AN ASSHOLE! YOU'RE NOT POLITE! YOU'RE AN ASSHOLE! That may be true, however, that is also irrelevant.

He was really mad at me. He was even more mad when my friends from the local police department knocked on his door.

Why was he mad? I'm not sure he started out really mad. I had the impression he as show-boating for his friends - showing off to show how he could "deal" with the locals. Then when I was not scared or intimidated, then he really got mad.

In this case there was a "code of conduct" to fall back on. It was the local ordinances. When I went, politely, and asked that the behavior change or stop, things got a bit silly. The next step was to call the keepers of the code of conduct, in this case, the local police department... non-emergency number. There had been no overt threat of violence and no suggestion there would be immediately. So, not an emergency.

It was just a guy being a jerk.

Sadly, this is the kind of thing where most "conflict resolution and incident deescalation" training and programs stop. (Some of my current drumming students are police officers. They complain about the same thing. Theory rarely survives on the street.)

When there IS a code of conduct one can point to, that makes the interaction less personal, and in many instances, less judgement based. Instead, it is a case of "Your behavior is in violation of the code of conduct on these points..."

That is fine. In fact, it is great - as long as the code of conduct (or local ordinances) are specific enough, and explicit enough, to leave little to no room for disagreement.

Do X and Y is the result.

Sadly, many of the published "Code of Conduct" documents and/or web pages I have read in the last two weeks are of the very hand-wavy, let's all just get along ilk.

That does not cut it.

(That is a warning I am about to go on a rant...)


Nah. I edited out most of the rant. I've been tinkering this post for a long time, mostly trying to avoid sounding like I'm yelling incoherently through my keyboard.

Instead I'm going to write about a really old-fashioned idea.

The sad fact is, there are people who act as if they are more important than anyone else. They act as if there is something special about them where the rules don't matter. I have seen this at the office (I bet others have as well). I have seen it occasionally at conferences.

Chivalry

Yeah. I know, right? Knights in armor. Damsels. Dragons.

Well, maybe not dragons.  Frankly, not that other stuff either. The real point to chivalry was, and continues to be this:

The strong protect the weak at all costs.

That's it. That is the gist.

What does that mean?

The powerful help the powerless. The stronger ones protect the weaker ones. Women and children first. Save the most vulnerable. Really. Yeah.

The core tenet to a society governed by what is called the "Rule of Law" is that the Law is King. The King is not dominant in society, the Law is.

Simply because a person or group of people are capable of doing a thing, they do not have the right to do so. Simply because a person or group of people CAN do something, as in they have the physical ability to do the thing, does not mean they have permission to do so.

Ever.

It does not matter if someone is being "inappropriate" in any way with a woman or a man. It does not matter if someone is being "inappropriate" in any way with a person of color. It does not matter if someone is being "inappropriate" in any way to a person of a different religion or ethnicity of the majority of the people at the event. If something is wrong, DO something.

What can be done?

There's a thing called "situational awareness" - being aware of what is happening around you and understanding how information, events, your own and other people's actions will have an impact immediately and in the near future.

It might be simple.

If you happen to notice something, say something. It can be as simple as "Is everything alright here?" Or maybe, "Everyone OK?" - with a significant smile.

You don't need to be the "behavior police." But PLEASE, be aware of people around you. Most of us have been in a situation where we felt really... un-good. Remember that? That feeling of wanting to be anywhere but where you were and that sick twisty feeling in your stomach that things were likely to get really, really bad? THAT?

Keep an eye out for folks who might be in a similar situation, with that kind of "I want to be anywhere but here" look on their face, then offer a word and a smile.

Safety Pin

Remember the Safety Pin thing that was around the UK shortly after the Brexit vote? I don't know if that is a thing or not any more. I've seem a few in random places in the States, but I don't know how widespread it is. I also don't know if it is still a thing in the UK.

The idea behind it is simple - People were being jerks, asshats and worse to obvious immigrants or people who did not look like them or prayed to a deity they did not pray to. A fair number were justifiably frightened, if not terrified. People stepped up and offered themselves as helpers, as havens - that is what the safety pin was for, to identify those who would help.


What we can do


Be the Safety Pin Person.

Be the person willing to help.

Don't engage in violence even when provoked.

I've told people I am very good at being a Big-Scary-White-Guy. I am. I don't like doing it, but I've done it more than once. I will admit I am extremely good at frightening people who are trying to frighten or intimidate others.

Violence is a terrible option and tends to be self-defeating. I'm not advocating punching people in the nose. Violence does not help, self-preservation not withstanding.

Standing up and preventing someone from inflicting violence on someone else is a different story, in my mind. Protect those who are in trouble and need to be protected.

Help people have the fun and open, positive learning experience we expect conferences to be.


Be aware.

Be a helper.

Shelter others.