I did manage to snag a bag from the conference volunteers, with a t-shirt, conference goodies and the various sundries one might expect (although a postcard from Agile Testing Days is a fun idea!)
HAH! Full house! I have NEVER seen a Lean Coffee THIS WELL ATTENDED on the first day of Agile Testing Days. I am astounded - and very pleased for Janet Gregory & Lisa Crispin, who pioneered the idea here several years ago, and it has simply grown since.
What is on after Lean Coffee? The opening keynote to the conference followed by my talk in the same room!
Jose Diaz is presenting announcements and introducing people who are working very hard. The committee and volunteers are still in the lobby working to get everyone in the conference - IT PAYS TO COME EARLY! Your volunteers would appreciate it! You would too. (I've been on both sides of the table - it is easier if everyone helps out.
The Afghan Girls Robotics team are here. There is a drive to raise funds for medical help for Linnea Nordström the daughter of Kristoffer Nordström, a frequent speaker and friend of ATD. (https://www.savinglinnea.com/)
OK - WOW - Next year is the 10th edition of this conference AND Jose just announced there is a special discount available - 30% off the registration fee for Agile TD 2018 - if you register by 31 December!
Now - the Keynote!
Jez Humble (@jezhumble) is talking on how people make excuses (and call them reasons) why continuous delivery wont "work" for them in "Continuous Delivery Sounds Great But It Won't Work Here."
Jez "wrote the book" on Continuous Delivery in 2010 and was told the idea was crazy. SOmehow, many (not all) companies have begun doing just that. The goal is to make releases boring (his words) so they can be pushed out any time, and not stuck working over the weekend (ahem).
The goal is to push to production in a simple manner, simply! with no interruption of service and even be able to upgrade hardware infrastructure - remotely. - If it is not possible for you - it is not a problem with CD or Continuous Integration - it is a problem with your infrastructure - or worse, your configuration.
"We all know the 'works on my machine certification' is useless."
He's walking thru the basics of how most shops do development, check in, integration, etc., The KEY is knowing if there is an issue. If you can't fix what you just merged in - revert. If need be, blow it away, stop what you are doing, rest and do it again. Really.
Citing Brian Marick & testing matrix.
Automated testing - using a machine to help you do what you need to do and don't want to waste a human being's intelligence.
The point of CD is NOT to replace testing or testers. It IS about using people wisely - using their talents to advance what the work is supposed to be! THIS IS REALLY, REALLY IMPORTANT.
The case he is making is that you should be able to reproduce you production environment configuration(s) FROM VERSION CONTROL. Data is different, yes - but the configuration should be able to be pulled. Need a test environment? Pull it, run an instuall, run a simple check to verigy the build was good - and BOOM - Bob's your uncle.
"Reasons" why people don't adopt CD -
1. We're heavily regulated.
Hogwash (not his word, this is a family-friendly blog)Amazon is a fine example (look for a nice photo when I geta chance) Amazon is HEAVILY regulated (although most people don't realize or think about it - and they are releasing every 11 minutes...
He's moved on to his experience with GSA (in the US) setting up Cloud.gov. to assist US government organizations to release software FASTER. How? 269 of 325 mandated security checks are done through cloud.gov. Make them common and stuff simply will WORK.
WHY? The US Federal Government is the most heavily regulated environments there is - and until January, they had successfully deployed tools to speed secured delivery on a regular basis.
Most change management is about covering your ass in case things go wrong. For MOST organizations, Change Management is nothing more than CM Theater - it looks good but is worthless.
2. We're not building websites.
Ummm, you know that that is hogwash too, right?
Most of the time, people have a problem - not what they think it is, but they are spending more time doing things related fixing problems than to catch them before they get deployed and end up spending a fraction of the time on new features. For example - HP Laserjet products @ 2008.
Ummm - firmware.
The issue was - simply - "we don't have time to get this automation stuff written, we need to make new features so people want our stuff." Sound familiar? Except the features were simply dependent on too much stuff.
Their solution (not recommended for most orgs) was to scrap everything and start over.
OK - He is going really fricking fast. REALLY Fast - the pictures that are getting loaded later.
The issue - ISSUE - is HP - ended in 2011 with 23% of their "dev" budget being dedicated to automated test development. It was astounding - (there is a slide going in here shortly)
Architecture is key to making continuous delivery work - no matter the structure or environment (runs a short video of a mainframe-based - green screen system using automated tests against it - AND CD concepts.
(he skipped reason 3)
4. Our people are too stupid.
"Where do you get your really brilliant people who do this work?"
"I get them from you."
Teams create outcomes - Bad systems & processes will overwhelm good people and good teams. The POINT is to get people to a point where people can excel.
Make the environment one where people feel free to excel and discover innovation. When you give people the opportunity to do great thing, they will.
"When you say "our people are too stupid" you are absolutely right. Except, the stupid people are not the ones you mean..."
And he is plugging "This American Life" - thisamericanlife.org/radio-archives - awesome radio show on NPR and a fantastic podcast. - The John Shook episode in particular. It is a great episode (I listened to it when it went out originally.)
Make things better - ALL THE TIME. Management needs to focus on helping people MAKE things better. This is the crux of the issue. Really!
Wrap up -
Agree & communicate on MEASUREABLE business goals (not handwavy rubbish)
Give teams support and resources needed to experiment;
Talk to other teams (particularly the one that piss you off - go buy them lunch and LISTEN);
and quote Grace Hopper -
"If it is a good idea, go ahead and do it. It is much easier to apologize than to get permission."
and into questions...
{I'm a little disappointed that Susan Bligh is delivering her talk AT THE SAME TIME as I am giving mine. She is talking on QA/Testers and their relationship with BAs. Sounds really good to me. I hope to catch up with her and chat on this.}
Bailing for now - I am about to present. Be back later!
**
RIGHT - talk went - we'll see how the feed back comes, it seemed really short and really fast (I might critique myself later)
Grabbed a quick drink, chatted with some people and slid (late) into another track talk.
**
Sitting in Elisabeth Hocke's session on "I am Groot."
Came in late so I missed the introduction. Talking about fear of failure and concerns around that. Slit into finding inspiration - boss gave her a copy of "Agile Testing" but Janet & Lisa - then the company began getting into social media, including Twitter - so she joined Twitter and found .... Lisa and Janet - which set up conversations there and her learning grew. (she is giving ideas around key ideas - I'll be listing them briefly as she goes)
She has now slid into Job Titles and how ephemeral they are. In short, don't let the words define who or what you are. Be what you are and find the right words to describe it.
Behavior drives change. You can change your behavior, You cannot change OTHER people's behavior BUT you can begin the process with yourself, and see what the influence is.
Mix up your learning - look to other tools around how people learn and how you learn. Drive yourself to force understanding. Don't get comfortable (ahem) with what you are and do - keep forcing change on yourself.
Constantly reinvent yourself. Really. Change things that you do - find things that are new to you - blog posts, interesting ideas in twitter streams or other social media - look for things that look interesting but you know only a little (or nothing) about. Reach out around that and try it.
Share responsibility. Work with your team/co-workers on what testing is and learn from each other. The "whole team" thing does not mean not being a tester anymore - it is instead a way of continuous learning.
GAH - had to bail on Lisi's talk (sorry! We'll catch up!)
**
Couple of maintenance things then back with Cassandra on test automation.
Her topic is "5 ways test automation is like sex..."
Right - THAT might get people's attention. The real question is, do I have a future in software testing if I don't do/know automation...
This grew out of a question in Ministry of Testing discussion forum... and here we go!
1. All the cool kids are doing it.
Well, yeah, this ties in with an assertion she made on twitter, that test automation is a bit like high school kids - they talk a lot more about it than they are actually doing it. Most job adverts in the UK (where she works generally) focus on automation testing experience. So, she went looking - 1st 5 posts she found, 4 mentioned automation straight up, the 5th, down in the sub context, was "we don't have automation in place, but we have a need. If you want to do this with us, come apply and help us.
2. There's pressure to "do it."
General press shows that "automation" or "robots" are replacing people - except they aren't really doing it. Things like "AU could threaten up to 47 percent of jobs in two decades - reports."
Yeah, cuz adding the word "report" to the end of a headline makes it real, right?
There is "fake news" and "fake information" and "alternative facts" - and always has been since the beginning of time, including the fake "studies" Assertions need to be followed up.
The thing about test automation, are precisely the same as was said about self-checkout in grocery stores/shops. Right.
3. There's a lot of MISinformation.
Loads of myths and urban legends but real, measurable information is harder to come by. People may cite other people - those considered "reliable" and still, somehow, they have not checked sources either.
References Alan Page - references Richard Bradshaw. Should testers write automation or should "tool smiths" write test automation? Page & Bradshaw think the later. (I'll find the references in twitter - I remember the conversations from a few months ago...)
4. Good people are wanted with or without automation.
The "community" may be the bubble - and may be an echo chamber.
Yet, the community of testers give a solid presentation
5. It (automation) is not the enemy (or is bad)
We need to find ways to contribute to it and find ways to make use of it to make better products. Tinkering with tools and dealing with people are flip sides of the same coin.
Lessons from Cassandra -
Don't believe the hype (it's mostly rubbish anyway);
Understand you reasons for wanting to "do it" - or not;
Benefit from and contribute to it;
Don't let it be your excuse;
Understand your value and have confidence.
** Be a successful testing with or without automation. **
RIGHT. I completely missed the 2nd keynote of the day because I was talking with the very intelligent and engaging Susan Bligh.
I am now sitting in the video replay of There and Back Again: A Hobbits/Developers/Testers Journey.
In the beginning - the start of the Hobbit clarifies what a hole is, by challenging the assumption that a hole is something known by rejecting that "known".
This sets up the core message - People know what they know, but it is fallible.
Testers tend to become quite comfortable. Many like being in that nice safe spot. Testers tend to react to the class bias instituting their OWN bias.
OK - I'll fill in the rest later...
Had some good questions/discussion and headed out of the room for a longer discussion. That took a while! THEN I got pulled into several enjoyable conversations with people who were asking questions around what my presentation had to say.
Short interview and sneak into Ray Arell talking about Safe-to-Fail.... Failure. Yeah. awesome!
He's asking questions around "Who in the end is afraid to fail? What does failure look like? Wgeb bugs (failues) are found in production, who is it they managed to get there? Persistence? For example - let's talk about Fail Safe (speaking of oxymorons)
We are defined by how we find value - by helping other people over come challenges and fix problems and drive conversation, which drives ideas....
**
Getting a bit tired. Sat for a moment & chatted with Mike Sutton. He's been having a busy time of it at the Open Session/chat area. Frankly,
GAH Battery is going!
OK - temporary replacement - Let's GO!
**
Closing keynote of the day - Poornima Vijayashanker is presenting on ... ick
onboarding...
How to Onboard and Train New Hires into Happy and Productive Employees.
OK, starting with the story of how she started - the new grad, lands the first job and finds herself in... not the world's best gig. The CHALLENGE for new employees is often the company, not the employee. Most organizations are pretty top down (that is why there are vbosses, right?
THe problem is, when the immediate boss is absent (physically or emotionally) or a bit of an expert in everything. The one who is telling people his or her version of how awesome they are.
So, what does this mean? Well, consider this, most people want to be good employees and contribute, etc.,
Consider this - What does the 1st day/week/month look like?
How soon does the new person feel they are contributing?
Watching cat videos does not count. Really.
Consider, how long does it take to get the new person to meet their new team - not the department, just the folks they are going to be working directly with.
Also, how long will it take, how much work will they have to get their machine and environment setup and WORKable - if you make it a screening process, you (the boss) screwed up.
Don't be that boss - help coach people, get them in contact with people to guide them. Really.
Get them involved - and WARN them if there are ... issues ... that might trip them up. Biff works well with most folks, but clashes with Dorf. Also, consider inter-departmental challenges - these guys like showing THOSE guys how in-control they are. Sometimes a word of warning can help people not walk into a minefield early on in their gig.
By getting people involved, they can make things work FOR THE COMPANY.
Given a new hire will feel connected early on, ask them what they think of the org, Ask them what problems they see - maybe at 60 or 90 days from start Maybe 100.
Ask them what they would suggest about direct problems they see. Why? It gets them involved and INVESTED.
**
Right. Tonight is the MIATPP awards and banquet. With a theme of "Super heroes" - yeah, people are encouraged to come dressed as a super hero.
This should be ...
interesting.
Loads of Cat Woman costumes, wonder woman costumes, super man, super girl, captain america and some costumes I have no idea what they are.
Big news is, my friend Huib Schoots was named as the Most Influential Agile Testing Professional Person (MIATPP) for this year. I am very happy for him. He's a good man.
**
very long to read. i just skipped it.
ReplyDeleteThank you for your comment.
Delete