Certifications

Comment

Certifications

I think the universe may be conspiring against (or with) me around this topic. In the past, I saw two posts on LinkedIn with interesting perspectives on agile certifications.

The first one was this from Erin Parsons—

Breaking News: My #CSM badge has officially expired.

And I'm not paying $100+ to renew it, because:

  1. That's not the path I'm on anymore, and

  2. I held a Scrum Master position as a certified practitioner for ~5yr, and that experience holds exponentially more value than a piece of paper I received after 2 days of training

I say it with an appreciation for the hard work I and others in the #Agile community have put into our various certifications and credentials, but please remember:
Your #value as an Agilist is not dependent on or limited to the number of acronyms following your name.
#scrummasters #agility #knowyourwhy

And the next was this from Sally Sloley—

Certs are not all bad. Yes, there are disreputable companies selling garbage. Whatever! Going for a cert can also mean a person is prioritizing expanding their knowledge and living by their belief in continuous improvement.

Do I think the certs I liked made me who I am? No? Did they give me a platform to show others in my field that I am willing to invest in making myself the best I can be? YES! Did they give me insight into how others in my field think and act in my chosen field? YES!

Collecting certs for the wrong reasons is bad, but wanting to learn new things, learn about opposing views, and investing in improvement will never be shunned by me. #choosewisely #neverstoplearning

I would first encourage everyone to read the posts in their natural environments and read the comments.

My Thoughts

These are not direct reactions to Erin or Sally. More so, their thoughts simply inspired my own reflections leading to these reactions—

  1. I do think folks who have greater than 20 or so letters after their names might be “missing the point” in some way. Just maybe?

  2. Certifications are for you. For your learning, growth, and confidence. They should serve you. If they do that, then I think they’re a good thing. A corollary here is that I believe it’s healthy to change your mind and drop a certification. I did that with my SPC and it felt great.

  3. It is always possible to take a certification class for the learning and not claim the certification/letters ;-). I’ve done this many times in my journey and have found that the learning is just as resilient.

  4. I’ve always felt that all certification classes are not equal. That the teacher/instructor makes a humongous difference in the value of the experience and learning. So, when you’re selecting a certification, consider the who as much as the what.

  5. Do you really need to list all of them? I’d say demonstrating the skills trumps showing the emblems.

Wrapping Up

Certification discussions have been going on in the agile community for, what seems like, forever. I do think they are neither good nor bad. It’s up to how the individual handles them.

As an aside, you might want to review Anthony Mersino’s, The Circus of Agile Certifications, article here. It weighs in from another angle entirely, that is the sheer number of agile certifications.

Stay agile my friends,

Bob.

 

Comment

Key Differences for Internal vs. External Agile Coaches

3 Comments

Key Differences for Internal vs. External Agile Coaches

When writing the EBAC book, my (our) perspective was largely from the position of the “universal” agile coach. One where the approaches, tactics, skills, and strategies were essentially the same no matter your place in the organization.

But there are many aspects of agile coaching where the subtleties of your place significantly influence your approaches. None is probably more varied and nuanced then whether you’re coaching as an internal (employee, full-time, FTE, role-based) coach versus an external (contractor, consultant, full or part-time, outside the organizational hierarchy) coach.

I think the differences are so compelling that I wanted to share the following table with you to sensitize you to some of the differences in perspective and approach.

While there may be differences, I want you to minimize the internal gyrations you go through to do your job. In essence, I still want you to be you as a coach. But, depending on your organizational positioning, I thought it would be useful to highlight some of these subtle and not-so-subtle differences.

3 Comments

3 KEYS to Beginning any Agile Change

Comment

3 KEYS to Beginning any Agile Change

I could have also titled this short post—The 3 Bs to Beginning any Agile Change…

Be Positive – Acknowledge & Celebrate Your Past Successes

  • Celebrate your history and journey

  • Celebrate the people who contributed to that journey

Be Real – Acknowledge and Learn from Your Past Failures

  • Mine thru the defensiveness and denial

  • Find the failures, face them, and embrace them

Be Caring – Acknowledge and Begin the Healing from Your Past Traumas

  • Every organization has induced some level of deep trauma, find it, expose it

  • It could be individual-based (ghost spirits); name them

I’d recommend doing this as part of an open space (or similar) event where you kick things off with your team.

Then, using these insights, craft your overarching Why for moving to agile ways of working and then leverage that to focus your strategy.

Food for thought. Stay agile my friends,

Bob.

Comment

Treating Managers Like…

Comment

Treating Managers Like…

I came across a post entitled—Stop treating managers like the bad guy, by Sander Dur. And here’s a LinkedIn thread that contains some interesting reactions to it. 

