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 |
AND NOW! in Dan Ashby's session on Lateral and Critical Thinking Skills for Testers.
 |
| Dan Ashby |
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
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.
No comments:
Post a Comment