And We're Off!
We've divided into two groups - which given the numbers involved is a very good idea!
First topic for the group I'm sitting in is is "Teaching Soft Skills to Nerds." Challenging - Lisa suggests avoiding the "touchy feelly" stuff - possibly with relation to "interpersonal" instead of other terms?
Great question - "Why do we hire nerds without soft skills in the first place?" Consensus - we're looking for technical skills and sacrifice something. Since we tend to sacrifice one thing for another, this is the result. (OK, I missed a bunch of the conversation - not firing on all cylinders yet? need more coffee!)
Next topic: Why have test managers in an Agile environment? If testers are "all in" and part of the team, why DO we need test managers?
There are skills they may have, not addressable in a "whole team" environment - when the "team" consists of 7 people, this looks and acts completely differently than when the "team" is70 people. Some organizations use the term "manager" to mean "orchestrator" - where they are helping to coach people and build their skills in an environment where these personal development considerations are maybe not fully represented. Same issues apply to test and development. A good manager can make sure that skills are resident in the larger organization, even if they are not on EVERY team, if someone has a mix of certain skills, they may be able to engage on /their/ team - and sometimes be a support person for other teams when they need their help.
Next topic: A Continuation of this? (Actually the group "moved on" but the topic is similar to the previous and I could not actually hear what it was...) Note - it is REALLY WARM in here! Whoa!
Managers can help bridge cross-departmental challenges - e.g., environments and sandboxes and make sure people have what they need. (Huge point!) Once comment - an interesting one - at some organizations, because teams have different needs, people can be migrated from one location to another. As they are needed in one project, people can be moved as effort/workload allows and is needed. THis is a really interesting idea.
One aspect that was raised - small companies have such a different dynamic than large companies, that things like office space, cubicle size, workspace location (windows, etc.,) the question is how to balance the politics.
OK - frankly - there is too much happening to record reasonably well. They folks have interesting ideas - by the time I get 1 thing types, they've thrown another one out and I miss it. this isn't doing justice - BUT - I think it gives an idea, no?
Like this - the point is not being important or the title on business card or whatever because you are a manager - the point is how can you serve the team BECAUSE you are a manager? One important aspect is to nurture more novice testers - both technical skills and softer, communication/people skills. A manager needs to nurture their staff to make things happen well. It is up to the manager to help people grow by getting juniors aware of ideas and skills to learn/look into, and it is up to the jr testers to actually do the work to learn.
** OK - I blew it by not charging my laptop overnight and my half-charged batter from yesterday's workshop is now flat-lining. MUST FIND POWER!
**
First Keynote of the conference - Andrea Tomasini - Agile Testing IS Testing. Right. Interesting. I tend to agree with the title - That may not be a welcome attitude - BUT - There are certain things that many experienced testers would agree with, among them is that blind adherence to locked process models will not result in good testing. You'll get a fair amount of /checking/ (see Bolton's checking vs testing work) but fine little testing.
He makes an interesting point right out the gate - What matters more is the QUESTION - sometimes the answer matters, but the question is what generates thought. Excellent point!!! (Waves to @jbrains / J.B.Rainsberger).
Interesting demonstration - How many cars pass a line projected across a video of traffic on a highway. Figuring things out is the easy part, unless it s hard. For example - How many cars cross a certain point in 10 seconds. Go.... Ummm, both directions. Cars not vans or trucks.
Sound familiar?
Clients want problems solved - not a proxy for solving the problem. We need to consider if the assumption made is validated by an increment of the activity or not. How can we learn /together/ what is needed if we don't communicate around that. Building trust is required to that communication happening.
Testing is not about validating that people did their job. It is about examining what was done and considering that against the customers desires. looking into the product is looking into assumptions around the application. (OK - I'm editing this heavily as I'm writing. The testers are not part of the team? Sounds far more lock-step / SDLC/waterfall than Agile - so I'm ignoring those references.
We are looking for fast feedback, but sometimes the results can take longer to receive, etc., The description given is around "luck" - as in try something once and it seems to work - and you stop. Yet without proper investigation, the result is misleading.
We must build a culture of trust which requires a reduction in social risk for the product team. People not trained in how "whole team" process models function will have great reluctance in diving in whole hog when it is the opposite of what their experiences have been.
The challenge is to examine costs and business risks - the relationship between them. If we can validate ideas in an incremental way, short feedback loops - blah - blah - OK - So far there is not much in the way of "new ideas" here.
The promised "controversy" has not yet appeared. Wait - hold on - Best Practices were cited - in that sometimes they don't work.
Creating a vision with Stakeholders - ok - promise there - Discussing collaboration with customers - often starts with /testing/ - mostly of ideas. For example - if we have an idea - it may be a great idea - but if no one wants to buy the product that results from that idea - it is just an idea. If we act on that and sink loads of money, time and effort into something - we could easily be wasting time and building a bunch of stuff that will gather dust.
OK - I can live with that.
The idea of "user stories" gives context and content. They can be a declaration of intent and interest. This is something a customer wants. This needs to be considered and defined - this takes work to define what it is that people want / need.
Sorry. I'm not representing this well. Much stuff being asserted. Commitments can not be compelled to achieve success.
Classic Scrum stuff being described. OK, but not quite what I expected in this talk.(OK - that was an editorial comment - still...)
Moved on to Lean - and how Lean got very distorted in the version often presented in the US. Little to disagree with here - in a manufacturing model. When people don't understand the reasons for things, the result will be lower quality. However - that is fairly normal. Over burdening is bad. Normalized flow is good. Unnecessary variation is bad. Wasteful activity is bad.
Stuff that looks like work, but does not contribute to the overall effort may be a good idea. However, from project to project - sprint to sprint - the context changes. The change in context may be give results that one does not expect in the process model (whatever that may be.)
I recognize that some of these ideas are potentially new to some people here. Having said that, it seems a very compressed set of ideas being glanced over instead of a limited number of ideas dealt with in depth. Many conference speakers attempt to put out EVERYTHING THEY KNOW in one presentation. I've done it - and learned from the feedback.
There may be ideas of value - but they are lost in the noise.
==
Track Session - Sami Söderblom - Flying Under the Radar - How Conventional Testing Was Secretly Turned into Sapient Testing." Right - fresh coffee - and in a track session with a promising abstract. G R Stepehenson described how corporate (or anyy) culture develops over time. Essentially, something happens that is BAD. People see what happens - and association doing whatever happened just before the BAD thing and link the two. To avoid BAD things, don't do that one thing.
Simple.
Unless they have no relationship to each other OR - there is no true association between them. Cites Thinking Fast and Slow - Real effort requires thinking.
Classic example (well, to me) of a requirement that is "testable" or not. The question is "what does this mean? In what context is this a requirement? Does this requirement make sense for that context?"
Invokes Mindmaps as tools to evaluate software - and thinking in general. And to track progress in testing - testing sessions, session charters and session reports. OK - I like that. (Question - how many people in here are familiar with session based testing?)
I'm really liking Sami's presentation style after the the keynote - relaxed - laid back - staying on task and describing what he did - nice - comfortable style. Some folks may be missing context though (like the guy next to me.)
Citing Hendrickson's Explore It! "Explore
OK - interesting slides on info-graphics. He flashes up a weibull distribution diagram - a common display/model for project management. He then flashed up a coloured bar chart - asked if it meant anything... people said "SURE!" except he made graphs based on the characters of the Simpsons. Really? Do they mean anything?
Without understanding what the intent is, without understanding what is meant - simply taking information at face value is a problem, and dangerous.
And then Prezi blows up the machine running the presentation when he tries to open a linked video. Oops. Bummer.
He recovers with an important point: To be successful, remove the obstacles to success, Simple, no? What if you do not see those obstacles as obstacles? Are they "important and needed tools" that are standard to your context or environment? So what? What if they do not add value RIGHT THEN - get rid of them. They may have value another time, but if they do not this time - drop it.
If they are obstacles to your THINKING - they are not needed and are harmful!!!!!!!!!!!
===
Talk 2 - Tony Bruce on Be a Real Team Member -
Starts out with some interesting questions - like... What makes a real team member? Asks for people's ideas on that - and gets reasonable answers - open, shares information, contributes openly, etc.,
According to Belbin's study - team work is a model where people assume a role in the team that supports the team (in some way.) The roles may be action, people or thought oriented roles. These are reasonable - BUT - there may be things missing. (He promises to revisit this in a bit.)
AND the SECOND Prezi take down of the day! Well done, Tony!
Are PMs "shapers" or what? If a Shaper is one who drives forward the ideas that will enable success - who (or what) is the kind of person that is? Steve Jobs, perhaps?
While walking through various types of roles (rather - personalities?) Tony makes an important observation in an off-hand manner. "People can be good in these roles/functions sometimes - in different contexts these can help or hinder." You need to know which one is which - and when.
BING! Off hand comment on models - IMPORTANT FOR EVERYONE! "Take what you can use and leave the rest." Some things will be of value sometimes - other times they will not. Learn to recognize what is going on.
Communication/respect techniques discussed. The question of how people interact - including the balance for individual worth is crucial. discussed the problems people encounter - or inflict - based on biases, behaviors, etc.,
Interesting ideas - a bit fast to record fairly.
OK - This room is stinking hot. Sweat is streaming down - wow.
===
Lunch time -
===
OK - Food eaten! Costume (for the party this evening) Fitted! Slide deck finished/updated!
NOW! Mary Gorman presenting on Interdependency for Agile Testing.
I met Mary two days ago and had a lovely conversation with her over dinner - remarkably bright. She starts with a horror story from a previous project where a vendor (the one that was needed for people to get their work done) went dark - as far as developers, etc., were concerned. They simply stopped communicating with them - bad news...
OK - So - with some definitions and differentiation around dependence and interdependence.
When you work together - supporting each other, is that dependent or interdependent? Is your work related? So, Mary is describing comprehensive interdependence - where activities are dependent on each other - and on each of the individuals doing the actions/activities (yeah, there is a difference...)
Discusses Thomson's work describing interdependence as "the degree members interact with, and rely on each other, to accomplish their work" - this is fairly important. However - most people fail to appreciate this OR resist the opportunity - (pete note: maybe a control thing???)
Interdependence is linked inexorably to trust. The two of them must be tied together for any measure of (commonly identified) success.
Types of trust ...
Contractual - Clear expectations/meet commitments.
DO you meet the commitments and expectations of the people you are interdependent with?
What about the other way around?
Really?
Communication - Trust of disclosure... WHo knows what & when? Is feedback present? Are you and the "other" open to it? Is it direct and constructive?
Competence - Trust of Capability - people don't trust each other person/team's competence / ability. What about Respect?
Right -
So communication is dependent on Trust - to make that WORK though we must "shed light without generating heat." (Cool graphic of structured conversation)
We explore ideas - which leads to value & evaluation - which in turn yields to confirmation. The trick is these must be done openly - bi-directionally - so each thing is understood. (pete comment)
In testing, we need to discover & deliver cyclically. each round gives us another path to consider. We have internal interdependencies between the "user" or tester) and actions which impact users which... ok - you get it.
--
Running out to set up my workshop....
---
Wednesday Morning -
Right - following up on this. My session was a 2 hour workshop, a roundtable on problem solving. As with similar exercises, we went through a list of problems people are dealing with/encountering at work, described them, then presented ideas to consider to address the one that was voted (dot vote by the participants). The "solutions" portion was the most complex part of the the discussion.
There was a swirling of ideas and suggestions that shifted over an hour of discussion.
By the time the "grid" was introduced, there seemed to be some solid ideas on what could be done to address the problem described. (Look for more on this in a later blog post - I'll add a link when I get it finished.)
It took a fair amount of time to tear down the room, and by the time I had gathered up my materials, I had missed a fair amount of the closing keynote for the day.
===
Ajay Balamrugadas' notes form the same day: http://t.co/UhgZujVwcr
See Chris George's comments on the same day here: http://t.co/jJGDMZTprr
ReplyDelete