I’ve written on this topic several times as I believe there’s a significant anti-pattern in the agile universe where we treat managers poorly. Largely by the same folks who claim the managers are treating them poorly. So, reciprocal disrespectful behavior.

Here are two of those articles:

In fact, I believe this is one of the primary factors that have served to drag down agile transformations. Serving as a blaming, disrespectful, and braking function that inhibits learning, growth, and forward progress.

One of my hopes for our agile future is that—

  • Leaders & managers develop into the agile leaders we need for tomorrow’s high-performance organizations and

  • Teams meet them where they are, take responsibility for their parts, and partner to create those organizations.

Well, one can hope!

Stay agile my friends,

Bob.

Comment

You don’t understand

Comment

You don’t understand

I saw this post by Jeff Gothelf and I felt compelled to weigh in, just a little. 

First, I don’t believe Jeff needs my help. He did a great job of defending himself, his position, and his thoughts. But I didn’t want him to stand alone.

Points to be reaffirmed and made:

  • Cargo Cult agile is still alive and well in the world and we need to recognize it.

  • We need to be able to respectfully critique, debate and disagree around agile topics.

  • And there needs to be no room for personal attacks. Attack ideas, but don’t make it personal or attack people.

Wrapping Up

The agile world needs more Jeff Gothelf’s. Instead of attacking them, we should be thanking them. Thanking them for challenging the status quo, bringing in new ideas, and having the courage to be a bit disruptive.

Those are the attributes of the original Agile Manifesto folks and we need that more today than we did then.

So, stay agile and stay open-minded, my friends,

Bob.

Comment

Your CEO should be your Chief Agility Officer

Comment

Your CEO should be your Chief Agility Officer

While I agree 100% with the spirit of this article, I want to riff off of it from an agile transformation leadership perspective…

It’s simply not good enough for a CEO of a company that aspires to agile ways of working (transformation, business agility, flow, employee engagement, etc.) and not take a strong ownership stake in it themselves.

To simply hire someone to make things be agile without being in the game themselves. Not as a:

  • Sponsor

  • Supporter

  • Proponent

  • Advocate

  • Stakeholder

  • Funder

  • Cheerleader

Isn’t good enough. Not for something as powerful, as challenging, as impactful, with as much potential as changing their culture and the way they do work.

Comment

The Weeds

Comment

The Weeds

John Cutler recently wrote an article on his Beautiful Mess blog entitled—The Weeds. In it, he explores the notion of going too far into the details of a role/activity from another role perspective. Aka, getting into the weeds.

For example, a project manager might be asking too detailed questions about the design of a particular UX component and trying to reduce the effort associated with it. They have gone “into the weeds” with the developer.

A couple of things that this article made me think about including—

Comment

Long-Lived Teams

1 Comment

Long-Lived Teams

Someone in my network sent me the following question the other day:

One question that's been surprisingly hard to answer is "Where did the concept of a long-lived team (vs a team that adjourns after a project is complete) first surface?"

And it started me to thinking about the notion.

Today, we talk a lot about moving from a Project focus to a Product focus, that is from:

Teams are formed and then disbanded or reorganized around the dimensions of a specific project. When the project is done, the team is done.

To

Teams are formed around a product area (or function) or around a functions area (infrastructure, architecture, etc.). The teams in this case are longer-lived in that there are no artificial closures based on their work.

Clearly, the latter strategy aligns better with the notion of a self-directed, cross-functional, high-performance agile team. But to the questioner’s point, when did that surface as an intentional focus, or even a directive or thing, in the agile community?

1 Comment

Who’s to Blame?

Comment

Who’s to Blame?

Jon Rennie has an interesting twist here, in that, the leader is ALWAYS to blame for EVERYTHING. Well, at least the captains in the US Navy are held responsible for ship-wide mistakes. 

And it got me thinking. Is this true of organizational leaders? Or technology leaders in agile contexts?

If something bad happens, we look to the following—

  • The Senior leader

  • Management

  • Teams

  • Individuals

To see who’s responsible for it? I can’t speak for all cases, but only what I’ve seen in my own experience. Typically, the organization and organizational leadership seem to look for the lowest level individuals to blame. With many fingers being pointed in all directions. In other words, I think the “captains” are held accountable in very few cases.

Wrapping Up

And is assigning blame or blaming even the point?

Or is it better to focus on learning what happened (root cause) and on preventing it from happening in the future?  

I’m still mulling this one over from a leadership perspective. I thought I’d share it with you to see what you think?

Stay agile my friends,

Bob. 

Another related link – https://www.military.com/daily-news/2021/11/04/navy-fires-2-top-officers-of-submarine-damaged-collision.html

Comment