Agile Testing Days, Conversations and Considerations (pt 2)

I'm sitting in my living room on a Sunday evening. A little over a week ago I returned from Agile Testing Days in Potsdam, Germany. Last Sunday, someone flipped a switch and piles of snow came piling down from the sky. 

 
Tuesday, that same person opened up all the channels and we ended up buried.

 

Yesterday it warmed up - like a bunch. We are now at "expected average temperatures" for November.  Between the rain last night and today, the snow is gone.  Not just gone but long gone.  Well - except for the piles from the snow plows shoving it out of the street.

I digress.

Instead, I have been thinking about conversations around the office. One of them was "So, did you get to Lean Coffee? You always talk about how cool it is..." Well, I must admit I did not.  Not once in Germany did I get into the official meeting place with a coffee and chat with people in typical "lean coffee" mode (time-box discussion around dot-voted topics put forward.) 

And I missed every single one.  Sheesh.

I did TRY! Three days I was up early, showered, shaved and dressed and down for breakfast. And three days something got in the way. Conversation.

One morning it was conversation with Matt Heusser and Meike Mertsch and ... OK, there was a rotating list of people in and out. I don't remember everyone who was there. Another time it was a veritable who's-who. Including Bob Marshall (@flowchainsensei).

My conversation with Bob that day was short. He headed out to Lean Coffee - other people allowed me to be dragged into more conversation.

The third day was amazing. I had several minutes with Bob - and no one around. (That actually is kind of a rare thing at a breakfast place in a nearly sold-out conference center.)

The conversation made me think of several things - and bits come back from time to time.

Simply put: Words have meaning.

Easy, right? Except, there is a problem with some people's approach. The question is, an you converse and share ideas in a way that allows your meaning to be clear with the other person, without causing offense.

OK, to be fair, that was not the conversation - that was one of the things I've been thinking about since. The way we frame ideas and thoughts and how we present them may make perfect sense to us, and leave others utterly clueless.

When people talk about "communication" much of the time they mean "how to say stuff." Except that is a "push" function - Communication is a "pull" function - what does the other person actually receive from what we are trying to deliver?

Can we deliver what people need, in a way they need it, in such a way that they can receive it? (OK, find Bob's stuff on going beyond the "Golden Rule." The thing where we don't treat others as we wish to be treated, but as they wish to be treated.) 

Can we find a way to share information that will be received - including how we frame the information we present? Can we form the images in our mind in ways that do not form negative images? Can we build positive images to build on?

Can we do things without causing injury or harm? Even to ourselves? Can we build a positive communication style and model that can help make things better?

I'm still thinking on this.

Agile Testing Days, Conversations and Considerations (pt 1)

I returned from Potsdam, Germany roughly a week ago.  I had the immense pleasure of participating in Agile Testing Days - speaking and interviewing speakers and participants - and on the Monday, "moderating" the finals of the Software Testing World Cup - an international testing contest.

Others have written about the testing contest in detail - I judged some continental contests and was present for the finals.  The cool thing was that the conference hosts flew the winners of each of the continental qualifying contests to Germany for Agile Testing Days, put them up and gave them all conference passes.  Pretty cool.

I found myself doing something resembling "play by play" at the testing contest - which proved more difficult than I expected! The challenge was describing something I could see but - even if you zoomed over with a camera - might not "see."  I don't know if that makes sense - ah well.  It was an excellent time.

The rest of the week, I kept running into various competitors.  We talked about testing and life and communications and... well, there were a few other points. 

As I was on my way out - at Tegel Airport checking in for my flight - there were some tester/competitors there also.  We spoke of the conference and the experiences we had individually and together - and the takeaways we had.

Then there was the topic that is always near and dear to me "This was great. I learned so much and have loads of stuff to bring back.  They (the company) will never pay for me to come back here next year."

So I said, "Well, there is a way - Speak." (Insert a chorus of "No! I can't! I'm terrible at speaking in front of people!"and other similar comments.)

Here's what I mean -

You just returned from a conference with loads of opportunity for learning and meeting people and hanging out and talking and... yeah.  You get the idea.

You have loads of notes and ideas.  The boss is probably going to want to know what you came back with and - really importantly - how can they be implemented at the company. 

BING!  (as in a bell going off...)

There is your entrance! 

Take the information you brought back - make sure it is written down or recorded in some way to help you remember it. 

Here's the hard part: Try the ideas.

Maybe not all at once - but maybe one at a time.  Look at the ones likely to help your organization and try them.  Not just once but try them several times.  If they work the first time, you want to be sure that that was not a one-off.  If they don't work the first time, was that because of the way you tried to implement them?  Who knows!  Look to see what happens. 

Record what you tried to do.  Record what you hoped would be the results. Record the results. Then, record your own reactions to what you learned from the trying of it. 

Record what you learned - how did it impact what you do and how can it be of value to your company?  Then, take these notes and ideas - write them out.  Describe your journey.

Then share it.

Writing. Speaking. Having a coffee with people at the office.  Having a beer with folks after work. 

The more you do these things,  the easier it becomes. 

===

What triggered this was a conversation leaving Agile Testing Days.  That is a really good conference.  However, these ideas can be applied to any set of conference learnings or take-aways. 

Try them.  Be bold.

I have every confidence in you.

LIVE! From Potsdam! Agile Testing Days - Day 3!

Thursday, 13 November - I'm STILL at Agile Testing Days in Potsdam, Germany.  I stayed up a bit too late last night doing things like hanging with folks and talking and playing games - then finishing blog posts from Day 0.  (ahem)

I was intending to make it to Lean Coffee this morning, particularly as I had not been there at ALL this week.  As it was, whilst having a nice chat with people over breakfast I lost complete track of time.  Oops.  I did stick my head in and see how things were going though.  It looked like a good group of folks divided up into 3 tables/discussions.
===

Sitting now waiting for the morning's keynote with Antony Marano talking on "Don't put me in a box."

If Antony, or someone else, walks up and says "Hello, what do you do?" Most people will describe something critical about themselves - this may be something related to their job or not.  In most of them, it is putting us in a category - a box.

Job titles tend to show how important people are - either in their companies or by some other model.

Comparatively, in the 1960's "Dads" and "Moms/Mums" had extremely narrowly defined roles around the house and raising children. The difference is that today these roles have shifted.  There may be some variation, but the general gist is toward more balanced work sharing.

Companies are like this as well.  In the 1960's there were very specific roles and responsibilities and things were pretty straight forward.  Today things are straight forward in a totally different way.  Usually.  Some companies are still acting as if they are in the 1960's.  Too bad.

