Tuesday, August 13, 2019

Agile Change is Hard

Loads of people are engaged in some form of "Transformation." I sometimes think people latch on to that word because, well, it sounds more impressive and has less baggage than the word they really mean - Change.

For example - Agile "Transformation."

I've worked with teams that have done that T thing. I've worked with teams where it has gone really, really well. I've tried to work with teams where resistance was the underlying theme from managers all down to the most recent hire.

In my experience (this could just be me, after all there are loads of "coaches" and "experts" out there who can and will tell you differently) "Transformation" sounds better and because of that they can charge more money.

"Agile" has become a catch-all word to describe work done in small increments toward a specific purpose. Sometimes, I find that the "small increments" part is optional for many organizations.

They'll take the ritual labels, slap them on meetings or stuff they are already doing and POOF! They are now Agile! And they'll do pizza and t-shirts and motivational posters to emphasize the point.

Except, this isn't a change, or a "transformation" in any way. It is codswollop.

They'll hold meetings and send out lengthy diatribes in the form of emails from the "facilitators"  or "change agents" on things like "safe spaces" and "fail fast" and other catchy phrases. And then turn around and insist delivery metrics be met, at the least. More likely they'll raise the minimum standards fairly dramatically because "Agile" (and Scrum in particular) will "make" teams deliver product faster. So they should be checking stuff in faster and getting work and projects done faster. Somewhere in there, they'll likely be some level of criticism, delivered harshly (because they are being "open and honest") on how people did "everything wrong" and how their manager would have done it. And then they'll follow the same production implementation process they have since COBOL was the hot new language.

This isn't change either. It is more codswollop.


The hard part about any kind of change, Agile or otherwise, is not the external mechanics. It is not "doing daily standups" and it is not "increment planning" or "retrospectives" or any of the other labelled activities and rituals that many not-quite-agile organizations embrace, by relabeling activities they already do.

The hard part is sitting down and doing the really challenging work of looking at the organization, as a whole, and asking hard questions around why do you want to change?

Of course, the hard part about THAT, is each person needs to take a long, hard, honest look at themselves, their beliefs, work habits, intentions, goals, dreamsn and desires. Then looking at how that fits in with their team and the broader organization.

For those who have never stared into the abyss of themselves, this can be a terrifying prospect.

That may be why so many organizations settle for codswollop. It is easier to swallow than the actual medicine to make change happen.


Wednesday, July 10, 2019

Agile Testing Days USA, Thoughts on the 2019 event

Many conferences around software have a feeling, a vibe if you will. This can shift from year to year, but rarely in a huge dramatic way. Partly, this is the result of the energy from the organizers, partly the work of the people reviewing speaking proposals, and partly the feeling of people returning from prior years.

This was my first ATD USA event, as I had a conflict with last year's. I came in with a mix of eager anticipation and recognition that things would be different from what I had experienced at the several Agile Testing Days in Potsdam, Germany before. I was hoping to have some of the same energy and spirit of "fun" as the event in Germany, recognizing that it would, by the very nature of partnering organizations and attendees and speakers who had not been to an ATD event, different.

I think Ray Arell (@elmoray) has been credited as describing Agile Testing Days as a Festival disguised as a conference. He's not far off. Loads of social events, including a themed costume party, given the venue and city (Chicago) a "Roaring 20's" party seemed appropriate.

What is most important for me, personally, at a conference, is the conversation and interactions with other people. At one point in my conference life, "hallway conversations" were short, while grabbing a coffee or snack and heading off to the next session - because I was going to get my (well, the company's) money worth from being there. I'd like to think I know better now.

The result was I went to the keynote sessions (except one, given after I had to leave) and one or two track sessions. I spent a great deal of time the first day in the "Mentoring Corner" - This was intended to be for new speakers or people who WOULD be speakers. I actually was there charging devices and using the table to spread stuff out - and made a point of being as helpful as I could.

I am glad I did.

I spent a great deal of time talking with people who had similar issues they wanted to talk with and bounce ideas around with someone (my words, not theirs.) I got to see presentations grow from "this is kind of what I want to say and the arc I think I want to cover" to "This is what I am going with - thanks for your help!"

To be clear, I'm not really an expert in a lot of things, I am very good at asking questions when I don't understand something. I sometimes also make leaps from what people say, connecting ideas they are having a hard time identifying - for example, how ideas tie in with broader topics in the wide world and can be shaped by the energy in the room, or in the broader place.

Such things happened here in abundance.

The Start

Heading down to ATD USA, I was disappointed that two people would be presenting at times when I could not possibly catch their presentations - One (Jenny Bramble, @JennyDoesThings) because I was presenting at the same time and other (Bonnie Aumann, @bonniea) was scheduled to speak after I had to leave to catch my train back home. So, rather than well on things I could not change, I "hoped for the best" and spent a pleasant time milling about the day I arrived chatting with old friends and getting registered and hanging out, in between connecting to meetings with the Day-Job.

Heading to the Speakers Dinner that evening, I see Jenny has been delayed in arriving because of odd flight issues. So, sitting at a table, having found a fairly safe spot in the corner with folks I mostly had not yet met (protip - don't sit with yer pals at an event like this, find folks you don't know yet) when - HOLY COW!!!!!! Here's Bonnie looking for a spot!

AND THERE IS AN EMPTY CHAIR NEXT TO ME!!!!!

One thing led to another and POOF! I had, what was for me an enlightening and very enjoyable conversation with someone who has put stuff out in public that I admire greatly and have learned from. We talked on a variety of topics, all of which dimmed when Bonnie expressed concern over the presentation to give (the one after I left...)

"Welp, I'll be sitting in the Mentoring Corner for speakers (and others) the next day, after I give my talk. Come on by and let's see if we can sort through it and help get it sorted." (I think that was something along the lines of what I said.. or at least a very polite folksy version of it...)

Later in the evening as I'm about to pack it in, I realize Bonnie knows Ray Arell and instead of packing it in, I find myself having "well, just one more" with them. (OK, I'm in full blown gob-smacked hero worship mode at this point...)

