My Heros: Rob Sabourin

Comment

My Heros: Rob Sabourin

There are individuals who have influenced my professional journey significantly. Sometimes, by working with me directly. Other times, by their writing or position in our software community. And other times, simply as a role model.

I've started a segment on my blog called – My Heroes. I’ll post intermittently, perhaps every 1-2 months. But it serves as a reminder to me to be thoughtful and appreciative of the folks who’ve influenced my growth and skills. And of course, they get none of the credit for my many foibles.

The third one up is: Rob Sabourin

Rob is a stalwart in the testing community. He's been talking about software testing for, what seems like, forever. He has a real passion for all aspects of testing. While I've traveled and done similar work to Rob in the software testing arena, I can't hold a candle to the depth, breadth, and real-world applicability of his experience. 

He's affiliated with McGill University and has facilitated quite a few research projects over the years. So, he's giving back to students and to our community as well. Sometimes I've wondered how many people have been influenced (for the absolute better) by Rob. I can't even imagine the numbers.

If you've ever attended a talk, workshop or another session format by Rob, a few things always stand out:

  • His passion and energy just blows you away;
  • His encyclopedic knowledge of the subject matter;
  • And his sense of humor, with a unique ability to "connect" with his audience.

all make Rob a unique and valuable gift to our community.

I Am A Bug

In 1999, Rob published a book with his daughter Catherine that explained the craft of software testing to everyone, including children. Years ago I used to buy copies of it as gifts for testers on my teams who had young children.

While I kid with Rob that he really should have written (write) more books, I am a Bug is truly unique and a classic gift to our testing community. 

When I "met" him

Around 2001-2 I started working on my first book - Software Endgames. It was later published in 2004. I was new to the community and I was aware of him by his reputation and interests. One of the common interests we had was defect workflows, triage, and generally how to effectively handle bugs in software projects. This was one of the main themes of Software Endgames, so I thought I'd ask Rob to review my manuscript.

While I didn't know him personally at the time, I thought, what the hell, all I could do is ask. So I sent him an email introduction and a copy of the manuscript. He immediately replied and agreed to give me some feedback.

2-3 weeks later I received a VERY detailed, chapter by chapter, review of Software Endgames. It was feedback beyond my expectations and incredibly helpful. Rob also sent me encouragement that the book added value to the community and that lifted my spirits to continue in the books finalization process.

To this day, his incredible generosity in taking the time to help and support a total stranger sticks out to me.  He made Software Endgames and me far better for the experience. And the example.

WRAPPING UP

One of the defining aspects of my heroes is that they’ll probably be embarrassed to be categorized in that way. Nonetheless, they are my heroes.

They’ve helped me to become the person, trainer, speaker, and coach that I am today. Whether they’re aware of it or not.

Rob Sabourin, you've shown me what it's like to be a professional. To maintain your energy and passion around doing what you love. You've also been a role model to me. I've learned much by simply watching you work. Not only in front of a class, but as an individual. Your generosity in helping me with my book has stuck with me. And encouraged me to "give back" to folks as much as I can.

But beyond my accolades, I consider you a colleague and, most importantly, a dear friend. It's this that I'm most proud of and humbled by. 

I’m incredibly blessed to know you and want you to know that you are my Hero.

Stay agile my friends,

Bob.

Comment

Meta-Cast LIVE @ Red Hat Agile Day 2017

Comment

Meta-Cast LIVE @ Red Hat Agile Day 2017

Josh and I were invited to deliver a live version of the Meta-cast for Red Hat Agile Day this past October.

Here's the description of our session:

The “Meta-Cast” Comes Alive