The point is - work is changing - How we do things is changing.  Tony describes his first experience in "pair programming" - with his Dad on a Commodore 64 (I remember those!) He wrote a simple program to do some estimates so his Dad did not need to spend hours and hours doing calculations by hand - and they could spend more time together.

Except, when he went to work - he was told, in essence, "Ummm, sorry, we don't do it that way."

Point of the story - Don't do stuff the way someone tells you to do it simply because of the job title you have.  Look for ways to do it efficiently and effectively.

Moved on to another (familiar) story - working on a team "in IT" where half the people on the company say "Oh! You're in IT? I'm having this problem with my email/printer/something lame."  Except in this company, you had to get from one group of the company to the other, you had to walk around the atrium - there was a "rule" that one could not simply walk across the atrium ("You'd ruin the view the lawyers had... or something") an you HAD to walk around.  Except that doing that the people tended to spend loads of time walking around instead of doing stuff.

And then one day he got forgotten when the team he was working with (well, doing stuff with) that sat on the other side of the atrium went to the pub and forgot about him. Bummer. Yeah, that is kind of no fun.  No harm was meant - they simply grabbed the folks that were around them and went.

So, there was an empty desk near them, and he packed up his stuff and moved to that desk. When asked why, it was so he could work better with them.  Actually, it was to make sure he would not get forgotten when going to the pub - well - maybe it was to really work better with them.  Asking questions and getting better understanding - and soon, the devs are all working with him to make sure their stuff is right and they being referring to him as their "go-to guy."

"I don't think it gets the best out of people to call them a 'resource' because it gives the message that they can be thrown away."

And he's citing "Tayloristic mindset" of management!  ROCK ON!

We should not manage "Quality" by managing a process (YEAH!) instead we should manage quality by empirical evidence. What data points do we have to measure what we are doing? Can we have some real measures that make sense? 

"I think quality comes from people, not process."

And he's telling a story about testing games.  In this case, the computerized version of the tactical response training - the thing used to train police & soldiers on "live scenario" training - where targets pop up and you shoot - or don't.

The first time they tested that, they were given specific tasks - then repeat precisely each time.  Same people in the same role.  Except the thing was, that is slower than other methods.

To increase flow, the "entry team" for room clearing - the two guys who actually entered a room after the door had been forced and the "distraction device" was deployed & went off, the rest of the team could move to the next room without waiting for the two folks in the room to get out and take up their original positions.  THis allows fast movement, better flow and (frankly) acknowledges that there is a chance - a good chance - that one of those guys that went into the room may not come out.  Its a sad fact that this must be build into training.