Having "just one more" with the two of them, and a changing cast of characters at the "Networking Night" - IN WALKS JENNY BRAMBLE!!!!!!! WHEEEEEEEEEEEEEE!

What ensues is a discussion around nearly any topic imaginable. Really. I eventually toddle off to bed a happy conference attendee, with the feeble excuse of needing to go over my talk one more time.

Day 1

Lean coffee was an interesting exchange of ideas, questions and "Oh, yeah, I had not thought about that" moments. The opening keynote was given, then I gave my talk. Then I scurried over to the Mentoring Corner.

At some point I ate lunch, went to a couple more keynotes, then went to the "Costume Party."

What struck me was not the details around these things but the ideas floating around in presentations, conversations and questions.

Ideas. ideals and bringing together people with different skill-sets and backgrounds and experience and life experience and outlook and pretty much anything you can imagine. The common word was "diversity" - and as much as that might be a problem for some folks, the looks I got when saying something like "part of the issue is there are a bunch of folks who look a lot like me, who figure they are the only ones with good ideas."

I learned a long time ago in pipe bands that the presence or absence of "dangly-doon-bits" (as one Glaswegian put it) had nothing to do with a persons ability to play pipes or drums. Nor does skin color, ethnic identity - having hung out with folks from the City of Tokyo Pipe Band and the Royal Sultanate of Oman Pipes and Drums in Glasgow, and having had some really fun times with members of the Church Street Pipe Band in Toronto.

The simple fact is, there were some very fine players in those bands. Sure, less experienced and much to learn, but when I think back to some of the bands I used to play in? whoa. Get real.

My overall lesson from the week

The message I was hearing much of the week can be summed up thus:

Anyone and everyone can contribute to goo work. Anyone and everyone capable of thinking can contribute. Anyone who thinks differently than ME can definitely contribute. You probably don't want an entire team of people thinking like me (no matter how they look or pray or vote) because it would just be weird.

Of course, declaring a bunch of people a "team" doesn't actually make them a team. Declaring a bunch of people a "team" who have only ONE THING IN COMMON, their employer, is not likely going to lead to a successful, diverse team.

That takes trust. That takes building rapport among people who are effectively strangers and have nothing really in common with each other, except possibly species. Trust comes with time, after people have found a way to relate to one another. The folks at ATD generally approach this as "of COURSE!" and yet, for many, like many first time attendees, the "how" is really hard to get our heads around.

Until you have DONE it, it is either very Unicorn-In-The-Sky, or it is pixie dust or glitter or some hand-wavy thing where in a process diagram there should be a cloud with "POOF! A Miracle Happens Here!" (For the record, I find most "team building guides" to have the same fundamental problem, people forget about human nature...)

My favorite part of this year's conference. 

Remember way up toward the top when I mentioned Bonnie Aumann? Bonnie DID come by the mentoring corner and we talked about the message within the talk. We talked about some really key ideas. Bonnie presented a compelling graphic, which I saw get drawn in the Tuesday night conversation at the "Networking Night" with Ray Arell and Jenny Bramble.

I'm not a famous name in software. I know that. I am honored that you read my meandering thoughts in my blog from time to time. I'm thrilled when people find some value in a tweet I might send. What I am trying to do now, particularly at conferences and meetups I can attend, is to help people tell their story.

That is one thing I tell people who say "I want to speak. Where do I start?" I always ask them about their story.