Since 2011, Bob Galen and Josh Anderson have been recording the Meta-Cast podcast. It’s an agile focused discussion that has literally covered every agile topic in its seven years and over 120 episodes. The podcast reaches listeners on virtually every continent and has received numerous accolades from listeners and fellow podcasters alike. In this session, Bob and Josh will be bringing the Meta-cast to you, a live audience. The podcast will be recorded and streamed live. We will gather your most challenging, interesting, and potentially exasperating agile questions and challenges. Then we’ll answer each of them with our collaborative and fun style. This session will prove to be fun, insightful, and driven by YOUR needs. So please, join the Meta-cast and try to “stump the chumps” or simply get some free coaching towards your greatest challenges.

Here's a link to the video recording of the session: https://bluejeans.com/s/MWMJy

And here's a link to the associated Meta-cast: http://www.meta-cast.com/2017/10/episode-122-red-hat-agile-day-q-session.html

Hope you enjoy it! We hope to do a similar session at future conferences. 

Stay agile my friends,

Bob.

Comment

2017 Agile Dev + Better Software - Tricentis Interview

Comment

2017 Agile Dev + Better Software - Tricentis Interview

I met a colleague, Noel Wurst, at the Agile Development conference. He's now working for Tricentis and he asked me to do an interview for their website content. Of course, I agreed.

I thought I'd share my replies to his questions. And I want to thank Noel for asking me. It was an honor to contribute...

Here are the interview questions that Noel asked and my replies:

1. Continuous feedback: I hear a lot of people talking about needing to shorten feedback loops, automate reporting, and development, test, and release cycles that deliver continuous feedback. And I agree. CF is highly valuable. But sometimes I wonder if, once people put those things in place, can they immediately act or respond to that feedback? How important is being able to do that, and not just collect or note that feedback, but adjust on the fly to make new decisions, pivots, and responses continuously as well?

I think this is a really important point, Noel. And it’s not simply related to continuous feedback, but also to the continuous improvement cycle. For example, feedback on adjustments that are raised in team, project, or organizational retrospectives. To your point, our lean-age should be towards doing something about our discoveries, in taking action.

Comment

Agile Software Capitalization...Boring!

Comment

Agile Software Capitalization...Boring!

One of the topics that I've typically avoided at agile conferences and in discussions with colleagues is software capitalization. Particularly in agile contexts.

The first reason is that it's usually used as an excuse to undermine agile principles and as a means of continuing old practices. 

The second is that I find it somewhat...boring. Yes, it's often necessary for many enterprise or larger-scale contexts. But I'd rather the teams focus on innovation, customer value, and deliver than on capitalization.

And the third reason, which is somewhat embarrassing, is that I never had a succinct recommendation for folks on how to handle it in agile contexts. I always felt that I said "it depends" too often.

Excuses

But all of those reactions were excuses. And I do realize that it's a serious topic for many folks. So, imagine my delight when I came across a real-world blog post from Stephanie Davis of Valpak in Tampa Florida that explained how they've been handling it. 

And not only that, the post contains some reference post that nicely provides additional capitalization examples and advice.

Wrapping Up

I've shared this post to be my "Go To" reference for capitalization. Thank you, Stephanie, for sharing!

Stay agile my friends,

Bob.

Comment

There IS an I in an Agile Team

1 Comment

There IS an I in an Agile Team

I’m beginning to think that we’re too focused on the team when we talk about agile. Everything is focused towards that end.

Team this and team that.

But what about the individual on the team? I contend that they count too.

  1. Make sure your voice is heard; in many team’s individuals can get lost. Often the loudest of voices seem to become the default voice of the team.
  2. Make sure you take time for yourself; self-learning, downtime / reenergize, reflection are keys to your personal growth and learning. Always increase your value proposition – you.
  3. If you’re introverted, give yourself permission to be alone; this includes working from home and “separating” from the team on occasion to work by yourself.
  4. Gain personal feedback; don’t get caught up in team-only feedback loops. While important, you need personal feedback as well. Make sure you’re getting it from your team and leaders.

1 Comment

2018 - Coaching Circles

Comment

2018 - Coaching Circles

I've been running experiments for the past year around doing virtual coaching. I call the sessions Coaching Circles and they take the loose format of a Lean Coffee hosted via Zoom.

