Sunday, September 29, 2019

Developers and Testers Are Made, Not Born

I read fairly regularly, and hear more often, that "developers don't make good testers."

Of course, I also see, and hear, just a little more hushed so as not to offend delicate sensibilities I think, that "testers don't make good developers."

To both of these assertions I'd like to offer the same (heavily edited) response:


People learn skills. Very few are born innately knowing how to write code (in any language). Very few are innately knowing how to test software and report the results in a meaningful way.

These "testers" who go on about developers not making good testers have no idea what they are blathering about. Likewise, "developers" who like to talk down to testers, or talk poorly about testers when there aren't any around, are likely insecure ninnies.

Being a good developer means you also test. These days, being a good tester means you can at LEAST read through and understand code.

The hardest part of both jobs is to admit you don't know something. The second hardest part is to communicate clearly and openly.

All of you, get over yourselves and learn how to work together.

Carry on.

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!


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.


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."
OK, Folks caught main points of Ash's talk on twitter pretty well. (Here, I made a link thing for you: )

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...

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...)


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 -

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.
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
“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
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.