Because when speaking, we take on to persona of the parent or grandparent telling a story to children. We take on the role of what is called a seanchaidhe or seanchaĆ­ in traditional Irish culture (in Scots Gaelic tradition it is seanchaidh). We take on the mission of extending memory and inspiring our listeners to be better. We take on the challenge of calling people to be bigger and better than they are now.

Bonnie talked with me about the challenge of persuading everyone and how it had become clear that was never going to happen. So, logically, start with people who were closer to you, but not in full alignment.

Over the course of a day, more or less, I saw Bonnie's collection of excellent ideas grow into a cohesive, powerful "call to action" and model for how people can build rapport, trust and a team.


My end note.

I have met loads of people with loads of things to say. I have met people with huge egos who have little to say. I have met very wise, intelligent people with much to say, if people are willing to listen.

The people I mentioned in this post, Ray, Jenny and particularly Bonnie, are all in the latter category. I learned much from them in the few days at ATD USA. I suggest anyone wishing to learn, find them and learn. They are masters in their own right.

As for me?


The Road goes ever on and on
Out from the door where it began.
Now far ahead the Road has gone,
Let others follow it who can!
Let them a journey new begin,
But I at last with weary feet
Will turn towards the lighted inn,
My evening rest and sleep to meet.
 
Bilbo Baggins


Tuesday, June 25, 2019

Agile Testing Days USA, Notes

I have 1 (One,Singular) conference speaking appearance for this year, and I am there now. I took the Amtrak Pere Marquette down from Grand Rapids, to Chicago Union Station this morning.

