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!