Tuesday, December 9, 2014

On Learning, Growth and Leaving Childhood Behind

Of late, I've been thinking a great deal on how people learn - how they "stay current" in their profession, to resurrect a buzzword from longer ago than I wish to recall.  That got me thinking.

What have people done to learn something recently?

Let me see if I can explain where part of this thought developed from. 

In the "Liturgical Year" I am writing this in the Second Week of Advent - the time of religious and spiritual preparation for Christmas. The Sermon/Homily this last Sunday was one that featured a note of irony.  The gist of it was that Advent, the season of preparation, is one of waiting.  People get ready for something they know is coming, but are not sure when it will actually come.  The priest's point was that in an era when Christmas music starts on the radio and in shopping malls a day or two after Hallowe'en, when society is rushing toward a fixed date, the Church is asking people to pause and consider what may be coming. 

On top of this, a few years ago, before the previous pastor retired, he gave a sermon about this same time of year.  He stood in the middle of the church, the main aisle, and pointed at the stained glass windows that ran the length of the church - both sides.  They really are lovely to look at.

Anyway, the pastor made a comment that many people's idea around matters of faith are those of a small child - the same basic things one learns in school, maybe age 7 or 8. People like the idea of Christmas and the child in the manger and the shepherds and the lights and tinsel and what-not.  But they don't like the "opposite bookend" as the pastor described it.  They don't like the story of that same child beaten, flogged and executed in a manner that boggles the mind of most people in this day and age.

As he was talking about this - he pointed to two windows.  One, on his right, depicted the Christmas story. The other, on his left, exactly opposite the first, depicted Good Friday - the death of the same baby.  His statement was simple. We can't accept the simple, childhood story without looking at the hard truth that accompanies it.

As mature adults, we need to step beyond the things we "learned" early on - either as children in school or as fledgling software professionals.

When was the last time we challenged our own beliefs and presumptions? When was the last time we critically considered what we were about? Have we become complacent?

Are we still operating based on our childhood understandings? Are we still operating on things we learned years ago and have not thought about? Are we passing on this same "wisdom" to people without a deeper understanding? 

Why?

Should we simply accept the pronouncements of people whose learning and understanding stopped when they were 7 or 8 years of age? What about "professionals" whose learning stopped 10 or 15 years ago? How about 25 years ago?


Sunday, December 7, 2014

On Growth and Learning and the Wisdom of Unicorns

I got a phone call the other day from a development manager who was not sure how to deal with a couple of issues and wanted to bounce ideas off a neutral party. We met for a coffee and chatted for a bit and she got a very distinct look in her eye - one that meant she was at the place she needed to be in order to ask the questions she wanted to ask.

"Why don't people want to learn new ideas about making software?"

Oh my. I admit, that made me put down my coffee cup and ask what she meant.

"I don't really know,and that is frustrating me.  Let me explain.  We talked before about how people are 'motivated' and I get your point that external motivation does not really work, at least not for the long-term. I understand and see now how the 'threat-reward' model I've been told to use really doesn't do what we want it to do. It certainly did not work when I was a developer, why should it work on other developers?"

"OK, fair point," I said. She smiled.

"I guess my problem is I don't know how to encourage people to learn something new - how to try and look at their careers as being more than what their job is right now. I can offer classes and they aren't interested. I offer to set up lunch and learns and bring in whatever food they want and no one is interested. I send out notices of meetups they might be interested in and no one goes to them. I offer to bring in outside instructors to teach cool new techniques and no one wants to be bothered. 'It doesn't apply to what we are doing' is what they say. How do I overcome that?"

Ouch. Yeah, it reminds me of a shop where I worked where over half the folks writing production code wanted nothing at all to do with "new languages" or "new ways" of doing things. The new language in question was COBOL - yeah - that was the new language. Mind you, I was teaching myself VB and C at the time so I had no sympathy for people not wanting to learn new stuff.