I arrived at the conference hotel, the Palmer House, now a Hilton property, it is one of the grand, old hotels of Chicago.The venue is absolutely lovely.One of the grand, ornate buildings that now seem too much effort for so many people. Alas for these times. (I'll be adding pictures later, maybe, I promise, sort of.)



Many years at conferences, I would spend massive amounts of time typing frantically and trying to live blog the conference as I experience it. I started doing that mostly as a service to myself - I wanted to take notes, in depth, and found I could do so as a blog post, and publish my thoughts/perceptions, in an attempt to share them.

A few speakers over the years have been a tad annoyed at my comments. A smaller number have been downright upset. My reaction? If the harsh words in the blog seemed unfair, oh well.

This time, this conference, I'm going to try a difference approach. I'll look for trends in conversations and sessions and see if I can make sense of them, and possibly find some lessons to be considered.

The first few days of the week, there were classes going. Today is tutorial day, the conference itself starts tomorrow. I'm speaking in the first speaker slot after the opening keynote, then scurrying over to the "Mentoring Corner" to talk with new speakers, or potential speakers and help them with whatever I can help them with.

That will consume a large portion of Wednesday, day 1 of the conference. Thursday, I need to leave early to deal with "day job" stuff so I will miss the closing keynote, These things contributed to my "don't live blog" decision. It also helped me to decide to focus on sessions with ideas I could bring back to colleagues and ideas that might be applied more broadly than considered.

And so, we begin.

==

Today was a low-key day, this far. Nice relaxing train ride in, connected to some meetings with the then employer (MI-GSO|Pcubed) and the client. Did a little paperwork, hung out and just rather rested. Fish & chips and a glass of local beer for lunch from one of the establishments in the hotel. Pretty good fish - haddock, nicely fried. Beer was a local whitsun ale. Not that you need to know that. Really boss, I got the Non-Alcohol version! (I wonder if she'll believe me...)

Ran through my presentation a couple times. Each time I do it, I feel more comfortable - and I like how it has shaped up.

Took a wee nap, followed by a shower (amazing how those wake you up when tired.)

Then hung out and met friends and colleagues as they rolled in, either arriving or from the tutorial they were presenting or in. Now, I'm sitting waiting for the "Pre-Conference Keynote" to wrap the end of the tutorial day, and get people ready for the social events this evening.

Jose Diaz is on the stage, looking pretty much ready to dive in.

This session is "Real Life is Not an Edge Case," presented by Rachel Kibler (@racheljoi) who is one of the SpeakEasy speakers! SpeakEasy helps new or inexperienced speakers find their voice.

Cool.

Here we go.

==
The message from Rachel last night was a good one for many people to consider, and remember. In short, when we look at the simple, straightforward path. Unfortunately we miss loads of opportunities to examine paths that will happen in real life, for the people using the software.

Our biases, and the biases of designers and people building the application and systems will impact how the software works, and may not be relevant to a large portion of people using it. THese things can be variations on bias-driven cores. They can also be under levels of stress we have not anticipated.

Perhaps, that is the single point - Stress testing of the application is one thing. Testing the application as a person who is UNDER stress is another. We need to be able to recognize the limitations we are putting on people having really bad days (not just a collection of things that get us down) - ambulances, sirens, police officers, hospitals, all count as "really bad days." How easy is our software to use? What messages are we sending to someone, based on the biased algorithm generating the UI/interactions?
==
Speaker dinner w)as amazing. I got to sit with and visit with people I won't be able to hear speak - Bonnie Aumann (@bonniea) and later, JennyBramble (@jennydoesthings) and great conversation with Ray Arell (@elmoray).

Lean coffee this morning, and now an interesting keynote by Janet Gregory and Susan Bligh.

More later...
==
Interesting mix of experiences this morning. Energy between the keynote this morning and my talk was very similar. I spent the balance of the morning, and early afternoon, at the Mentoring Corner, aimed at helping people who would be speakers at tech conferences home their presentation, or, in one exciting case, "I decided I could speak at a conference after coming here..."

Lunch was wonderful. Fajitas and conversation with Susan Bligh and others. Which made me late for Ash Coleman's keynote. Oops.

Context is Everything - Except "context" shifts in ways that most folks, including "testers" don't really expect, anticipate, or consider - like, intent of the customer/user, or possible underlying complexities that are based on life experiences of the developers, designers, testers and customers.

We must "go beyond the context of the expected tester, and lean more into the context of oneself."
--
updated
--
OK, Folks caught main points of Ash's talk on twitter pretty well. (Here, I made a link thing for you: https://twitter.com/search?f=tweets&vertical=default&q=%20%40AshColeman30%20%23AgileTDUSA&src=typd )

What struck me as significant was how context, perspective, life story, experience all shift by person. What seems obvious to one is earth-shattering revelation to another, and that is OK. Being aware that this MIGHT be happening can help us communicate.

==

An interesting and busy afternoon. I spent a pile of time, like, most of the afternoon, talking with people and looking at what they were doing and what they want to do.

And mayhem is about to commence in the closing keynote for the day - "Bad-Gile: The Game Show"

==

Mayhem was loads of fun, and provided valuable lessons for those who paid attention. In short, admitting and "owning" errors, mistakes and failures is hard. Recognizing that Agile practices will rarely (never say never) be identical to itself - no two projects, efforts of sets of work will look the same. Do not try and MAKE them look the same.

The evening reception and party were a great deal of fun. People in various forms of 1920's costumes, from flappers to competing Babe Ruths. The ball player not the candy bar named for the ball player.

Loads of good conversations, "networking" and generally hanging with friends, some new, some we've known for time.

===

Thursday morning, for me was a quick breakfast followed by Lean Coffee. Lean Coffee was interesting - great conversations around important ideas - books, learning, continuing learning after a conference.

Now, this morning's keynote - Recognizing Cultural Bias in AI, presented by Camille Eddy (@nikkymill). Thoughs later!

==

That was an immensely intense presentation. Difficult to deliver, difficult for some in the room (I suspect) to hear, yet very needed. There are trends here in the messages from several speakers I need to think on. Expect a further blog post with some of these concepts.


==

Sitting in Ray Arell's session (@elmoray) on Scrum Must Die.

Thoughts on this later as well...
--
updated
--

It is later:
Ray's message is similar to some ideas I've been having of late. People see the learning frameworks as the ONLY way to do things, because that is something related to what their instructor said because even if they are paying close attention. Sadly, many training efforts ignore the principles of Agile and jump immediately to the ceremonies and ritual.

The result is similar to keeping training wheels on bicycles long after they are needed, because that is what "you are supposed to do," according to Ray. Sadly, I've seen many instances where that is the case.

The FIRST way people "experience Agile" becomes the only RIGHT way they know. IF they were not properly trained, or they half paid attention because they were too busy reading emails of doing "important real work" then, yeah. This is what you tend to get.

And this is a huge problem, contributing to commercialization and commoditization of some really powerful ideas. Because we can take anything that seems like a good idea and make snake oil out of it...

==

Next session, after some lovely conversations in the open space/mentoring space, Dan Billings (@thetestdoctor) is presenting on security roles in testing. Interesting opening (gotta love anything featuring James Doohan... well, William Shatner is there too, I guess...)

--
updated
--

Dan's talk was well received (given the number and range of people in the room, pretty much anything with Star Trek references would be well received!)

People caught a great deal of the highlights on twitter, so, here's a link - https://twitter.com/search?f=tweets&vertical=default&q=%40TheTestDoctor%20%23AgileTDUSA&src=typd

My general takeaway, we're not as secure or safe as we like to think we are, nor as we are often told we are. Be aware, build strong diverse teams, explore and follow thread, challenge the comfortable status quo (it likely isn't good enough.)

