Yeah. Here we are in Potsdam, Germany for Agile Testing Days 2016. We are starting Day 3! Loads of people here! It is great to see this amazing community grow so much!

Thursday December 8 dawned, sort of… I guess… cloudy over cast and cold. That is kind of a theme here this year. Of course, Potsdam in December, what should I expect?

Last night’s Sponsor’s Reception was amazing. Wonderful food prepared – grilled & barbecued – wurst & salmon & brisket & pulled pork with a lovely selection of vegetables, roasted potatoes, salads – fantastic food last night (maybe I did not get enough for breakfast this morning…)

The Games Night went really, really well – loads of people participated. I brought stickers to give out as prizes – for people who solved the puzzles I had. I revamped a “Tester Quote” game – a selection of quotes all from the same person – name the person and get a prize. Then, there was “Instant Insanity” – a game where the object is to get each of the five cubes in line with colors showing only one time on any side of the cubes, when lined up end to end. Then, there were variations on observation an interrogation games – Look for the “hidden in plain sight” type – along with “Here’s enough information to get you started, now, ask questions about the items.” AND “magic rings – simple little things to show how the obvious can sometimes be so far away and hidden from us.

Loads of fun was had – as people said “Got any more?” I pulled out variations on dice games, pen games and other “are you paying attention” and “are you looking for patterns” games. By the ending time of 10:00 we were not quite ready to pack it in, so we wrapped up the last few cycle and packed everything away until next time.

The Cabaret night seemed to be going over very well, by the time I got back down from packing away my games, the Cabaret room was packed with no sign of letting up. So, I headed over for a quiet pint in the other hotel bar.

Had a fantastic series of conversations with new friends and old. Alas, it came time tohead up to the room and try and do a little work for work before climbing into bed.

I am so looking forward to today’s sessions. There are so many good ones coming up! As it is, I really need to do some work for the day-job and get it done today. So, here is what I plan on checking out.

The opening Keynote for the day is by Jessica DaVita (tweets at @UberGeekGirl). Her talk is Baking Safety into Infrastructure Testing. I am looking forward to hearing what she has to say.

Then, while there are many talks lined up in the next slot, including my colleague and friend Matt Heusser’s (tweets at @mheusser) talk on How to Talk About Coverage, I need to spend that time doing work stuff (Matt, I’ll try and catch the recorded version this afternoon!)