There is an idea that I find troubling in the recurring theme of "you can't make me learn new stuff" - until the jobs using the "old stuff" all kind of went away. (I know there are still a bunch of people doing COBOL, but as a percentage of all software development? COBOL used to be THE language for people writing software for businesses - it's now a benchmark for how old you are in many shops.)

We talked on that a bit. We talked on the question of "how do I get people to go to GR Testers meetups" - the answer to that one is easy "Offer something they are interested in."

We talked a bit on the number of developers and testers at the company where she worked - and the percentage of those who expressed a desire to learn more things - at the entire company, not just on her team.  There are some who are hungry for more knowledge, information and ideas. Then there are the majority of people who shrug and are not interested.

I warned her to be careful of rejecting the idea of learning new things because they "don't apply" right now. I have learned so many things that can be applied in multiple contexts that they are amazing to me when I look back at them. If I had rejected things because they "don't apply right now" what I really meant was "I don't see an immediate application for this nor do I see how it will help me in the short term."

That does not mean I will not seek out information or ideas I can apply or might be able to apply. If I have a choice of learning opportunities, one that has a direct application to where I am in my professional path and one that does not, at this time, have a direct application I can see, I tend to go to the first option - particularly if they are happening at the same time.

"But, Pete, you're an expert. What is there really for you to learn?"

Oh dear, First I'm not an expert. I am learning all the time. There is much more for me to learn. When there is nothing more for me to learn, then go ahead and say I'm an expert. Until then, I need to keep at it.

At that point, the Unicorn at the next table cleared its throat and harumphed in a significant way. I was a little surprised to see him, this was not the usual coffee shop where I'd run into him.  I was a little taken aback. The nice person I was chatting with had eyes that looked to be bugging out.

"I can't believe it! When did a Unicorn sit down here?"

The Unicorn smiled and said "I was here when you sat down. You finally noticed I was here, that's all.  Forgive me if it seems I was eavesdropping, but there is something maybe you could point out to your team."

At this point, I was not really certain what to expect the Unicorn to say.

"Remind them that all the people complaining about not being able to have a chance to apply for the new 'technology' jobs we keep hearing about in the news - the ones the 'tech companies' say need more visas to allow workers from other countries to come in and do - Many, not all, but many of those people had the opportunity to learn these new languages and techniques and chose not to. Now they want to be 'given a chance' and learn them, but I think for many it is too late."

I jumped in (a fairly brave thing to interrupt a Unicorn) with an observation. "I don't know if that is a fair summation of what is going on. There are many people who have been trying to learn these new things and find themselves pulled away for other responsibilities. Not everyone has the time or resources to learn and embrace these new technologies and techniques."

The Unicorn smiled and said "But the things this nice lady here has been describing seems to me to be presenting these opportunities at little or no cost to her staff, other than time, and they are rejecting the chances. In 5 or 10 years when there is some cool new technology the company wants to put in place, how likely is it that the people who were offered and rejected an early start will get to work on it? How likely is it that they will find themselves relegated to 'maintenance' for the old system while the new system is being developed?"

I sat back and realized I had seen that pattern many, many times in the last 30 years. Suddenly, I felt very sad.

The development manager seemed deep in thought. She asked the Unicorn what she could do that might help her team - warn them from this path.

He looked at her and smiled. "Lead by example. Take a course on something new. Go to some of the meetups when you can - let them know you are going and offer to make an outing of it. Offer to pick up dinner for anyone who joins you.  I know you have kids and responsibilities.  How many nights do you work late at the office? What if you were to bring papers home and work on them from home after the kids were in bed instead? What if once every two weeks, or maybe a month, you came home after a meetup and tucked them in?"

"You could explain to the kids that you had to go to school to keep learning new things, too - just like they did. And sometimes the school class was at night. The children may learn something about always learning. Maybe your staff might learn something as well."

As I drove back to my office that day, I thought about the Unicorn. He had said things I would not have dared say - and part of me wanted to reject as "UNFAIR!" Except I learned long ago that many things are unfair.

Baseball should allow 4 or 5 strikes before the batter is "out." (I had terrible hand-eye coordination as a kid - that seems perfectly reasonable to the 9 or 10 year old self.) In (American) football, there should be 5 "downs" to advance the ball 10 yards for a first down. These would make it "more fair" by some measures - and then unfair by others.

We may not be able to change the way the world is, but we can change how we respond to it and how we act to others who are also struggling to respond.  We can lead. We can help others along the path, if they want help. We can continue learning.

If you are reading this, I hope you are one of the people having a problem trying to learn new things. There is a possibility, however, that you wish to only get trained in areas where you are comfortable. I hope that is not the case. 

Learn and grow.

Saturday, December 6, 2014

Random Stuff from Agile Testing Days 2014

Agile Testing Days, in Potsdam, Germany, wrapped up a bit over a month ago. I collected a variety of images, pictures and other stuff. So, I'm going to try and post some of these here - in sequence - and tell a story differently than I normally do.

Monday - Workshop...




Tuesday - Keynotes





Costume Party - Tuesday Night...


Wednesday




Ummm, this was my session. People were still coming in, some are sitting in the
aisle and off to the left of where I was standing. 




The Car













Thursdsay












It was a pile of work, many very good sessions, excellent conversation, extremely good learning and intelligent, thinking people.




Sunday, November 23, 2014

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.

Wednesday, November 19, 2014

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.

Thursday, November 13, 2014

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.





Wednesday, November 12, 2014

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.