To mix metaphors (not unlike the question asked "Where's Chebacca?" at the end of the presentation) "Constant Vigilance" - Alister Moody.

==

Dan's was actually the last session I attended. Instead, I spent some more time sitting in conversation with people, gathering thoughts and preparing to head back home.

I gathered ideas into a collection of notes I will be writing up in another blog post - more on the ideas I encountered than anything else.

The venue for this conference was absolutely beautiful. Having organized conferences, however,I can see where it would be a challenge to coordinate smooth traffic flow and keeping the "feeling" conferences tend to generate.

In spite of this, the organizers and staff did an excellent job of engaging people, making the learning fun and helping people build connections to further their understanding.




Saturday, May 11, 2019

On Being There


I remember a few years ago, a fellow wandered into a standup after being rather MIA for two weeks. As in, he was physically in the building, just ignored all the normal “rituals” around Agile, and Scrum in particular. Now, this was interesting, because people would see him in the hallways, his calendar was always full, but the items were blocked so no one could see what they were, including the manager and team lead. He would not answer phone calls, return emails and mysteriously was never at his desk.

Then came the day he showed up in a standup toward the end of the sprint.

“Hey, I don’t have any tasks on the board so I was doing other stuff.”

“Like what?”

“Oh, stuff that Bill asked me to do. It has been keeping me busy. What are you guys all doing?”

This was brought back to me very, very vividly a few weeks ago.

Since the first of the year, I’ve been working across Michigan, some 180 miles, from where I live. So drive to the office crazy early Monday morning, staying a few miles from the office location during the week, then driving home Friday night. This presents a bunch of challenges, as one might imagine. The family/home/pets/friends/relationship stuff is hard when you are home almost 72 hours per week and sleeping a fair portion of that time (as I am reminded often, I’m “not 40 anymore.”)

Then add to this, trying to fit in with a bunch of pipe band drummers you are supposed to be working with, but that has turned into “giving guidance and offering suggestions” based on recordings, simply because practice happens evenings during the week, 185 miles from where I am. So, one of the very, very rare weekend practices, I walked in and found… I was not fitting in. At all. That is really bad when you are supposed to all play things together, the same way.

Why? How’d this happen?

Simple. Minor little things were agreed on when the four of them were there, and worked on, and internalized – and then when I showed up, it was “Oh, yeah. Um, we changed that a little so now it is THIS. OK?” One or two of those are not a big deal. A bunch can be added over 3 months of work.

This is in addition to the stuff I WAS told about. “Oh, we changed the ending to this tune, so, here’s what it looks like. OK?”

The point of regular, weekly rehearsals is to keep everyone aligned and moving the same direction. The goal is to make sure there are no major, and only a very few minor, differences in style, interpretation and technique. Most importantly, to make sure the shared vision and purpose are present and driving the approach to music and presentation.

This, by the way, is the purpose behind the “rituals” of Scrum – the standups, the refinement meetings, the retrospectives and the demos – moving toward a more perfect alignment in purpose and reason for the team and the product.

All it takes is one person missing then magically showing up to totally disrupt the results.

Tuesday, May 7, 2019

A ScrumMaster Has No Name

Let me start very directly for those who really don’t like reading my
normal format blog posts:
If you are hoping that becoming a ScrumMaster will win you praise and
broad recognition and honors and be recognized as THE PERSON who
saved these troubled projects or made the teams awesome, this is not
the role, or the job, for you.
If you are hoping that becoming a ScrumMaster will get you the needed
authority to compel people to obey your command and deliver awesome-
ness every 2 weeks, this is not the role, or the job, for you.
If you are hoping that becoming a ScrumMaster will result in teams
improving performances, increased quality and time to delivery will get
you the satisfaction of knowing you helped people make things happen,
deliver items of value to their organization and its customers and have
the team not even notice you in the corner getting things to happen,
then this might possibly be the role, or job, for you.
There. 
That’s the gist. 
Now to explain.
At one time, many large, usually European although some American,
cities had such things as “Gentleman Clubs.” Now, these were not the
ilk of certain business establishments today that advertise themselves
as such. Instead, they were rather formal places intended to provide
people of a certain, order shall we say?, with a place where they could
step in, find a welcome from the staff, have a beverage and maybe
some refreshment, smoke a pipe (perhaps) or play a hand of cards or
simply have conversation with polite, like-minded individuals.
These would be arranged and ordered much as society itself was –
there were those that were for the “better sorts” (meaning wealthy,
particularly coming from older, more established wealthy families)
and other aimed at other levels of society – men of business, or
whatever. They would discuss politics, indeed, rather famously there
were a pair of such clubs in London, aimed at the very upper levels
of Society, very similar expectations (qualifications) to become a
member. The great differentiator, was, what political party you
supported: Tory or Whig. Yes, yes, yes. I am well aware there were
radical followers of Wilkes who were reformist Whigs, of sort, but
still, they were the main two parties.
Anyway, you see my point, I think.
There have been “clubs” for some time.
Frankly, becoming a ScrumMaster does not get you into one of the
"better clubs." Walking into a room does not get you hushed awe,
deferential bows, looks or even glances. Members of the “better
classes” will not come over quickly to greet you or take your hand.
We are not the ones for whom such things are ordered.
We might very well be the ones making sure they are ordered and
the members of the Club coming in are greeted appropriately and
have their needs attended to. The members of the Club might
know our name, typically the surname or family name, for that
is how such things work.
“Ah, Walen. Very good to see you again. How are things this
evening?”
“Oh, thank you sir. It is good to see you back as well.
Mister/Doctor/Sir/Lord {name} is in the {some} room and asked
I let you know should you arrive this evening. Can I help you
with you coat, hat and walking stick? Can I have Barlett bring
you your usual?”
Well, maybe we aren’t in a Georgian era Gentleman’s Club
in London. (I’m fairly certain we are not based on the fact it
has been a while since I’ve heard conversation of that manner
that was not part of a stage production or a tongue-in-cheek
pantomime.)
But the analogy holds, I think.
Our purpose as ScrumMasters is to help facilitate the work
people do. Help them answer questions they are not sure
how to frame, let alone ask, and help them discover more
apt lessons than “Try vertical slicing of this story…” 


