Tuesday, November 11, 2014

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!

No comments:

Post a Comment