I would be remiss if I did not come down to catch Ash Coleman’s (tweets at @AshColeman30) session. Ash is another of the “New Voice” speakers – meaning they are new to speaking and are becoming known in broader circles. Ash has also been doing many interviews this week of people who are presenting or otherwise engaged at the conference – I had the great pleasure of interviewing her (and turning the tables a bit. She is presenting “Expectations, Adaptation and the Battle for Quality.”

Melissa Perri will be presenting the keynote after lunch, “Designed to Learn.” I read the abstract and am looking forward to this – hoping I can actually be there as my team will be in the office by then and I will possibly need to spend some “quality time” with them.

AND the painfully cheerful Michael Sutton is starting morning announcements – so we are about to start! (I so need more coffee…)

Right – made it back JUST in time for Jessica’s start.

Her position is Technical Evangelist, which she describes as a person bringing new light and information to other people and organizations. She describes herself as a student of human behavior, and how people interact.

Software is eating the world. It is everywhere. She popped a tweet from Lisa Crispin that she’s terrified of flying because she knows there is software in those planes. There is also software in motorcycles – yeah – cited a motorcycle race where the defending champion was about to win, and smoke began billowing out of his bike, he pulled over and lost – because of a software error on his bike. Oops.

And she talks about DevOps – and how there are conflicting needs – Change and Stability. Before DevOps, there was a “wall of confusion” between development and operations. Except sprinkling pixie dust, agile magic & unicorn happiness does not really fix anything. So, we need to work on this.

So, why does safety matter? Because there is crappy software everywhere.Cites John Allspaw (CTO at, @allspaw)  – that we never really know (as much as we would like) why our software works or fails on any given day. Security matters – they don’t intend to be a roadblock – they are trying to protect customers and the company.

Aaaaaaannnd – Patching – yeah – everyone loves when patching gets borked, right?  THis patch was pushed 8 years ago, except for this ONE server. Oops

AAaaaaaaaaaaaaaaaannnnnd – Regulations! YEAH! Regulations – PII, PCI, HIPPA, auditors. yup

Why do so many orgs hate dealing with auditors? Mostly because it is done so poorly. So archaically. And given the scandal with the VW emissions masking, what has become clear  is the only real way to know what is going on is to look at the code. And not just the code we are interested in – but EVERYTHING that happens and interacts with what is of interest to us.

THis brings us to Fear and a culture of fear. People will react with fear given how so many companies react to change & impose controls. Many companies make use of fear as a  control tool – where intimidation is the norm, perpetual fear of punishment or retribution is the norm. She describes these as pathological companies.

Google has a concept of Psychological Safety – that it is the most powerful predictor of safety teams

There is a notion of a basic agreement that there is coordination , joint activity around intentions.

Common Ground in Joint Activity –
Signals & cues
Conversation – effective coordination

Common Ground is about, at it’s heart, who knows what.
Interdependence – if what we are doing as a tester has nothing to do with what the developers, we are not really working together – we are siloed.
Common ground is not a thing – it is not a state – it is a process.

Communication is always proceeding on 2 tracks – Team work (what we do to keep each other up to date) and Task Work (what we are working on)

Signalling is an idea around communication – letting each other know what is going on. When you are heads down & working in depth on something. The challenge is to know if a person is in a state where interruptions will disrupt the work. In person, it can be fairly easy – for distributed/remote teams – this is way harder. The problem is that even asking “Do you have a moment?” can disrupt the mental work that is in progress. The result can be ungood.

(Pete note: she’s going crazy fast – all the morning keynotes have challenged me to even be close to keeping up)

Coordination is about managing dependencies between activities. It CANNOT be manufactured through procedures and explicit guidelines.

One simply does not just do coordination.

Common ground is not “everyone knowing the same thing” – it is instead based on pertinent mutual knowledge.
Common Ground depends on mutual knowledge, beliefs and assumptions.

When each person on your team
has different roles and functions – different forms of expertise.The problem is these can be compromised if we try and force.

Common ground can be compromised or lost during hand-offs (eg., stuff goes to production or “downstream” processes, etc.,)

Why do teams lose common ground?
No (or limited) experience working together;
Access to different data;
No clear rationale for directive;
Different stances;
Unexpected loss of communications – unskilled at repairing disruption;
Failude to monitor confirmation of messages;
Confusion over who knows what – fundamental breakdown…

Joint action ladder – 
1. Attend (make sure the person is aware of a communication attempt)
2. Perceive (be aware there may be a communication attempt)
3. Understand (does this make sense to the reciever)
4. Act (can this be acted on)

Common ground is not binary – it is organic and ongoing. It needs to be supported and sustained through out.

The fact is, no matter how much care is taken, the wheels will fall off from time to time. CG muste be nurtured.


Safety is conveyed through actions.
And Automation? can we help make automation a “team player?” Sure – but it takes a great deal of work
We need a common language so everyone can understand what this stuff means (mentions INSPEC – a human readable language for automating continuous testing and compliance…)

Make things a plain language as possible – make sure everyone can understand what is being presented, explained – “what does the code do?”

Cites Justin Arbuckle – you can prove a companies compliance if it is expressed in their code.

So, where do testers fit in with an ever changing world?

Mentions a “large company” that made a cute video saying they had eliminated the testing funtion. (sigh) She says “this is a huge mistake.”

Challenge for testers – help others understand the way testers think. Involve developers in what you are doing, involve developers in working on automation- This will help them write code that is more testable.
== Q&A ===
Psychological safety is based in making things OK for people to make mistakes. This is not carte blanche for a loose attitude.

And with that – there is a break. I need to do some day-job work. I’ll be back for Ash Coleman’s session!
OK – PRogress on work stuff, FANTASTIC conversation with Jane Gregory & Lisa Crispin on stuff people from the office asked me to ask of them. and NOW – in Ash Coleman’s session – REALLY looking forward to this!
(Oh, and sitting next to THE @teewanz – yeah him…)
Right  – Ash laucnhes  and – BOOM! technical stuff – no mic, flaky internet… and she’s doing a great job adapting and “going with the flow.”

We can set expectations – no problem! Except … documented “plans” tend to gather dust. If people read it once – that is pretty much it for most plans… and most teams.

As testers, we have ideas around how things should go. We can help teams be successful by focusing on  what we can do. Things like…

What do I test? What CAN I test?
How do I keep track of stuff – questions, bugs, tests I’m working on, stuff like that
How can we communicate so we are ALL comfortable.
–Pete Note –  Ash is hitting on what seems to be an underlying theme in a lot of talks this week – Communication is key. If you have crappy communication, don’t expect to produce good work,

The greatest joke in life is making a plan. (Pete Note – nice variation of the “No plan survives first contact with the enemy.”)


How do you identify whether your plan needs alterations? (AWESOME question)

“So, we’ve been having a lot of problems on this team, are you sure you’re up to it?” Yup – loads of teams trying to transition to Agile have said that to people joining the team. Ash heard it a LOT.

As she puts it, she was so happy to be there, it was only after joining she realized she had… a situation.

The Situation – and how to evaluate it
What does your tracking look like?
How are your plans panning out?
Are you able to deliver or bring features to completion?
Is everyone happy?

These were the questions Ash learned to ask – after seeing an environment that was … troubled. Client is mad, testing is a mess – development is a mess – people were soooooooo unhappy no one wanted to talk about anything cuz they were already really depressed and found that talking about it didn’t help.


Details in the fabric -Look for what is being said underneath the comments. What OTHER forms of communication/venting are in place.

Fine Tuning – Look for what IS working – if people are willing to look for some bright spots, there is hope. If you can FIND stuff that is working – and are good! – Then the rest might be turned around.

Ever notice that when a project is in trouble, more meetings get scheduled to “fix” it – so people then get stuck dealing with what people who are upset about not maling progress & communicating and more meetings and stuff doesn’t work and meetings and… yeah.

What does SUCCESS look like FOR YOUR GROUP? NO – Really!

So, if you are looking at a bunch of stuff – and people are writing bugs – WHAT are the criteria for determining what the problems are? DO you have a clear, shared understanding of what the intent is? Do you have any ground rules? Ash mentions multiple bugs written – which were contradictory – based on people’s expectations since there was no clear direction or signs of intent (related to the thing Alex & Huib did yesterday – people will fill in gaps with their own narrative – that thing.)

With time, by celebrating small success, and helping people see there was hope –

Avoid sacrificing quality when experience changing conditions.

But what is quality?
related – What is the Definition of Done?
related – What is the Definition of Ready?

Getting something “done” for the sake of getting something done – without knowing what things should look like – is NOT HELPING! STOP! JUST STOP! Figure out what things are supposed to look like – and agree.

If people have some understanding of what is wanted – what is the ask – then you have an opportunity to make things better, if not great. Reset expectations when possible – make sure people understand what they are responsible for in getting things in place – the ground work – like what IS meant by ready? What ARE the endpoints we can hit?

Tension is not always a bad thing. Ask “IS this good or bad tension?” (Pete – are you a good witch or a bad witch?)

Sometimes, like flying a kite, tension can be good or bad – a certain amount is waht you need to conrol how the kite moves. Do it wrong, or over react to the ebb & flow in wind, etc., and you will have “less than optimal” results…

Like, scheduling EXTRA meetings in order to “fix” projects that are in trouble. People will do it, and go to meetings, but it will be grudgingly and will be resented. People will be less happy – then look for quality to drop.

The time I feel I want to hold on
the tightest is the time in which
I am under the most pressure.

So, how about MVPs – the most valuable players/people?
the thing about distinguishing the forest from the trees.
Yeah – creat call out – that metaphor works BOTH ways.

What is the MVP?
What does the forest look like?
Is there room for more trees?

This brings us back to quality – what IS that – what DOES success look like?

Defining that for your team will help define the tea
m’s expectations – will help ALL the players be MVPs (yeah – the team members all contributing uniquely to success.) THIS will help then realize the CAN be successful.

Encourage humility among the “leaders” Encourage honesty and openness.

Doing so will help you gain the small successes that you can build into larger successes. As a group, collectively, we can build these things.

Ownership – yeah – that gets misused a lot – AND! This can be shared to expand what the team can do.
LUNCH TIME!!!!!!!!!!!!!!