Because, much of the time, without an understanding of the
work at hand, such things are rejected as buzz-word non-
sense, and rightly so.
Our purpose as ScrumMasters is to help facilitate the
communication that must happen on projects, large or small.
We can ask “would a meeting with {person} or their manager
help get these answers? Would you like me to set something
up since they are not responding to emails or phone calls?”
Our purpose as ScrumMasters is to help remove roadblocks or
impediments. The Scrum Guide (OK, I know LOADS of people
have never actually read it, maybe it might be a good idea if
you’re going to call yourself a ScrumMaster or Scrum Master
or some variant of that) makes that really, really clear. We don’t
need to be the one fixing the problem or removing the roadblock.
Sometimes we might be.
My standing “humorous/joke advice” for newly minted Project
Managers holds true for newly minted ScrumMasters/Scrum
Masters/Whatever: “Make sure the coffee and tea are fresh and
that people have their beverage of choice available. Bring it to
them if need be.” (Yeah, I’ve offended people with that line.)
Back when I was writing and fixing customer-facing production
code, sometimes in the middle of dealing with a serious problem,
the thing that really would have helped, and the thing I could
really use except my brain was too closely engaged in the problem
at hand to stop and go get, was a cup of fresh coffee. Someone
walking in and handing me a coffee (or tea or some carbonated
& caffeinated beverage) when I was neck deep in broken code
was a life-saver.
When team morale is an impediment. DO SOMETHING. Bring
them coffee, tea, bagels, donuts, muffins, cookies/biscuits, sweets,
nuts, fruit – SOMETHING. Let them know you are aware of what
is happening, that you recognize you cannot help with the technical
problems (unless you can) and you can contribute THIS to the effort.
When they are done and walking toward the door, don’t forget to
give them the correct coat, hat and walking stick. When everyone
has headed out, then make sure the room is tidy, then get your
muffler and hat from the hook in the staff/servant’s room, and
quietly head out the back door.
Because it is about the team. It is not about you.
A ScumMaster has no name.

Friday, November 30, 2018

The Man's the Gowd For A' That

The title here is the last line of the first verse of the Robert Burns' poem and song commonly referred to as "A Man's a Man." For the late 1790's, it reflected a huge portion of the enlightenment's understanding of human kind.


Is there for honest Poverty
That hings his head, an' a' that; 
The coward slave - we pass him by,
We dare be poor for a' that!
For a' that, an' a' that!
Our toils obscure an' a' that,
The rank is but the guinea's stamp,
The Man's the gowd for a' that.
What makes me think of this today?

Simple, a short phone call that was followed by a short conversation with my lady-wife.

I've been looking for a new software adventure for some time. Yes, I've had several opportunities come across the desk, many have not felt right to me. Some I applied for and things have been slow in progressing. A week or so ago, a placement specialist/recruiter/head-hunter called me. He had seen the resume I submitted for a different position, and wondered if I would be interested in one that had come into their office that morning.

He then described the job I was looking for.

We talked about the generalities and then dug down into greater specifics, as these conversations tend to go. He said he'd run the information past his manager and get back to me. An hour or so later he called again. We chatted some more.

