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 –
==
Recent Comments