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
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 Etsy.com,
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 -
Intention
Signals & cues
Conversation - effective coordination
inter-predictability
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 -
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.")
Customize -
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.
Unless..
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.
--- {Pete Note - HAH! Ash is a funny woman - Her team uses MVP to talk about Minimum Viable Product AND the people! - I muffed the transition - Sorry Ash!}
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 team's expectations - will help ALL the players contribute tp MVPs ({Pete Note: Minimum Viable Product this time} 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!!!!!!!!!!!!!!
===
Back from lunch - awesome food.
Right now, I'm sitting in Melissa Perri's (tweets at @lissijean) keynote "Designed to Learn."
Company had a beautiful app - awesome stuff and no one used the app. So, they tried an experiment. Instead of doing all this huge development effort, what if you tried a minimal change and see what happened. Her first experiment was like.. umm... successful in showing this was a terrible idea.
So, she suggested that at the next place she worked that... the do an MVP.
Response?
"We don't do that here."
Minimum Viable Produce is a concept that, even the "experts" who popularized it, has changed over time. (she had loads of slides with quotes, I bet they are on twitter... not putting htme here - takes too long)
Question -
Do customers have that problem, really?
What are they doing to solve it now?
Where will the yuse the solution?
What do out customers expect to gain?
When?
So, maybe we need to forget the term MVP and instead look at how we learn - all of us
and consider these as experiments to discover something.
#1 Consider problem-solution fit - Does this problem exist and can I solve it?
#2 Product Market Fit - Is my product desirable enough to be profitable in the market?
Most people look at #2, not #1.
So, some folks argue that the issue is one thing when it is often another. Do you really have a problem? EG., you have people trying a product and not actually repeating? Or, do you have people getting so far in the process and then dropping out?
What is it that you can do to learn?
Design ways to learn more?
How can you learn from people who are experinceing issues? For example - People get to a screen and drop out - The reasons may be totally different than you think
Example was a food delivery service. Loads of people look at stuff, website looked great and people are dropping out. added a chat window asking what they disliked.Biggest reason was people had no idea that the product included - what was available. The website was pretty but had no information.
MAKE THAT CLEAR!
Get your stuff together -
Remember that even successful experiments will fail. First efforts nearly always fail. ON average, 1 in 20 will fail.
Product Strategy is not the solution - that is a description of what you have learned BY experimenting.
Then you can describe what you can do to fill needs and make the company a ton of money.
Product strategies describe current state - what do we have now?
We need to establish in initial step - the "target condition"to work toward. When that has been achieved, take the next step. Because, the new "target condition" is now the current state.
By expanding, shifting the state from the current to a more desired state, you can move forward. The challenge is keeping the target condition easily achievable. These should be steps toward the big "strategic" goal.
Product leaders provide vision, goals and guardrails.
The challenge is "when do we think big? How do we achieve the goals we want to achieve?" So, the challenge is to remember that HUGE goals are likely NOT to be achieved in a single step. Take small steps to get the - Increment!
Things like, HiFly - a small airline used to support other airlines. If, for example, there are people booked to fly from City 1 to City 2 on an airline. That airline, for whatever reason, might not have a plane available. So, in Europe, they might have a HiFly aircraft fly those passenges to whereever they need to go. Delta also used HiFly to experiment with new airroutes - cheaper than buying new aircraft - it was a short term experiment.
Solve BIG problems for users - that will create BIG value for the business.
Value & Features are NOT synonyms. We are here to solve a problem. Focus on THAT.
You are always in this balance between clear leadership and chaos; in fact that's where you're supposed to be - Ed Catmul - President of Pixar.
Your brand is how people feel about your product or service - Bill Beard (@writebeard)
So, experimenting will help you determine a successful route. Get stuff out fast, then iterate.
Umm - you are not "agile" if you are not iterating."
Remember - Agile does not have a brain - Scrum is a process, it will not tell you what to develop.
Focus on solving problems, by experimenting.
==
Right.
You may have noticed I stopped live blogging following the afternoon keynote today. Yeah. I kinda hit the wall. I ran into a couple of things that needed my attention at work, then the lack of sleep caught up with me and I needed to get out of the conference center for a while.
Don't get me wrong. The Dorint Sansoucci is a fantastic venue. I've seen few better, and many, many less good. I just needed to decompress, recharge the batteries with a walk about town and visit the amazing Christmas Market get some air and walk more than from one room to another.
For the North Americans who have never seen a Christmas Market, it is astounding. Pretty decorations, grilling sausages, mulled spiced wine, loads of variations on pastries, gifts galore - amny looking like they came straight from Santa's workshop.
Got back to the venue and realized I did not have the energy to try and keep up with Gojko's keynote on Snow White and the 777.777.777 dwarfs.
Instead, I sat with Ash Coleman, Matt Heusser, Diana Larsen, Carin Eaton and many more, just chilling and talking about our conference experience. Many of us then retired to get some supper at the hotel bar - enjoying a supper of chips (fries) & wurst or hamburger & beer.
Many great conversations today with George Dinwiddie (@gdinwiddie), Samantha Lang (@samlaing), Fanny Ptak (@StudienratFanny) and far too many to remember now. We talked, shared ideas, hopes for the future ... Oh, and we talked about testing.
I'm to bed early tonight as I have one more day to go, presenting a workshop with my friend Matt Heusser on Agile Leadership.
Good Night, Potsdam!
No comments:
Post a Comment