It may not be exactly agile, it is lean - eliminating waste and increasing flow to support customers.  We can do that whether the "customers" are hostages to be released or application products to be released.
---
As always this week, loads of stuff was presented and I simply could not keep up.  I hope someone else catches stuff I missed... (oh, twittersphere?)
--
 Brialliant Question!  "Should testers need to learn to code?" FANTASTIC ANSWER!  "I dislike the work 'should' because it means 'I know better than you do what you are doing and how.'  In reality, people need to be concerned about being put into limiting boxes, e.g., specific job titles... Instead look into other areas, broaden your horizons and look to how many things can be applied in different ways in different situations." (Pete note: He's describing my definition of "context.")
==
Right - I'll be interviewing the winners of the Software Testing World Cup for 2014 - Cesar Brazil!  So as cool as that is, I won't be in a track talk for the first track session - We'll see what happens and what shape I will be in for the second track block.  See you all in a while - Cheers -
==

Christina Ohanian

Had a lovely visit with Cesar Brazil and then a nice hallway chat with Christina Ohanian (shetweeted a picture of her sketch notes from my talk yesterday. Pretty cool.

AND NOW! in Dan Ashby's session on Lateral and Critical Thinking Skills for Testers.

Dan Ashby

He launches by having a volunteer say the colors on the screen - except the words were colors - so, like, "YELLOW" was in Green text, "RED" was in Blue text, and so on.

Western logical thinking is based on the work of the "Greek Gang of Three" - Socrates, Plato & Aristotle. The thing is, most "logic" is based on argument.  The OTHER thing is, Plato had this habit of gathering information & putting into buckets - categories.  This became the root for describing "critical thinking."

For example - how do you get from where you live to where you want to go for supper?  There are any number of possibilities.  Walking? Taxi? Traffic patterns? Lights?  Then again, the whole world tends to look at things... differently.


Loads of examples - cool stuff - TOO BLOODY FAST (which is one of my heuristics for a good
conference session.)

Loads of good conversation& exchanges (another of my heuristics for a good conference session.)

Citing Ed de Bono - "You cannot dig a hole in a different place by digging the same hole deeper."  Cool guy - he coined the term "Lateral Thinking."

What kind of scenarios work for the supposition? What things won't work?  (Pete note: How can people keep learning when they are not sure what they are about?)

OK - More de Bono - "Lateral thinking is for changing concepts and perceptions."

Cool pic - "What do you see?  How many items can you see in the pic - simple, eh?

Then he does a cool "connect the dots" exercise.  It's pretty good and I won't take pics of that.  It is good though.  Have a chat with Dan if you want to see the examples.  

Lateral Thinking skills help us get to the ability to test the software (or requirements) or... see Alan Page's comment - "Good test ideas lead to good test design."

And another good example - wine glass stuff... As a bar tender I want to be able to pour wine from a bottle into a wine glass.  There are a couple of questions around the "acceptance criteria" - like "what is it made of? does it hold wine? and so forth.  Good stuff -

He then lists a group of books - de Bono's again - Thinking Fast and Slow - 6 Thinking  Hats... all good resources to help people improve their testing.

Right - that wrapped up way too fast.  Sometimes 40 minutes is not nearly enough time.
==
Lunch and a bit of a rest to let things assimilate.  Then afternoon activities.
===
Right - had a lovely conversation with loads of people - recharged the engines and talked with Jose Diaz - the conference ... master?  I don't know - smart man, good man (sadly a rare combinations sometimes) and generally an all around Spanish Gentleman, in the classic sense.

I'm back in the plenary session room to catch some concession talks.  I like the idea of them - short, concise talks on a topic the speaker is passionate about. 

First Concession talk I make it into is Test First Code Later by Christina Ohanian.  She's based in London, remarkably bright (see the comment I made about about the chat I had with her. Christina is making a bang at the start - "Great! Another Bug! Log it! That makes 50 bugs - we must be doing something right!"

NO WE'RE NOT.  We're doing it wrong.  If we have this number of bugs we're dfinding in testing something is serious wrong.  Why do we spend so much time chasing bugs and not keeping them out in the first place - Why do we have so many problems?

Heh - Maybe because we fail at conversations.  Conversations Matter. 

Can testers really get involved in the discussions before code gets written?  Yeah, that's right - they're there to ask questions.. .blah blah blah - ARE TESTERS ASKING THE RIGHT QUESTIONS?

Simply put, they can't ask any questions if they are not in the conversation in the first place (OK - see my note on Dan Ashby's talk - she is cruising along - pounding out points - hard to keep up.  Luvin it!)

Scenarios, sketches, condition lists, prototypes are all part of her description of "testing first."  She is cautious about prototypes - because too often they become the final product - and are poorly built because it was "just a prototype."  Ick.

What can be done though?

Well, Let's start with "Inspect and Adapt" - her note is "Use the Force, not a silver bullet..."
Next on her list is "Team Commitment" - Short lived success without that commitment.
Third - "Continuous Team Collaboration" - Two heads are better than one - as long as they actually work together and not independently.  
Fourth - "A Culture Shift" - The light saber at the end of the tunnel.
(Matt Heusser is missed during that talk)

Instead of asking "Have we build the right thing?" - ask "Are we building the right thing?"

Technology changes every day - Nothing matters if toy don't know what you're building -(pete note: or on what platform it is needed.)

Tools won't save you (Pete Note: AMEN! AMEN!)

Yeah - well done - very nicely presented!
---
Next up, Helmut Pichler is presenting (Fr)agile Quality.

Helmut is from Vienna, Austria and is a tester with ANECON Software.  The company offers assistance and support services in the area of "implementation strategies."  He is ISQI Cat certified, ISTQB certified - and - I missed the third item on the slide (sorry.)

Citing Standish Report on Chaos.  The 2012 Standish Chaos Report shows nice pie charts on failed projects between waterfall and agile projects - the percentages are different than the percentages cited y Joe Justice.  (Pete note: Interesting.)

Loads of examples of "failed projects" - mostly clippings from German language papers.

OK - there are some interesting numbers being said - and some bar graphs going up on the screen.  Alas, my German is not good enough to follow the slides along.  Not all are in German, but a fair number of them are.

Pete Note: Not a bad summary of the pros/cons and other ideas around Agile implementation.  It seems a bit pedestrian, but it could be me having a hard time isolating his points.
---
Coming Up!  The FINAL keynote of Agile Testing Days 2014!

Helping Testers Add Value to Agile Projects with Alan Richardson (@eviltester) - Yeah - I'm looking forward to this one.

We're set and ready to go - Jose Diaz is at the front of the room making some announcements- including that there is more happening after Alan's talk.

He starts with the observation that there are trends in the keynotes this year.  And that is a trend in message. I think to BREAK that trend he starts with the philosopher Warren Zevon and his master work "It ain't all that pretty."

How? By working on the reality that is in place - regardless of what people want to see - things get in the way of that.

Which brings us The Dread Pirate Roberts - Quoted by S Morgenstern - abridged by WIlliam Goldman to text and screen...

"Thank you for everything, Westley, good night now, I'll probably kill you in the morning."

Westley makes himself useful, he does stuff that adds value - and eventually Westley learns that the Dread Pirate Roberts is not the DPR - he's a fellow who learned the trade - and became the DPR when the previous DPR retired... and Westley becomes the DPR. 

Fine.

Except testers look at things from a different angle - They disabuse people of the notuon that they are something they are not.

Testers mantra should be "I'm not here to make you look good." I'm here to help you see what is and do it better,

We survive by learning to adapt to the system OF development.  (Pete - so Warren Zevon, Pricness Bride and now slides with images from Transformers (the comic books).)

In 1901 there was a news story about Annie Edson Taylor - the first woman to gove over Niagara Falls in a barrel - And the story that she would rather be shot from a cannon than go over a waterfall again.

Alan's comment - "I survived the waterfall, and won't do it again."

And now - William Blake is cited -

"I must create a system. Or be enslav'd by another Mans; I will not reason & compare: my business to create"
William Blake, Jerusalem

 Except - the first time Alan was on an "Agile" project, he's asked to write a test strategy.  Gah.

He was stuck on - Writing a test strategy - Poor stories and acceptance criteria - etc.ad nauseum...

And NOW we get Pink & the Brain! "Tomorrow, we take over the world!"

Except his normal behaviors from the past - where he can assert himself and take things on - excet it becomes very hard.  So he ned to expand his reality.

He needs to learn Java - the Perl - AND then he needed to learn & improve his TDD skills.

He did not know the technology so he had to learn it - he needed to also expand his skills and embrace the ideas in new ways.  He got to "what is "done"?  What can be done to advance what testing was in Agile.

THEN - the next task was "get to done" with no stories that fixed the stuff that was done... wrong.

NO-ONE ELSE knew what testing was supposed to look like - so he made it up.

Scary - BUT!  Life is good.

And Alan then reverted to form - He did what he always did -

Mat the "ptest process" and adance the goals.

When you look at AGILE in isolation - life kind of sucks (Pete: that's my paraphrase cuz Alan is FLYING past points - HOLY COW!!!!!!)

Instead - looking at Agile as a SYSTEM leads to broader understanding - this allowd us to look at things differently each and every time because we are on projects that are not like the last 5 or 6. We are wortking withy people who may not have worked with us before.  THESE are the things that REALLY contribute to to moving things forward.

And he's citing Sun Tzu's Art of War as a referene - YES -


Loot, Pillage, Raid and Steal from other disciplines - by "borrowing it - we need to give it back. So WE TAKE IT - that makes it ours.  (I think Alan has Viking blood in him...)

And here comes "Green Eggs and Ham" reference - but it is "Do not call me QA" (I got a pic of the

QA is not Testing - call it QA - he calls it Tester.  Ask for a "QA Team Report" and there will be silence.  (Pete note: AMEN!)

People new to Agile need help - let the experienced ones help the novices - but let people try things themselves!  If you impose YOUR model of "Agile" on a group - YOU HAVE FAILED!  You are no longer Agile - You are going to a dark evil place (well, Pete is paraphrasing cuz he's going right bloody fast.)

Foster of attitude - of helping testers; and of ownership - and of How to surviveloads of stuff.  Its all good.

"Only variety can absorb variety."  Stafford Beer restating - (Pete note: bugger - missed that original source - sorry.)

Teams absorb behavior & respond...

Testers need to help foster tester's survival.
 --
Pete Note - ALAN! I need some slides I could not get good pics of - unless u don't want them in the blog...
===

And NOW - Janet & Lisa are giving a retrospective?

I think?

A skit - brandy & cigars? Maybe a Boston Legal meme? so maybe its Scotch?

And Super Agile Person makes a return - and Jose is the barman - with a nice apron - and a ... mustache?

So they are going over the conference - with a C/W song in the background? if I knew country better I could tell you - but I don't.  Oh well.

Mobile testing - vendor demos - hallway conversations - and some unexpected things - like non-violent communication, non-judgemental observations (Bob Marshall's stuff) - and - improving relationships - and - failing fast, but does that really mean "learning fast"?  hmmmmmmmm - then the Open Space stuff gets mentioned - loads of fun stuff apparently - including the Lego workshop...

Then there was ... one of the challenge on their wall (in their workshop) - how do we get "skilled testers" - And now there is a room sharing their experiences - I'm not able to keep up - sorry -
==
And Jose is wrapping things up - bringing out Uwe and Madeleine - and recogizing Alex - who reviews the proposals - and WOW!  I got a thank you gift for the live blogging, etc - that I am to bring home to my lady-wife, Connie.  Thanks!  I am honored -

Loads of people make an event like this happen. 

And he is now thanking Matt Heusser and Maik Nogens for their work on Software Testing World Cup.  That was a bunch of work - and loads of effort

Next Year - Nov 9-12 - 2015 - In Potsdam!
And on Tutorial Day - a kid's track - something appropriate for children that works in line with the theme of Agile & testing - Way cool idea.
Coming UP!
Agile Testing Day - Netherlands - March 19 - 2015!
===
This ends the day 3 Live blog - thanks for playing along -
Finished with engines.

Almost LIVE! From Potsdam - Agile Testing Days 2014 Day 0

Monday, 10 November in Potsdam Germany saw a day of tutorials and the first ever Software Testing World Cup Finals!

Matt Heusser asked me to assist him with his Lean Software Testing tutorial - which he was offering as a 1/2 day format for the first time (drinking from a fire hose ain't in it.)  So, we had a small group - which probably made it possible to get through the material we had lined up - more than a handful an it would have been impossible.

 So, we ran a series of exercises and retrospectives.  We threw people in with little guidance - and they came away impressing me - I suspect Matt was equally impressed (you'd need to ask him!)  After 3 1/2 extremely intense hours, lunch break came.


I ended up grabbing an ironing board, ironing ALL my shirts, slacks, etc, (as I could not on Sunday, the day I arrived) then got downstairs to "moderate" the Software Testing World Cup (STWC) finals contest by the designated 2:00 PM time.  The contest started later than that, but an hour of prep, level checks and the like made it go very, very quickly. 

I had the chance, with my "broadcasting partner" Kira, to meet all the teams and chat with them briefly.  My intention was to wish them luck and generally be supportive - and give us an idea of the make up of the teams before we began the contest.

In short, we did a live stream of the contest with Kira and I doing commentary.  (One friend said it was a bit like listening to someone calling a football match with no actual football being played on the screen!)  It was a lot of work - and a lot of fun.  We had an excellent time.

Frankly, Kira asked some really good questions - they were pretty basic and showed she was not in software at all - but it gave me the chance to talk about what we could see the testers actually doing in the room - Mind maps, collaboration plans, time blocking - pretty basic stuff for testers used to Session Based Test Management (SBTM) or Exploratory Testing in general.  But, it gave me the chance to talk to some common misconceptions about software and testing. 

I'm not quite sure how to sum up the afternoon and evening.  When the dust settled - I tried to talk with each team for a few minutes - with the cameras off.  They all did extremely well in a fairly stressful situation and showed they were capable of far more than the 3 hours allotted for testing the software under test and reporting the results of those tests. 

I was impressed by the teams' behavior - and extremely impressed  by how the teams all mingled after the contest ended.  Loads of talking and laughing and having a drink together - Friendly competition at its best.

The winners of the African contest, OpenBox from South Africa, brought around bracelets for each of their competitors - one for each team member.  Others shared props and toys and all shared a laugh.

I've been told the livestream was recorded, I really hope it was.  I've gotten several tweets to the effect of "That was a brilliant answer!"  Except I have no idea what most of the questions were and not certain what I said - for the most part.

LIVE! from Potsdam! Agile Testing Days - Day 2!

Wednesday, November 12 dawned very nicely in Potsdam.  A soft, gentle morning.  Not too cool, very gentle weather.  Not that many participants were up and going at the same time I was - it was an excellent reception last night and may people continued the festivities into the wee hours. 

The theme of the party was "Carnival" recognizing the German Carnival celebrations that start regionally in early November.  Costumes and dancing - to tie in with Carnival in Brazil, there were Brazilian dancers, drummers entertaining the group - the party grew louder with the announcement of the winners of the Software Testing World Cup finals contest (held Monday evening.)

The third place winners were the team from Romania - the Army Ants, European winners.  The second place team was The Annunciation from New Zeeland, the Oceana winners.  The winning, first place team was Cesar Brazil, from Brazil - the South American winners.

I spent time yesterday afternoon talking with Lisa Crispin, Janet Gregory and (ahem) Joe Justice - from Scrum Inc (yeah, Jeff Sutherland's company)

===

Joe Justice is presenting his keynote on How Test First Saved the World.  He works fro Scrum Inc.,and runs his own 501-C-3 - WikiSpeed.  Wikispeed is a cool company focused on making ultra-high efficiency, ultra-low emission, road legal, practical purposes.

Joe put together an entry for the X-Car prize - and the results were astounding.  They landed at the Detroit Auto Show, and then were contacted by other manufacturers.  They are now capable of producing cars - and have 1 in Germany (arrived last night) to be assembled at the conference.

This started by Joe setting up some stories - targets such as "build a car that is low emissions", "build a car that is ultra-efficient" and "build a car that is road legal."  He modeled components, such as the body designed in foam, then built the car that went on display at the Detroit Auto Show - and a fan saw the picture - mocked up some variations - and THAT is what is now available.

Wikispeed calls these techniques "XM" - Extreme Manufacturing.  They employ the core principles of Extreme Programming - Joe was a Java developer and Scrum coach before he turned into a car designer.

Using these techniques, SAAB is building combat aircraft at a fraction of the cost of the comparable combat aircraft in the US - the F35.  Which, by the way, still is not in production because of "software errors."

These techniques are now in use at Lockheed Martin to fix the problems with the F35, and also at Boeing - and now at John Deere.

Tomes Law: Team Velocity+Portfolio Velocity = Transition Velocity - named for an embedded Scrum coach with John Deere.

What has been found in these organizations is that teams of 4-5 people make highly efficient teams.  Other companies, such as Raytheon and Tom Tom (the GPS folks) have applied these techniques and significantly reduced their backlog.

Joe was brought in to advise Unesco on stabilizing EU troubled economies.  Explaining how  Scrum worked, short iterations, short delivery and quick review - and now are looking at the way to revamp their company recovery plan - which used to require a 5 year plan with penalties for deviation from the plan - to an iterative approach for recovery.  Except now this needs to be tested.

The testers need to be able to support people by asking the right questions at the right time.

That is what we are supposed to do anyway, right?

Now - There are companies and organizations and countries that are working poorly that can work better.  Using Agile techniques in general and Scrum in particular can help people do better work and get those companies, organizations and countries out of trouble.

(Umm - Joe is going really fast - I hope that the someone else is catching stuff I'm missing)

Using Test First techniques wikispeed began building their cars using these approaches.  By using these techniques they can speed cycles and determine results of efforts faster.

Agile/Scrum - Reduces the cost to make change
Lean - Use less stuff
TDD - Build just enough stuff to save the world
---
That was the end of the keynote - perhaps a pretty good evaluation came from Huib Schoots - "That was an awesome keynote."
===
And in the Q/A session - Joe mentions how Beer helps testing - Yeah - Kind of what I said Monday at the STWC finals, and in Estonia.  Because - BEER HELPS TESTING.
===
Now for track talks...
--
I'm sitting in Richard Bradshaw's session entitled Developers Testing? Yes, and Enjoying It! 

I have known Richard cyberly for some time and engaged in some wonderful conversations, virtually and in person, the last several years. I have never seen him present (that I can recall) and am looking forward to this.  He's in the "Test Strategies and Exploratory Testing" track today, so I suspet that is a clue to his general message.  

And here we go...

Richard (NOT JOE!!!!!!!!)  is giving some information on actual events, an experience report if you will - of what he did at a client shop.  Often times companies view testers as the guy on the other side of the wall "firing bugs" (reporting bugs) to developers. This is, sadly, not uncommon.  THis was even a "cool" company all into Kanban, Pairing, TDD, DevOps, 2x weekly releases, on and on and on...

Interviews consist of "Right, here's a room with a computer and some software - test it, we'll be back in an hour."  You go home, then if they like the results of your work, they call you in for the discussion part.  The do something similar with developers - tossing them in and pairing with a dev for an hour or so, working on code.

So - What were they looking for?  The title was "Test Evangelist - a Test Specialist."  They were looking for someone who ould talk about testing and work on stuff and help people do better work.

Of course, a big part of that was to get developers to do testing.  So, Richard sat down and was asking questions like "so, how did you test this? how did you structure your tests?"  The answer consisted of "Well, we tried it a bit, poked around a bit - and seemed fine.  So, we shipped it."

Except, there was loads of testing going on - the people doing the testing simply did not have the vocabulary to explain what they did.  For example, they did loads of stuff - much in automated work in Selenium - and Richard came in and looked at the automation - and refactored it (as he was comfortable with webdriver.)

Except that soon, all the testing was being dropped on Richard - who really could not do all the testing.  There was simply too much.  On top of that, this wasn't really what he was supposed to be doing.  So, going to the boss, he asked and the response was interesting.  "Yeah, I kind of expected that to happen.  I would be surprised if you could get them doing all the testing.  This is part of getting them to test."

Richard introduced the idea of Session Mased Testing - Session Based Test management (SBTM) developed by James Bach, et al. Focused, time box test events to exercise pieces of the functionality.

The key to making this work is cutting down the charters to small pieces - and then cutting down the stories to much smaller pieces.  This allows you to work in specific bits - and test specific bits. Recording and capturing information is important - Richard's client used JIRA.  There are some handy add-ons that can help with that.

The realization that these things can directly impact the "quality" of the product - that they can do things that make quality better - both testing and non-testing activity - makes the idea of QA = Testing a different discussion - one that Richard (Pete Note: and I) are much more willing to have. 

Internal Talking Opportunities - Informal chats at the office - "Beer and Cheese Nights" Kind of like wine and cheese - except that no one there really liked wine.

And after posting a bit on TDD, there was a rush of discussion. So, he put a copy of "Explore It!" out in the company kitchen - sometimes open to specific pages - and the developers actually read it!  A book on Testing!

Then there was "Lessons Learned in Software Testing" - a 'fairly old' book (Richard's comment) but with loads of good information - stuff that is really valuable.

The then put out James Bach and Michael Bolton's Checking vs Testing - where checking began to morph into "change detection" - something happened and maybe it was something they did not expect.  With the "C vs T" thing - the developers found they were really, really good at automating the "checking" - because they had TDD, they had loads of examples to choose from for the Selenium script.

The result was that the devs became very very good at spotting differences and identifying their own software problems.

So, the shift began in the "Pre-Planning Meetings" - half day things talking about what was going on.  Except while people looked at the needs, the looked at the complexity - and sometimes code they'd need to work with or On.  And Richard began asking things like "What is this? How are we going to test it?"

Questions can be asked and answered - and sometimes the answer is that things need to be worked on a bit more - sometimes it is that things are pretty straight forward.  As the time to do something goes up, possibly a simple tool (helper) can be of value.  In one case, the weird problem to exercise the function needed a log reviewed.  Manually reviewing logs takes a lot of time.  So, the devs wrote a quick tool to review the logs - voila! Loads of time saved.

Then - this lead to development of code reviews and tests around them - including people developing tests because they saw there wasn't one created for the specific function.

So, the result was that bugs were dealt with quickly - and the dev pairs were self-motivated to find bugs and improve eah other's work.

Consideration of the need for testers on a team -
Alan Page's Generalist Specialist - "Jack of all trades, master of none"
If all the dev's are testing, who is developing? (and the other way around."

In the end - people were diving in and doing good testing work  The issues found were pretty central and the teams embraced the approaches Richard introduced.

---
Right - Nice summary and set up for my session!
==
whew - Here's my room 5 minutes before I started... SHEESH!

By the time I actually got going, there were no empty chairs and the aisle was full of people sitting and the space to my left at the front of the room (out of the frame) had 8 or 10 people sitting on the floor.  Wow! What a response!

I am absolutely humbled by the turnout.

So, apparently I struck a chord with people based on the twitter stream.  I always find it interesting what people latch onto and grab as a takeaway.  Thanks to everyone who came - I admit I was a little taken aback by the response.  I am honored by your kind reception.
--
Lunch time (when I got over to the food) had an absolutely brilliant conversation with three very bright testers all from Redgate.  Chris George (@chrisg0911), Emma Armstrong (@EmmaATester) and Gareth Bragg (@GBCamb) were all deep in a lovely conversation on testing and motivation and honest collaboration and... the topics were wide ranging.  We were so deep into it that we missed the first 10 minutes of the keynote - and then decided to keep going.

Sorry - I don't have notes from the presentation by Alexander Schwartz and Fanny Pittack on Insights from Happy Change Agents.  I was kind of looking forward to this as I had met Fanny at last year's Agile Testing Days - very bright tester as I recall.  I hope someone has notes I can check out please?
--
In the meantime, I check on the interview with Matt Heusser and Maik Nogens on the Software Testing World Cup contest, and a couple of questions around Matt winning the MIATPP award.  In the process of THAT - I stopped to check out the car being built in sprints, in the lobby of the hotel.

Check it out...

Assorted bits & pieces...

Planning Board/Scrum Team List

Uwe rushing to deal with a "situation"

Chassis, wheels and more stuff

And with the interview over, and a quick change of clothes (it is really warm in here - putting on something a bit lighter) I'm catching up the live blog and heading back to where the action is!

See you in a few minutes!
---
And the car is starting to look like a car!

And David Evans is now up for the "Pillars of Testing."  Looking good!

He starts with some really bad puns around Columns, Pillars, Greek Capitals and Roman Capitals.  (Pictures to follow when I get caught up...)

The issue is, how do we get to greater confidence?  What are the dependencies? How do we make things work?

Confidence is supported by Safety and courage - which are in turn supported by Stronger Evidence, Better Design, Greater Coverage and Faster Feedback - THESE ARE THE PILLARS!  (Well, actually they are columns, but you get the idea.  Right?)

THOSE in turn are supported by Collaboration and Communication, Test Techniques, Effective Automation, Business Engagement and - stuff that went to fast for me to get... GAH!

Last year's keynote stated "The Product of Testing is Confidence." In that, Confidence depends on the bits mentioned above.

These are the Pillars - Each pillar represents a measurable, valuable quality of Testing.  Each quality exists to some extent but can always be improved.  Aim to understand and improve each and balance it with others.

The Pillars/Columns rest on fancy terms of architecture that I did not get.  But, the intent is that they serve as the team foundations.

Among these are the Collaboration & communication - which rests on Business Engagement and Team Structures?  How easy is it to get information for the REAL experts - the people who know the system intimately.  These things are what the "Stronger Evidence" pillar/column rests on

Then we get the Test Techniques - which rests on Skills and Experience.  These two things are that which Better Design and Greater Coverage rest on.

Which brings us to "Effective Automation" - which relies on Application Testability and Configuration Management.   These support "Faster Feedback."

These ALL rest on Management and Leadership as well as Engineering Discipline.  The taller the pillar/column, the greater the need for a stronger base.How can we really build things higher without laying a solid foundation?

Many companies try to do just that.  A strong foundation is crucial.  The foundation needed is solid Organizational Culture and Values.

How can we use this?  Well, how about a Discovery Model?  We can look for things we simply don't know.

Another is as an Assessment Tool.  Self Assessment is critical to growth and understanding - it is hard work and calls for a willingness for deep self-awareness.  "We might be bad at this, but is it important?"

Then the third option is Challenge tool.  Rejecting something out of hand is not the point.  The real point is to get you to think about what is indeed needed.

David's New book is out though - and I DOWNLOADED A COPY!!!!!!  WHOO HOO!  Thanks man!
===
Official activities are done - but there are things going on.  The car build is still in progress, there is a reception this evening followed by games and the like.

Should be a good evening.

More later.  Maybe.

===

Its later - like - WAAYYYyy later.

Car Delivery status:  Done.

===

LIVE! from Potsdam! Agile Testing Days - Day 1

Tuesday, 11 November in Potsdam dawned a bit foggy outside, but the areas in the conference center were clear and bright.  People are recovering from the Software Testing World Cup Finals (STWC, #STWC2014) last night - which saw 6 teams competing in the same room on a piece of software.

I found myself moderating the contest - providing "commentary" during the live stream ... for 3 hours.  It was fun - it was a lot of work - and the beer afterward was extremely good.

This morning we have Jose Diaz making opening comments, thanking people who contributed to the conference (500 attendees this year!) and about to announce the decision of the judges in the testing contest last night.

There are several things I am looking forward to the next several days.  For example - there is a project to build a car at the conference - ummm - yeah.  Not kidding.

I've also been asked to talk with some of the presenters over the next several days - some keynote speakers, the organizers of the Software Testing World Cup, Jose Diaz and others.  It looks to be an excellent time.

Fair notice, I will be away from the conference briefly this morning - my luggage had a problem getting here.  Eventually my bag made it, just not intact. So, I'm talking with KLM/Delta about what happened and in the meantime I need to get my stuff home - so luggage shopping in Potsdam I will go!

Jose is finishing the introduction of sponsors now - Dynatrace, Soasta, Zalando (whose software was used for the STWC last night), Parasoft, SEQis and others... Some humorous, some very business like (Pete Note: if you've ever been to a conference where sponsors talk about their company in 2 minutes, you'll have a good idea - its too fast for me to keep up...)

===

Of some 3,000 people started out in the STWC, by the time last night came around, there were a total of 6 teams, 24 people.  Jose is presenting the teams on stage - QuadCore (Kitchner-Waterloo, Ontario) TestStar from China, The Annunciation from New Zealand, OpenBox from Cape Town, South Africa, Cesar Brazil from Brazil, and Army Ants from Romania.  All of them did an excellent job - and the winners will NOT be announced this morning, but at the party tonight (Pete Note: No - I'm NOT going to be live blogging during the party...)

The opening Keynote is being presented by Lisa Crispin and Janet Gregory, who just had a new book published "More Agile Testing" - a follow-on to their previous book "Agile Testing."  These two ladies spoke at the first Agile Testing Days six years ago.  Jose called for a show of hands who attended for all 6 years - a few hands went up.  Loads of hands went up for "who is here for the first time."

There are a few issues getting the presentation sorted out (technical problems) However, I can say that Jane is dressed at Captain Kirk (TOS) and Lisa is dressed as Mr Spock (TOS).  This is going to be itneresting (Pete Note - sorry - just realized I left my camera upstairs... maybe someone can post pics I can link to?)

"Welcome to the Future! Preparing for our Agile Testing Journeys"

We can't predict the future, but there are things we can do about making the future.  They refer to last year's keynote (find my blog post on last year's Day 3) with how people can loosen bounds and help teams work together better.  (Pete Note - I'd dropping the STTOS references - too much happening)

The question is "how do we move and work toward the future?"  There are sets of challenges we need to deal with, changes in context are pulling and pushing people away from their comfort zones.  New skills, new technologies, changes in communication models, greater awareness of product - We need to morph - shape shift into people - Elizabeth Hendrickson cited for Exploratory Testing - Cheezy cited for automation... etc.,

What testers need to do is have the ability to Lean - be the "T-Shaped" tester (wide breadth, deep depth in specific areas), cognitive thinking, "take charge of your career."

We need to be not only aware, but focus on our specific context.  We need technical awareness (to help drive collaboration), Exploratory Testing (Pete note: If you have not read 'Explore It!' why not?) other techniques - swarming, generative testing and (Pete note: ewwwwwwwwwwwwwwwww) "Big Data."

OK - generative testing is developing test data that fits specific attributes and what expected results should be.  By modelling around this, you can evaluate the data trade-offs within a system and may catch problems that can not be reproduced using more conventional approaches.  (Pete Note: this sounds a bit like data modelling/orthogonal arrays/pair-wise testing)

Distributed Teams have introduced new complexities - technology has developed over the last few years that can mitigate those problems and challenges.  Video Conferencing, Google Hangouts, Virtual white boards, etc., Sometimes the easy thing is to get up and go to where the other folks are - like walk to their desk (if they are in the same building) or go to their office (if they are in a different building.)

One challenge that has not changed is that Customers want us to deliver exactly what they are thinking of - except we are not mind-readers.  There are tools available - for example Impact mapping (Goko Adzic) can help facilitate communication and break down misunderstandings.  Story Mapping (Jeff Patton) demonstrate how the individual stories relate to each other - This gives us a visual representation of how the individual stories work together.  Doing this can help people think through what the software will do.

And we have an "OOPS!" moment as J&L realize that the screens look HORRIBLE.  "Works on MY machine syndrome."

Ah well.... So, after giving up on fixing the display - we're soldiering on. 

Citing "7 Product Dimensions" Mary Gorman talked about last year as a Business Analysis tools.  Citing Brian Marik's work on development approaches - BDD, TDD, ATDD, These are not NEW ideas - but people can step out and try them in new ways.

What techniques and ideas do we cling to that are not working today, or are not likely to work tomorrow, that we cling to because it is comfortable.  For example counting bugs, or tribbles, or... stuff.  We look at the "quality" of the process (Pete note: and process MODEL) and not at the quality of the actual end product.

Step away from the confortable and look for Business Value - do youknow / uudnerstand your stakeholds? What are their objectives? What problems are they trying to solve? Can we create a shared understanding?  These are not new ideas - yet we are still failing at these miserably.

Risk / Risk Awareness / Risk Assessments - there is a certain level of danger in Risks - what is it that can cause horrible results to the project? What about the product? What about the company and it's customers?

Uncertainty - Can we model how we chose to approach a problem?  Can we/do we understand the difference between complexity/complicated/simple/chaotic.  Consider the Cynefin model.

We have different approaches & tools to:
 - Understand the problem;
 - Mitigate Risk;
 - Visualize solutions...

Visibility / Openness is crucial.

We can learn and describe ideas using aspects of play - eg., Legos to learn /something/. Observation - What can we see? Why are these processes being used?  Is there a reason?  Are these things blocking Innovation?

If we fail to recognize the reasons behind things, we may be limiting ourselves.

"Every tester has an inner 4 year old." (Comment from their tutorial yesterday, did not catch the name.)

Consider - How will mobile apps evolve?  How will we test them?  How hokey will our bleeding edge tech look in 10 or 15 years?  This is key to looking at what we need to do.

What if we do an evaluation of risk profile, and focus on a risk or value based solution delivery?  This is not a "Test-based" delivery model.

Cites Cheryl Quiron - "When can I stop doing customer validation and Experimentation?  Um, Never."

What is next for you?  Consider what you need to do for your project/stakeholders.  Reject the "one true way" to test. Look at context of what we are doing.  Look at the core question you can address.  This is what we do as testers.  Test yourself.

And the Closing slide is showing a unicorn and dragon having a glass of ... wine? mead? something?  Celebrate and enjoy the conference - the POINT of a conference is to CONFER!  Don't just hang by yourself or your team - have lunch with someone you don't know.  Take notes - SHARE THEM!  Tweet Them!  LIVE BLOG (and I get mentioned) - (Pete Note: yes please - live blog, I'm missing loads of stuff.)

There is a continuity at conferences - each conference has a personality of its own.  This is created by the participants and the speakers.  It is the very people sitting in the room - the people who are here to learn - that shape that.

Question Time - #1 - What is the biggest Risk for testers?  Answer(s) - Stagnation, coplacency.

Consider that everything has advanced leaps and bounds - pro sport players who were super-stars in the 1970's are unlikely to make the cut today.  Training, tuning and growth techniques have advanced for sports, cars, manufacturing, communication -- why not testing!

Pete Comment: "grow or die."

===

Right. I had to duck out and pick up a new suitcase as the bag I checked got eaten or run-over or something.  Contents were generally OK, some of the clothing needed a really good ironing, but nothing critical seems to have been damaged.  ANYWAY!

Catching up via twitter & conversations on track sessions while I was gone.  I'm building an image of what the sessions I intended to go to looked like.  So, carry on with lunch everyone here (or breakfast in the States) I'll be back as soon as I can with updates and the next keynote.

-
Consider these conversations inspired by presentations (I wish I had been in)

https://twitter.com/huibschoots/status/532160761754583041

https://twitter.com/huibschoots/status/532157779386327040

-
Strategy Testing: Building a Product User's Mind

Roman Pilcher is launching into his keynote on how testers and others can examine what testers can do to understand what is happening with product development and what people intend the software to do.

In order to get the happy smiley face from users and customers, how can we approach that?

Welll - traditionally we had the "build a big plan then work the plan" - and that worked reasonably well.  Unless things changed, like the general business situation or the needs of the company or technology shifts or... right.

So, why can't we build a proto-type and simply see if it flies?  Which is great unless we examine what it takes to build a proto-type and people have a model they want to use or an idea - well that can be helpful.  If the purpose is that the new product "will be cool" can we really say that is a /good/ idea?  What makes it a good idea?

Instead - let's look at the Vision - the Goal.  Why are we trying to make this happen?  What is the "Over arching goal" we have (Pete note: That is my general, working definition of 'strategy'.)  And the now says "What is the Strategy?"

He approaches Strategy as "path to a Goal."  He talks about "I needed to come to Berlin - I could drive, ride my bike, walk or ... take a plane.  Each of these may be a valid approach. Since I was concerned about getting here fast, I chose to take a plane.

Then we get the Details - What Steps do we need to do?  Well, book tickets, pack bags, get to the airport, etc.,

And A Steve Jobs quote...

The point is, Vision needs to be more ambitious, bigger, what is the positive impact your product is going to make in the world?  (Pete note: I wonder if the droll, drab discontent so many people have is because their products fail that test?)

Once you have a product and yu can identify how the product will help people - Then - Choose your path and show it works.  The path can be identified as "Product Strategy" - Who are the customers?  Who will use the product (may not be the "customers")?

How does this benefit the company?

What is the Market? The Value Proposition and Business Goals?

What is your market?  State that in a clear-cut business goal - Eg., the first generation iPhone.  That was a fairly crowded market when Apple entered it - and instead of targeting that to the cool kids, the techology driven Personal Digital Assistant, they approach this from a consumer view - simple to use, powerful technology and filling a niche (even if it was simply a marketing definition.

Find an itch worth scratching

The whole "difficult to monetize thing" is OK but not an earth shattering view.  In fact, it may be a sign of a problem area around the very product you are trying to make/sell.

Sonos did much the same thing - the idea of a device that makes listening to music anywhere...
 -
Sorry - hit "Save" and it took a while to come back.
Picking up - Sometimes the idea of a good product isn't going to really make you money directly - It MAY be something to make you other products more attractive so that people can learn and grow.  What is it that we hope to do with this?

These are all important questions

So, look at the Target Group, the Needs of people - that question "What" for the product and the Value - the Why question.  These things combined actually define the purpose - the point of the function - the reason why we are building the product.

Next slide is the Stick from Top Gear - car show on BBC (Pete note: I rather like that show when I can catch it on BBC America)  He tests cars.  Typically very fast, very fancy cars - but he tests!

Define your strategy - consider the biggest risks - decide how to address it, right?  (Pete note: yup, sounds really easy...)  Then we can collect data - talk with people and get solid information. Sometimes this information is available empirically - we generally like it to be.  Then analyze the results & make changes as needed.  Then we can move forward and exercise the ideas.

This is the core of "fail fast"  We have to recognize that sometimes we get it wrong.  Even the best people make mistakes.Allow them to.

Create a failure tolerant environment. 

 Bosses typically don't go around to their staff & say "Well done, you failed on that - le me give you a big pay raise?"  Not so much.

Some climbers have this habit of climbing on boulders - huge rocks.  Typically they don't use ropes & other stuff like that because it is a challenge to keep them from entangling you. So, can we do something else?  How about Crash Pads - like "boulderers" use - pads put where they THINK they may land - something to brace themselves.

(Pete Note - my connection seems slower this afternoon - don't know if other people are on the wifi but - I'm missing a lot as I try and save the doc.)
 -
Questions/Answers - One problem is that software people tend to get sucked into the trap of "what do the customers want?  The question to be asked by SW people is, what need are you trying to meet/fill?  (Pete note: this is an important difference.  Consider the philosopher's statement "Yoiu can't always get what you want, but if you try sometimes, you just might find you get what you need.)

- What about anyone automating testing to do the vision or strategy?  Well, on a native basis, Roman has not seen that work per se, however, some aspects of TDD are actually part of that. If we address information based on what we are trying to do, then we can evaluate the real needs.

===
So this afternoon, instead of going to workshops or the concession talks, I was visiting with Janet Gregory and Lisa Crispin - then later Joe Justice.  These are recorded interviews for the conference - part of what they are doing Janet & Lisa's new book - and Joe on the amazing stuff on Scrum, Wikispeed and other   cool stuff.

Now we have Bob Marshall (Flowchain Sensei) giving a keynote on "The Antimatter Principle."  And he does not have slides - he does not know what he will be talking about (or so he says) but he is talking about what people do at work and why so many people working in software seem to bloody well hate their jobs.  Instead, he's going to talk about working with people and the kinds of organizations he wants to and is willing to work with.


The problem is very few organizations by and large, want to actually get better. (Awesome phrase that, by and large, Bob used that.  I'll give more on the origin of that later if I have time.)

So, where do you go if the Golden Rule and Platinum Rule are already taken?   The whole treat others as u would be treated; treat others as THEY want to be treated... except how do you go that is HIGHER than Gold or Platinum?

Simple - Antimatter - $1.7 Billing per gram -way more valuable than Gold OR Diamonds or... pretty much all else.

Bob's Antimatter Principle is:  Attend to folks needs. 

Most organizations trend to the "force people to do stuff" or "do stuff better" - OR - do what we tell you or you're fired.  Except that kind of sucks - particularly if the people who face getting fired are generally reasonable people.

So, if you want to do better, look to people's needs.

Bob trends toward non-violent communication, talks about people who model non-violence as a philosphy - AND how does that fit within software development. (Side note, Bob does software.  He's kind of one of us.)

He then asks a very simple question - What is the role of Software Testing "Talk amongst yourselves" for 2 or 3 minutes - And the room explodes into voices talking (yes, I used non-non-violent language on purpose.)

The question was essentially a question to consider how people look at their role in the world, if not the organization.

Bob launches off into the realm of Theory X and Y of people - essentially people are either lazy, shiftless, untrustworthy and generally bad-eggs (X) as opposed to people really wanting to be good, generally are good and wish good for others (Y) .

And is citing Taylorism ("Scientific Management") and how that really does not apply to knowledge work. The problem is that "software development" and any other form of knowledge work, is not really related to the "studies" Taylor did - which was essentially how you can maximize "a bunch of hairy blokes" moving pig iron from one place to another.

We don't do that.  These things don't apply in that the core work is quite hard to itemize.  How do you break "thinking" down into units?

Now, feelings, needs, of people (including management) and how teams interact with other teams, team members with each other, and any other "people/persons" that come into view.  And remember, customers and managers and spouses and their (and your) significant others are all people.
SURPRISE!

(OK - I'm kind of sucking at following up on this keynote - too much happening too quickly.

Default mode of the brain - What do we think about when we're not thinking about anything else?

Current research points to "ourselves in relation to other people" - us - our relationships.  That is essentially what our brains are thinking about - whether we are conscious of that or not.

Thus, one of the essential things our brain is looking at is relationships - central to which is helping other people.

How can we as Software Development professionals look to meet people's needs? (and the room breaks into discussion again)

And Bob is wrapping up (cuz now he knows that he just told us - his message)

How can we build organizations where less-stupid things happen and how can we get people to work, and build organizations like that.  It may take more time than any of us in this room have left - BUT -  using the message of the anti-matter principle - we can make a start.

Questions now (completely missed the 1st two - general gist was what does it take? Patience, work, diligence -communication (Bob mentioned that he's on twitter all the time - so I asked "like now?" via twitter - he has not responded... yet)

Needs tend to drive behaviors - and people have learned strategies for getting their needs met that may not be terribly effective.  THis is the core problem leading to many forms of conflict - like people shouting or threatening or engaging in violence to get needs met.

That is kind of the problem, isn't it?

It is not until intrinsic needs are met that the other needs become obvious.

The question in the world - why do people put up with the nonsense of people yelling at them at work?  Simply, because they have earned only the one form of doing things.  They have become blinded by their own needs to the abuse that is being heaped on the in exchange for a paycheck.
===
We have reached the end of the formal day - the party and celebration begins shortly.  It is an interesting day.

Thank you Jose, Uwe, Madeleine and your whole crew!