They run for 90 minutes and, so far, attendees have seemed to gain great value from them.

Oh, and did I mention that they're free?

I've increased the frequency to (roughly) 2x a month for the early part of 2018 and have them scheduled for January - May. If you'd like to participate, you can get more info and register here - https://www.eventbrite.com/e/coaching-circles-wbob-galen-tickets-41323509730

Just one of the ways I'm trying to "give back" to our wonderful agile community.

Stay agile my friends, 

Bob.

Comment

My New Role – TechWell Program Chair

1 Comment

My New Role – TechWell Program Chair

I’ve been speaking at TechWell events since around 2000. First, I started out with track talks. Then I started sharing full-day and ½ day workshops. I’ve also been invited to deliver several keynotes at the Star and Agile Dev / Better Software conferences.

All-in-all, it’s been a professional relationship that I’ve really enjoyed.

Recently, the long-time program chair, Lee Copeland, stepped aside. I truly want to thank Lee for the years he invested in helping me grow this side of my consulting practice. I owe him a great deal.

Program Chair & Talent Scout

Given my history and experienced, TechWell approached me to help fill the Program Chair role for the:

  • Agile Development
  • Better Software
  • DevOps

Conference series going forward.

The conference has a West / East format. The West version is held in Las Vegas, typically in early June. The East version is held in Orlando, typically in early November.

The programs are usually developed 8 months in advance of the conference, so you need to reach out to me early if you’re interested in participating.

The program chair is responsible for pulling together approximately:

  • ~4 Keynote presentations
  • ~4 full-day workshops
  • ~20 ½ day workshops
  • ~60 60-minute track talks

across the four major themes (Agile Development, Traditional Software Development, DevOps) of the conference.

And the talent scout part of my role will focus on looking for new and interesting topics, speakers, and formats to introduce to the conferences.

1 Comment

Advice for my Corporate Colleagues – Find your Blind Spots!

Comment

Advice for my Corporate Colleagues – Find your Blind Spots!

Years ago, I worked for a company called Micrognosis. I shared a little about the company in this post. As I recall, I worked there from the late 1980’s to 1996 or for about 10 years. Over my entire 35+ year career, it was my longest tenured job. And I did a lot of growing there, both in my role and in my self-learning.

When I left Micrognosis, I moved to North Carolina for a software leadership role at Bell & Howell Mail Processing. So not only did I change jobs, but I relocated my family as well. To say the change was a bit scary for me and my family is a bit of an understatement. But we moved and never really looked back.

I realized after about three months at Bell & Howell that I’d stayed in my Micrognosis job for a bit too long. That I’d developed some “blind spots” that I didn’t even know I had.

Let me explain.

Comment

Agile Planning – Getting Punched Every Day

1 Comment

Agile Planning – Getting Punched Every Day

There’s a famous Mike Tyson quote:

Everyone has a Plan
until they get Punched in the Mouth

It reminds me of the ultimate futility of estimating and planning. Or investing too much in both of those endeavors. Particularly in the area of software product development.

Another related quote is from Eisenhower. It surrounds the value of plans (artifact) vs. planning (activity):

I have always found that in preparing for battle that
Plans are Useless,
but Planning is Invaluable

That is:

  • The activity of exploring requirements via user stories and acceptance criteria;
  • The activity of minimizing (MVP) the results so as to learn;
  • The activity of making estimates as a vehicle to explore size, scope, risk, and design approaches;
  • The activity of discussing construction and deployment strategy;
  • The activity of delivering work to stakeholders and gaining their feedback.

Are all more valuable than fixed or static plans, which are intolerant of the punches that are inherent in software development - learning and discovery.

Wrapping Up

The next time you find yourself getting “stuck in” your plans or thinking that planning is more important than doing and adjusting, then please remember these two quotes. Also remembering, that Tyson and Eisenhower weren’t practicing agile software development. But they were indeed…agile.

Stay agile my friends,

Bob.

1 Comment