I made a couple minor tweaks to the cover letter and resume to tailor it better for this position (not making things up - it bugs me when people do that - but emphasizing work I took for granted that others not doing stuff with Agile or Scrum or Testing would be looking for.

We agreed on a billable rate and off we went.

We had a couple emails back and forth since then, just checking in.

Last night, as we were watching the fish in the fish tank (really, that is what we were doing) waiting for the "dinner's greatest hits" to warm up in the oven, the phone rang - it was him again.

"Hello, is this Pete?"
"Yes it is."
"Hi Pete, this is {him} we talked last week about submitting you for a position at {company}. Do you remember?"
"Of course, {him} I remember. How are you doing today?"

A simple polite nothing - small talk in some ways, but a bridge that is so important.

The change in tone and energy was immediate. From being rather mechanical, almost awkward, everything became much more human.

"I am good today, thank you for asking."

The manner of the conversation changed with that simple question. Recognizing him as a person, recognizing he was trying to do good work to support his family and, incidentally, help a client company connect with a candidate with specific skills.

We finished the business, I wished him a good evening at the end and the conversation ended.

My lady-wife was watching with great interest.

"His entire energy changed when you asked how he was doing, didn't it."

Yup. It did. At the end, you could almost hear him smiling.

Sometimes, the purpose of such small things as asking how someone is, asked in a sincere manner, does more for that person than any other thing you could do right then. Such "polite nothings" are similar to the honorifics that once were part of everyday society.

"Good morning, Mr Jones."
"Good afternoon, Miss Radzikowska."
"Good evening, Ms Neal."

Giving people such a greeting sometimes feels awkward today, when many people cast off such artifice and defer to first names as being more "real" or "honest."

I'm not so sure.

I prefer to not abandon them out of hand and presume a familiarity that is not honestly present. Such things help keep the wheels and cogs of society moving as smoothly as possible, when they tend to be clunky at best.

Reach out with open handed kindness to another human person. Recognize them as worthy of respect and kindness. We don't know what they are struggling with themselves and sometimes small things might help them get through the day.

Be kind, even when it is hard for you to feel kind.

As Burns wrote over 200 years ago -
Then let us pray that come it may,
(As come it will for a' that,)
That Sense and Worth, o'er a' the earth,
Shall bear the gree, an' a' that.
For a' that, an a' that,
It's comin' yet for a' that,
That Man to Man, the world o'er,
Shall brothers be for a' that.

Monday, November 26, 2018

Testing, Limiting Failure and Improving Better

In this post, I wrote about demands and practices that lead to myriad problems in software development - even though every story (really, Backlog Item, but, whatever) is marked as "Done."

In this followup post, I wrote about things that can be done to mitigate the damage, a bit.

This is looking at the problems in the first post (above) and how this might be tied to answering the implied question in this post.

I suspect these are all tied together. I also suspect that people have been told by experts, or read a book, or talked with a peer at a large company who heard that a cool, Silicon Valley company is now doing this - and so they are jumping in so they can attract the best talent. Or something.

Let's talk about a couple of subtle points.

Testing

That is something all of us do, every day, whether we want to admit it or not. It may not be testing software, but it may be something else, like "I wonder what happens if I do this." At one time, most people writing production facing, customer impacting code were expected to test it - thoroughly. Then we'd get another person on the development team to test it as well. It was a matter of professional pride to have no bugs found by that other person, and a matter of pride to find bugs in other people's work.

I remember one Senior guy telling me "Before you hand this off to someone to test for you, make sure you have tested everything you possibly can. Document what you did and how, so that if something IS found in later testing, we can see what the difference is. Then the next time, you can test that condition when you test the others. Make them work hard to find something wrong."

That stuck with me and helps guide my thinking around testing - even 30+ years later.

Things have shifted a bit. Much of what we did then can be done fairly quickly using one or more tools to assist us - Automation. Still, we need some level of certainty that what we are using to help us is actually helping us. The scripts for the "automated tests" are software, and need diligent testing just as the product we need to test so the company can sell product, customers are happy and we don't get sued - or worse, brought up on criminal charges.

Still, when done properly, automated test scripts can help us blow through mundane tasks and allow people to focus on the "interesting" areas that need to be examined.

OK, caveat #1 - check the logs generated by the tests - don't just check to make sure the indicator is green. There MAY be something else happening you have not accounted for. Just, do a sanity check.

Then, while code is being worked on, and unit tests are being prepared (presuming you are doing TDD or something similar) someone NOT working on that piece of code look at the story (or backlog item, or whatever) and look at the tests defined in TDD and ask "What would happen if this happened?"

Now, that could be something like, an unexpected value for a variable is encountered. It could also be something more complex, for example, a related application changes the state of the data this application is working with.

One approach I have used very often, look at a representation (mindmap/decision tree/state diagram) of what the software looks like before, and after this piece is added. What types of transactions are being impacted by this change? Are there any transactions that should not be impacted? Does the test suite, as it is running, reflect these possible paths?

Has someone evaluated the paths through the code? Beyond simply line and branch coverage, how confident are you in understanding the potentially obscure relationship between the software, and say, the machine it is running on going to sleep?

Have you explored the behavior of the software, not simply if it "works?" Are there any areas that have not been considered? Are there any "ghosts in the machine"? How do you know?

Testing in Almost-Agile

I have been told by many "experts" that there is no testing in "Agile." They base this, partly, on the language or wording in the Agile Manifesto. They base it partly on the emphasis on everyone being responsible for quality in a "whole team" environment.

Some even point to the large Silicon Valley companies mentioned earlier who state very publicly they "don't have any testers."

Yet, when pressed, there are often clarifying statements like "We don't have testers in the Scrum teams, because we rely on automation for the Function testing." Here is where things kind of break down.

No "testers" in the "Scrum teams" because people write automation code to test the functions. When asked about "Integration Testing" or Load or Performance or Security or any of the other aspects of testing that testing specialists (sometimes referred to as "Testers") can help you with, do really well, and limit exposure to future problems, and possibly future front pages and lawsuits - the response often is "We have other teams do that."

Wait - What?

The "Scrum Team" declares a piece of work "Done" and then at least one or two other teams do their thing and demonstrate it is not really "Done"?

Mayhap this is the source of "Done-Done"? Is it possible to have Done-Done-Done? Maybe, depending on how many teams outside of the people developing the software there are.

That sounds pretty Not-Agile to me - maybe Almost-Agile - certainly not Scrum. It sounds much more like one of the Command-and-Control models that impose Agile terms (often Scrum) on top of some form of "traditional software development methodology" like "Waterfall." Then they sing the praises of how awesome "Agile" is and how much everything else stinks - except they are busy in stage gate meetings and getting their "Requirement Sprint" stuff done and working on their "Hardening Sprints."

Another Way - Be Flexible

Look at what the team can work on NOW for the greatest impact to the benefit of the project.

What do I mean? Let's start with one thing that the customer (in the person of the product owner or some other proxy) really, really wants or needs - more than anything else.

Figure out the pieces to make that happen - at least the big ones;
make sure people understand and agree on what the pieces mean and what they really are.

Then pick a piece - like, the one that looks like it will deliver the biggest bang NOW -
OR - one that will set you up to deliver the biggest band in the next iteration;

Then, figure out...
  • how to know if that piece works individually; 
  • how to know if that piece works with other pieces that are done; 
  • how to know if that piece will negatively impact the way the whole package is supposed to work;
  • how to know if that piece might open a security vulnerability;
  • if there is a way to find any unexpected behaviors in this piece or by adding this piece to what has been done.

I'm not advocating doing this all at once for every piece/ticket/story/whatever. I am suggesting these be defined and worked on and then actually executed or completed before any task is labelled "Done."

Some of these may be easily automated - most people automate the bit about each piece "works individually."

If your team does not have people on it with the skill sets needed to do these things, I'd suggest you are failing in a very fundamental way. Can I really say that? Consider that Scrum calls for cross-functional teams as being needed for success. Now, it might be that you also need specialists in given areas and you simply can't have 1 per team - but you can share. Through decent communication and cooperation, that can be worked out.

Still, the tasks listed above will tend to be pretty specific to the work each team is doing. The dynamics of each team will vary, as will the nature of some of the most fundamental concepts like - "does it work?"

Of these tasks, simple and complex alike, perhaps the most challenging is the last one in the list.

Is there a way to find unexpected behavior in this individual piece we are working on? Is there a way to find unexpected behavior when it gets added to the whole?

These are fundamentally different from what most people mean by "Regression Testing." They are tasks that are taken up in the hopes of illuminating the unknown. We are trying to shine a light into what is expected and show what actually IS.

But, who has those kinds of skills? 

They need to be able to understand the need of the customer or business AND understand the requirements and expectations AND understand the risks around poor performance or weak security, and the costs or trade-offs around making these less vulnerable. They need to be able to understand these things and explain them to the rest of the team. They need to be able to look beyond what is written down and see what is not - to look beyond the edge of the maps  and consider "what happens if..." Then, these people need to be able to share these concepts and techniques with other people so they understand what can be done, and how it can be done differently and better.

These things are common among a certain group of professionals. These professionals work very hard honing their craft, making things better a little at a time. These people work hard to share ideas and get people to try something different.

They are often scorned and looked down upon by people who do not understand what the real purpose is.

These people have many names and titles. Sometimes they are "Quality Advocates" other times they are "Customer Advocates." However, they are commonly called Testers.