My New Role – TechWell Program Chair

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.

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

You might be an agile leader if...

2 Comments

You might be an agile leader if...

I delivered a keynote at the Agile Development + Better Software + DevOps conference put on by TechWell on Wednesday, November 8, 2017 in Orlando. 

The feedback I received was wonderful and it seems the talk resonated with quite a few of the attendees. 

At some point, I'll get a link to the video of the keynote and I'll share it here. Until then though, here's a link to the slide from the talk.

2 Comments

Advice for leading an Agile Transformation

1 Comment

Advice for leading an Agile Transformation

Nathanial Willis posted this in LinkedIn recently:

I asked Steve Denning for advice on how to successfully lead an agile transformation and here's what he said:

  1. Get a bullet-proof vest and hockey mask because you're going to get beaten and be shot at! (As he laughed)
  2. Stop communicating over email - do it face-to-face; preferably in a bar. (No seriously)
  3. Discover your executive leader’s problem. Find a story of how another company solved that problem and share it.
  4. Focus on the 20% that want to change. Forget about the folks that don't.

1 Comment

Just a little…Forgiveness

Comment

Just a little…Forgiveness

I was attending the STPCon conference in Washington, DC last week (week of September 25). As always, there were quite a lot of old friends there. Folks I usually only meet on the conference circuit.

The conference committee tried a Lightning Talk format for the first time. They invited 7-8 speakers on stage to give 5-minute, focused talks. Dot Graham gave one that is still sticking with me.

She focused on creating (fostering, inviting, inspiring, allowing) a mistake culture. One where everyone focused on two aspects of their mistakes:

  • Learning from them, and
  • Forgiving themselves for them.

I’ve heard the learning part many times before. But this is the first time that I’ve heard “forgiveness” mentioned as part of creating a learning culture and it struck me.

In a team environment mistakes always happen. Sometimes they’re small things. And other time, they’re large ones which have an impact on the entire team.

I have a saying that I often share in my coaching and teaching. I amplify that agile teams (all teams really) succeed and fail as a team. That is, we don’t throw anyone under the bus, but we deal with everything from the solidarity of a WHOLE TEAM perspective.

I now want to add other attributes to that description:

  • We reflect as a team;
  • We learn as a team;
  • We make mistakes as a team;
  • And we forgive ourselves as a team.

I love the Norm Kerth sentiments regarding the Prime Directive for retrospectives where he sets the stage for the “intentions” of all attendees.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

I think this sentiment helps us in our view towards mistakes and our forgiving each other (including ourselves) for making those mistakes.

I know that I for one can be really hard on myself when confronting the things I’ve done wrong.

As Dot reminded me, I want to encourage all of you in your agile journeys to be kind and forgiving of one another. Remember, they are ONLY mistakes and we all make them!

Stay agile my friends,

Bob.

Comment

What the world needs now…Is Radical Candor

1 Comment

What the world needs now…Is Radical Candor

I came across a video the other day that had this catchy title – Radical Candor. I watched it and was intrigued by the talk AND its implication to agile teams, organizational transformations, and sustainable cultures.

Kim Scott was the presenter in the video and she was sharing lessons she’d learned in her leadership journey at Apple and Google. In a nutshell, she was advocating radical candor for leaders in communicating with their direct reports.

The stories she told made me think about my own career and leadership journey. A couple of which I’d like to share with you.

1 Comment

DevOps Explained...Simply

2 Comments

DevOps Explained...Simply

I wish I could remember the young lady’s name. She was from a European DevOps tooling and consulting firm and she did an interview with me at one of the TechWell Star conferences. I believe it was StarWest at the end of 2016.

She was interviewing speakers to get their take on the implications of DevOps in agile, testing, and across software methodologies.

I recall vividly that she referred to DevOps as an evolutionary step beyond “agile” in nearly in every question she asked. And I told her I struggled with that idea. She was also very automation centric and extremely tools centric in her questions – referencing and emphasizing various DevOps oriented tools at every opportunity.

It’s not that I was defending agile. It’s that I have a very different view to DevOps and what it means than I was hearing from my interviewer. And I continued to explain and amplify my view in nearly every answer.

At the end of the interview, I felt that she understood my point of view. And that she had rationalized it against her own to create a more cohesive mental model for DevOps. I asked her to send me the link to the final interview, but to-date, I haven’t heard back.

And I continue to get questions during my coaching and consulting around DevOps, so I was inspired to write this post as a means of sharing my views.

2 Comments

Agile Leadership – Eating our own Dogfood

Comment

Agile Leadership – Eating our own Dogfood

Or The Dynamics of an Agile Transformation Team

I found this great article about a leadership team (SLT) adopting agility WITH their teams.

http://blog.qrious.co.nz/how-to-navigate-with-agile-leadership

It’s relatively short, but powerful because of the perspective. That is, it focuses on the activity of the senior leadership team in an organizational agile transformation.

I often think one of the core challenges for most leaders is that they are stuck in a situation where they’re telling their teams and organizations –

Do what I say, Go Agile, and not what I do

That is, they are not walking their talk. Now don’t get me wrong. It’s usually not a malicious or lazy play. It’s simply that they have more important things to do. Things that require their specific skill set and expertise to lead and get done. So, there is little to no time left for working like or with their agile teams.

Some may think this is ok and that it doesn’t really have an impact on the agile organization. Or the potential agile organization. I actually think it has a very negative effect.

Comment

Agile Leadership – Keep it simple, stupid!

1 Comment

Agile Leadership – Keep it simple, stupid!

We’ve all heard of the KISS principle. It stands for: keep it simple, stupid.

Well I want to apply it to software development leadership. Particularly those leaders that are in an agile context.

I’ve been hearing a tremendous amount of pushback and whining amongst leaders in agile contexts of late. What you say. How can this be?

Here’s a sampling of the running types of dialogue (complaints, whining, pushback, etc.) that I’m referring to:

  • We’ve already committed to customers a release date for a new, highly profitable product by June 1. However, the agile teams keep saying it will take till January. I thought agile would allow us to get more…faster. It’s sounds like every other time when the teams couldn’t seem to meet our demands. Where’s the creativity? Where’s the can-do attitude? Where’s the commitment to hard work? Where’s the agility?

1 Comment