On the Coming of 2017

It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair, we had everything before us, we had nothing before us, we were all going direct to Heaven, we were all going direct the other way--in short, the period was so far like the present period, that some of its noisiest authorities insisted on its being received, for good or for evil, in the superlative degree of comparison only.

Charles Dickens, A Tale of Two Cities, 1859

I know a fair number of people who see the coming year as a portent of doom. I know others who think it means there is new hope. I know others who are looking about at other signs and portents and think something is coming, but they don't know what.

Simply put, I suspect this near-random marking of a new rotation around the sun will be what each and everyone of us will make of it.

Work wise, I have skills I need to learn, others I have let get rusty I need to clean, polish and oil. There are some things I need to think deeply on and consider further. I feel the need to become better at what I do. Not because of any external pressure, but to make myself better.

I am teaching drums again. I am playing in a pipe band again - two of them, truth be told, but one is mostly to help train the newer members until they are up and functioning enough where they don't need me.  I am looking at a handful of music performance opportunities with both of these bands.

I will be speaking at at least one conference, Agile Testing Days USA in Boston, in June. I'll be doing a workshop on "growing into Exploratory Testing" - an expanded version of the talk I gave at Agile Testing Days 2014.

I am considering submitting to proposals to a couple of other conferences. I haven't made up my mind and still have time.

Life goes on.

The daughters are each doing well. The grandchildren are growing. The cats are being cats. Clover the Garden Kitty, our oldest, went to "cat heaven" this last December. The other two indoor cats still sometimes look for her in her favorite places.

Do I have a sense of dread? Do I fear the future?

No.

Each of us are tasked with working to make the world a better place, every day. We may not be able to reach out and shake the towers of the mighty, but we can certainly improve our small corner of the world. Do that with all the strength and good will you can muster.

Go forth boldly.

Do not fear the night. Be a light bright enough so the night fears you.

Thoughts on Agile Testing Days 2016, Pt 2

I've been watching the continuing twitter feed as people unwind, download, and organize thoughts around the week in Potsdam at Agile Testing Days (ATD). I wrote one set of thoughts, mostly stream of conscious - a mind dump.

This one is different. I've been thinking about what makes a conference something where people go attend sessions, go to the "official" events (mixers, networking events, etc.,) and go back to their rooms for the rest of the time, and conferences that are events in themselves. Agile Testing Days  is one of the very few conferences I've been to that fit the later description - an event.

Loads of learning - Some decent presentations, keynote sessions, workshops and tutorials. No session will be to everyone's taste and that is probably a good thing. I'd personally like to see more nuts and bolts, practical "apply this idea" sessions and have begun considering what I have in the hopper that would fit that bill. Now, not every keynote presentation will impact people the same way. By the end of the week, I can see a need for a difference in tone and timbre.

Idea... People are tired. Mentally exhausted. I think of this as brains leaking out their ears. Looking to issue a "call to action" in the last plenary session is a challenge. I like the idea of a retrospective - a "what did we learn?" Less a clarion call to DO SOMETHING and more a gentle glass of something warm sitting by the fire.

Other Learning - I tweeted about how "people talking" was a favorite part of ATD. Yup - I did... here:  https://twitter.com/PeteWalen/status/806146808368025600

Why is that a big deal? In hallway conversations and breaks and quiet chats in quiet areas, people are free to delve into thoughts and concepts that interest them, or considerations on a topic that were triggered by a presentation. While this can be social, I find many of these are part of deep learning. They allow people to explore partially formed or considered ideas and help shape them by talking them through with other people. This is a key component to learning for many people, including me.

That ATD has breaks between sessions of a nice length, with snacks, coffee, fruit, etc., between each session, AND a quiet area (like, really, a designated quiet area) AND plenty of quiet nooks and crannies to sit and talk helps people do exactly that.

