Speaking at Agile Testing Days

Thursday, December 8, 2016

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?
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 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!!!!!!!!!!!!!!
===
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!


Wednesday, December 7, 2016

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!