Social - Part and parcel of the "other learning" are social activities. A visit to the Potsdam Christmas Market before the official start of the conference, the Most Influential Agile Testing Professional Person Award dinner (MIATPP - this year's winner was Maaret Pyhäjärvi - @maaretp - extremely well deserved. Congratulations!) The "Sponsors Reception" and "Agile Games Night" - AND a Cabaret-type event after the Games - AND Lean Beer and Karaoke - AND a Women's Summit...

That was just the "organized" functions.

Meeting and talking and drinking and walking about the town and talking and going for dinner and talking and meeting in the pub/bar later and coffee and lean coffee and talking and beer and talking and whisky and laughing and telling stories and listening and listening and watching and thinking.

I know the organizers did not "make" that happen. What they did was work with the venue to allow it to happen. This is hugely critical and often overlooked. Getting people to interact is easy when everyone knows where everyone will be.

My personal learning - Don't over commit. Yup. That sums it up.

This year, in addition to all the conference stuff I normally do with ATD, and all the stuff I promised people we'd "talk about in Potsdam," I was also desperately trying to finish some testing on critical tickets for the day-job. Yeah, there was a deadline. There is always a deadline.

The result was, time I usually used to allow information and ideas to distill or settle, was spent working on projects that also required deep thinking. Result was even less sleep than normal for a conference (One morning I woke up after just over 4 hours and felt like a million bucks for having had "so much sleep"... yeah. Nuts.)

So. Don't do what I did. The recovery time took way too long this year.

Allow time to decompress. Allow time to sit and sip a coffee or tea or juice or water and enjoy the flavor and taste of it. Allow time to taste the beer or wine or whisky you are drinking. Going full speed all the time actually diminishes your ability to fully enjoy the experience around you.

I ended up doing that Thursday afternoon. Walked away so I'd be rested and restored enough for the tutorial on Friday. There were good things, fantastic things all around related to the conference. I was full. That was enough for now. That way, I could finish the week strong. I could do what I had committed to for the conference AND for the day-job. (I actually finished testing at the SAS lounge in Stockholm on Saturday.)

Give yourself the choice to step away from the world so you can enjoy and appreciate all that is around you.

With that...

I return to finish shoveling snow deposited over night.

To Jose, Madeleine, Uwe, Sabine, Stefanie and everyone else who worked so hard to make this experience happen - Thank you.

I look forward to Boston, Agile Testing Days USA, in June - and, with luck, the 9th installment of Agile Testing Days in Potsdam, next November.

Thoughts on Agile Testing Days 2016, Pt 1

This last week I was in Potsdam, Germany for the 8th instance of Agile Testing Days. Thinking about how to describe it, I find myself struggling to describe the week.

I found this year's instance a bit of a challenge on multiple levels. I had a fair set of expectations coming in. This is the fourth iteration I've participated in. All have been awesome. This year, I was involved in the Software Testing World Cup, helping with moderating videos, interviewing teams before and after the contest, judging the team reports.

I also helped with some of the interviews the conference organizers lined up - both as an interviewer and doing interviews. Loads of fun - and still, time consuming. In some ways, it interrupted the flow of the conference. This isn't a bad thing - just a thing.

I presented a new session as a track talk. It was a challenge in some ways. I had roughly an hour's worth of material - pared it down to 35 minutes, allowing some time for questions - except for one minor little point. I should have pared it to 30 minutes. Ah well. I think, in general, it went over fairly well. Some folks looked blankly back. Others, I think, got something out of it. The simple fact is, when you are speaking at a conference, that is the best you can hope for - that people walk away something to act on or at least think seriously about and take home to discuss.

I also spent a lot of time live blogging the conference. Every session I was in I tried my very best to represent what the speakers were presenting. Frankly, I am not sure I ever achieve that. But, I give it a solid shot. (not grape or chain). One thing I was very excited about, was the number of people who ALSO were live blogging the conference since I was here the last time. I know of 2 or 3 who took up the challenge.

The interesting thing is, people ask me why I do it? Simple. I take notes - I might as well share them. That's it. I write as fast as I can and capture as much as I possibly can. I know I miss a fair amount, but, there you have it.

Friday I assisted my friend and colleague, Matt Heusser on Agile Leadership. It was an interesting session, I thought. Frankly, I would have been interested in participating if I wasn't helping present it. ;)

The core ideas were similar to those that had been floating around all week. Leaders are to help others excel. Plain and simple - get the junk out of the way to let people be awesome. That is a paraphrase of the "working definition" that was set out. The lessons and exercises presented were variations on that theme. I think it was worthwhile.

The social events were, in a word, astounding. LET'S SEE -

A Christmas Market - yeah. Little booths with food, beer, mulled wine- a HUGE bonfire - a BAND - all in front of the conference center. Yeah. Americans might go, "huh?" But the German tradition, which has a strong base in my home town, still shows up from time to time. It is loads of fun. Then there was the "Awards Banquet" - A costume party with winter and Christmas themes behind them - Oh wow. What fun.

Wednesday night saw a "Sponsor's happy hour" - where there was a pile of grilled food - yeah, bonfires out front again cooking food, followed by a Games Night. I ran a table there - but there were a PILE of folks running similar tables. And loads of people having fun. AND THEY WERE EXERCISING TESTING SKILLS. It was awesome. Really, really fantastic.

Conversations. Oh man. Smart people. The folks I named in the blog posts from the week. And there were others that stand out. The organizers - Whoa. Loads of work to make an event with 600 people participating come off with out a hitch. The usual host, Jose Diaz, was down with the flu for most of the week - he surfaced on Friday. Madeleine Griep, Uwe Gelfert, Stefanie Reusner and all the rest of the crew. Exceptionally well done. The lot of you picked up the slack from Pepe being down and looked like a flock of ducks - serenely floating on the water, and paddling like mad where no one can see. You all put on a clinic. Well Done!

Let's see.

Lisa Crispin, Janet Gregory, George Dinwiddie, Huib Schuits, Alex Schladebeck, Maik, Meike, Lalit, Carin, Karen, Sam, Ang, Santosh, Gil,Mike & Michael, Stephan, Eddy, Gitte, Diana, Sabine, Claudia, and, and, and - so many people. So many deep thoughts. So many things I need to ponder from them yet. Great conversations from "whole team" and "3 Amigos" to stories and... "tell me how you met" and ... everything.

I found myself sitting with, at one point 5 or 6 women talking about the world. Someone asked it I was uncomfortable - Nope. Absolutely enjoyed it. Open conversation and sharing of ideas on nearly every topic imaginable.

In short, this was an astounding event. I slept little and did much thinking and learning. Less drinking this year (good thing) but fantastic conversations that have impacted my thoughts more than any week I can recall in years and years. The information flow was non-stop. Oh, and there were really good conference sessions, too.

There is one thing I can say with absolute certainty. Do NOT make the single major mistake I made this year. I had work to do for the day-job and I foolishly thought I could finish "the last few tickets." The problem is, my moments of quiet time that I use to assimilate the information I've received that day, or at least up to that point since the last time. Look. When you are conferencing, conference. The little rest you get is needed. Nothing to do with hanging and drinking with folks. It has everything to do with absorbing what has happened so you can take it back to the day-job.

Right. Anyway.

There have been so many things I am still trying to assimilate. Look for a Part 2 when I find the right words.

Live! From Agile Testing Days! Day 3!

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 Etsy.com, @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 -
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.

So, how about MVPs - the most valuable players/people?
--- {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!

Live! From Agile Testing Days 2016! Day 2!

Wednesday, December 7 - cold. cold cold cold. Overcast. Did I mention cold?

Good thing we're still inside the Dorint Sansoucci in Potsdam.

Last night's award dinner and party was a tremendous success. The winners of the Software Testing World Cup were announced (see yesterday's blog post for that.) What ELSE was announced was the Most Influential Agile Testing Professional Person (MIATPP).

The winner of the 2017 MIATPP was Maaret Pyhäjärvi (@maaretp)!  Terribly pleased with this announcement. Congratulations to Maaret! Well deserved.

This morning Michael Sutton is warming people up for the first keynote of the day. This will be Diana Larsen (tweets at @dianaofportland) whose topic is Liftoff: Start and Sustain Successful Agile Teams.

(Umm, internet access is toast right now, what’s up with that?)

Diana opens with the recognition that the in open space events, the right people for the discussion are those that are in the ones that are in the room at the right time.

And we’re having a reprise of the issues I did not mention in yesterdays keynote – man – loads of challenges with sound this morning – and internet access.

When Diana got into “Agile” she hung with some of the XP guys and have been engaged ever since. Do you use some form of Retrospective in an Agile team? Yeah. She wrote the book. Literally – Agile Retrospectives.

The point of the “Liftoff” book was to help teams get to where they want/need to be – so they can achieve Successful High Value Delivery

That means:

What the customer wants and accepts;
That creates value for the business;
In a timeframe that fits the customers’ needs;
Easily maintainable and supportable;
Leaves the team members with increased capability and eager to work on the next deliverables.

Thus people can deliver useful, high quality software and where the team learns enough to employ what has been learned in the next project. Thus, we need to avoid deathmarches – because, well, at the end of a deathmarch, we’re… ummm… dead.

Are we really ready? Do we know what we need to do to drive to a scenario where those things actually happen? If so, we’re ready for a Liftoff.

Now, if you’ve launched and having problems, it might be wise to stop and relaunch. After all, many of the stories, anecdotes, etc., presented by the “experts” are actually relaunches of the original effort.

Teams a Complex Adaptive Systems (CAS)

One challenge is that teams are collections of individuals, within a large collection. Hence they are a system. Specifically a complex system (that is a very specific term, I’ll try and post a link to a definition when the dust settles).

In addition to being a Complex System, teams are ADAPTIVE – they change! They adjust and adapt. THIS IS A HUGE POINT when getting ready for liftoff.

One aspect – are the teams really cohesive? Do they work well TOGETHER?!?!

Promote Team Cohesion with Liftoff Design

Group Cohesion is a multi-faced process

Conditions for CAS?

What Containers do you want to establish?
What DIFFERENCES will show up?

Set the conditions PROPERLY for team learning – 

How? Remember these are HUMANS! (duh) Keep the team emotions ALIVE! People will learn best when their emotions are engaged! Appeal to the sense! A dill boring lecture is generally a terrible way to lean for most people.

Do it for real – learn by doing it. Keep people interested by having them do the work and learn to master the real work! Exercises are OK to start, but get to the real deal QUICKLY!

Keep stuff obvious – “Start Obvious, Stay Obvious” – make sure people can get a quick grasp of what is going on and needed.

Focus on the flow – no really. This is what will help drive learning.

When you are able to do this, THEN – Keep the setting first!

Choose Liftoff Activities (Pete comment -wisely)

Get the executive sponsor involved and ENGAGED – They can help explain the greater purpose and goal. You may consider “typical” Sprint 0 types of activities. (Pete note – I’ve seen this work really well, when guided properly)

Training Boot Camps might be of value – Consider both Retro & Future-spectives, etc., etc.,

No matter what else – DO include Collaborative Agile Team Chartering (this is a must!)

Chartering Model?

Integrate Purpose (Inspire)
Alignment (Collaborative)
Context (Dynamic)

Get people involved EARLY who can help guide those things – Produce Management, Sponsor, Facilitator, etc.,

Why?

This is where we let people know that this is worthy work, that this is something these people should invest their time and energy to act on this work. We can talk about

 

Purpose?

Product Vision (how will someone’s world change? What is the effect?)
Team Mission (what is the nature of the work that will need to be done to make that happen?)
Mission Tests (examine and TEST the mission – then write some tests that will help us measure and engage in the tasks at hand? Are we on track?

Alignment – This is how we commit to doing the work TOGETHER!

Simple Rules guide a system (pretty much all systems) and guide cohesion.
Core Team – why have people been engaged to be part of this team?
Working Agreement – stuff like, “What is DOD?” “What are our core hours?” “How many meetings will we have & how frequently?” – Stuff that actually guides the work.

Context – This is the piece that is usually most ignored.

How does this team fit with the needed work and how does this work with the team, the effort – and how does this work/team/effort fit into the broader system of systems

Go ahead and say Resource – really 

Committed Resources can be work space, tools, training, servers, etc., etc., Plan for that

LOOK FOR RISKS! (have the team help with this so they understand better what they may be facing. THIS IS A BIG DEAL.

The Charter - 

This is a living document, not a dust collector or door stop!

Help teams build the energy & momentum to help teams get thru the liftoff. It can be hard. Don’t make it any harder than necessary.

And we're over time!

Break now - then I present!

===

Right gave my presentation - handed out a LOT of chocolate bars. Had a bit of fun. Now up in the room changing shirts (it is WARM down there today!) and having a cool drink. I'll be back shortly!

Oh, Look for a live blog review of my presentation (which was recorded and will be played back later today!)

===
 

Right - I'm at a testing conference, so I did some testing for work between my session and lunch - and NOW I'm geting ready for the afternoon where Huib Schoots and Alex Schladebeck are getting ready for their keynote. However, Michael Sutton is up to something and this should be fun.

So ... Once upon a time... there was a lovely princess and an ugly ogre... Yeah. This is on telling a story.  

One upon a time, when Huib was a school boy, he had a hard time sitting still. He got put behind a pinboard so he would not distract the other students. He went into programming and… got trapped in tules.

Their goal for today is to focus on telling a good story – well.

Clips are being played –

I have a dream – Stay hungry and stay foolish – Vulnerability is not weakness – Yes we can

Right, so the point is, these people were telling stories in a compelling way. If you come back from holiday or vacation with a bunch of pictures, how do you describe them? In a story or in facts.

1 jeep 1 driver;
3 zebras, 1 jeep

Telling compelling stories does not come easily – it takes practice. Lots of practice. But – we musdt make it compelling. How?

Freytag’s Pyramid -
Expositon (background)
Rising Action (conflict)
Climax (high point)
Falling action (results)
Denoument (wrap up of the story)

And they play an ad from the Superbowl, with the puppy & the horse from Budweiser – the “Best Buds” tagline series.

By sharing stories with others, we understand each other better and we feel like we are part of a group, a clan. Don’t tell numbers, tell stories.

The stories we tell as a group, as a culture, helps us remember and make us come together, e.g., the Unicorn with ATD! 

If you put a series of specific bits, without context, purpose or motive, people will tend to make their OWN stories based on their own … thing. People will fill in the gaps of a story or bits of facts and build stories out of them. That is part of how telling partial facts, disjointed, in a compelling way can draw people to the conclusion you want them to reach without actually saying, precisely, what they want people to take away.

Conflict is crucial to storytelling – the hero/villain thing is based on this. It also tend to have the impact of changing who is the hero, based on the perspective the context or condition in the story.

The nature of stories can, and will, change people’s brain chemistry – so “sad stories” can be used to evoke the emotions of people to donate to charity or go to war.

So, what about testing?

A story is a tale about the status of your product.
 

A story is how you tested it.

If out test reports are charts of number, a couple of things can happen. They can give all the information in a simple manner. However!  Remember the bit about how people will build a storu to fit what they have and fill in the gaps?

Yeah. That .

Numbers are important - Stories are more important.

So, getting into the question of WHY? This is a crucial point. When looking at projects, ask “Why?” first – long before “How?” is considered.

How?

Demo & sprint reviews;
 

Personnas;
Risks;
Bugs & Familiar problems;
Tests/charters;
Consulting;

All of these impact on stories and shape the story of the project. Checklists can help – Stories fill in the blanks.

Software & software development is not about computers. It IS about things that benefit humans – PEOPLE!

So Huib & Alex are having people tell stories – 1 about “What are you passionate about?” and 2 – what was the dumbest thing they’ve ever done in a project. Point made.

Alex relates the story of her violin. How her dad would play recordings and have her “draw what she heard.” She told the story about how she learned about it. How the music given her by her dad was the greatest gift he could give her. Playing music can, and will help express the world. (Pete Comment – Oh yeah, should have brought my small instruments – instant session!)

Mind maps sent to people do not communicate well. They CAN be used to drive a conversation, and a story.

==

OK - Minor delay. I have 1 more interview session to do. Until THAT happens, I'll be liveblogging a thing on... Releasing without the numbers, by... me.

Came in late - I'm wrapping up a summary on various policies like lock down, no high priority bugs, etc., and some examples - healthcare.gov, Rhode Island benefit system, Australian Census, etc.,

So, if these disaster projects had solid metrics showing that the software was ready,  how could they go wrong? What was the real issue? What do the "hard facts" tell us about the software. I suspect that it DOES tell us about the state of software development management.

Facts are awesome because they are facts. Except... wait

Emotions have a much stronger impact in making decisions than outside data points. What are we really deciding on? How do we avoid having P-0 or P-1 bugs? We make them P-2! Or - we just don't write them up!  

In most Agile shops, there are some level of communication, some regular meetings, touch points. Yeah, the problem is Standups can get really long - But, can we have an impromptu meeting? Can we pull together the people involved from each group, and talk with them? How is your part of the project going? What are you running into?

The challenge is that it is possible, if not common, that management and individual work teams have different perspectives on the same body of work. Get the people together who are working on this - and have them talk. "How do you feel about the state of the project/release."

And I describe the study from the Journal Science - Durably Reducing Transphobia: A Field Experiment on Door-to-Door Canvassing." - Link Here

And I cite Lord Kelvin - and... I get pulled out for another interview. I get done with that and needed to check in with work. 

Right now, I'm in the Open Session room - loads of fun, more people than I expected.  Two sessions going at a time - cool! Here's Janet Gregory's tweet on one of the sessions.

Open Sessions are time boxed, self-selected discussion on topics the participants suggest in the room.

Up next is a short break followed by the closing keynote of the day - followed by testing games, a nice cabaret and a bit more fun.

Right then - Closing keynote of the day from Keith Klain (@KeithKlain) on Lessons Learned in Selling Software Testing. Large organizations have heavily outsourced an commoditized. 

Warns against false experts - quotes Kahneman - the question of people being considered experts because they said they were experts.   Wonders about the presence, or lack there of, on skepticism.
 
If you get up on stage and speak, you should be open to a greater amount of scrutiny.


States that when he left Barclays, a job he loved... involved self-questioning - "I don't know what the @#$%&! I'm doing"

Suggests people get out of their bubble and do a challenge of their own beliefs.

Keep your objectives in mind.

Testing is an information based science. We should test to learn something. And questions the intent to "automate everything." Organizations spend a lot of money on stuff and get no real value out of it - not even the simple stuff.

Cites the "Leprechauns in Software Engineering."

We have to fight against people selling crap all the time.Some 50% of enterprises use some form of a Testing Center of Excellence. Except they've spent so much money on the TCOE they don't want to walk away from that.

Smarty Pants syndrome - when criticized, recede into a third culture where they ... "tiger cub?"

Criticizes passive aggressive word correction - like "suggesting" a gentle change or correction when trying to be "nice." 

Compares the Hilary Step on Mt Everest with a career in testing. (Some 40 feet of sheer ice face to make the final summit of Everest.)

Looking for information about your business? Look at the company's publicly filed papers for public or privately traded companies. Listen to the quarterly stock performance calls. 

Critical bug test - what was the last critical bug you found and what would have been the impact to the business if it had gotten out.

Testing is a service, not a servant. (Pete's note - I am not certain he and I have the same definition of those words.)

Quote Feynman - We are never right, we can only be sure we are wrong.

The reason why it's so hard, is because it is so hard.

and into Q&A - 

With THAT! We have the Sponsor Speed Round, the Sponsor Reception and a Beer Testing! and Agile Games!

SPONSORS

THANK YOU FOR MAKING THIS EVENT POSSIBLE!!!!!!

Devoteam

D&H 

Easit 

here

jamo Solutions

iSQI

SeQis 

OTTO

Novatec

TestObject

SEASIDEV

Kreuzwerker

Thanks to all of you for sharing information about your company!

And now - the Reception!