Personal Thoughts
Robert Galen
We've Moved
We've Moved
Walking Their Talk, Sustainability, Inspiration
Robert Galen
Sustainability

I saw this wonderfully courageous and informative post by Sabine Canditt the other day where she wrote about Sustainable Scrum. 

https://www.linkedin.com/pulse/sustainable-scrum-responsible-choice-sabine-canditt-x0gef

After just completing a The Week program facilitated by the amazing Ann-Marie Kong, it touched my heart.

That said, I wanted to highlight one comment reaction/interaction between Sabine and Erich Bühler 

Erich said—

Thank you for bringing this approach into the world! Scrum does provide an iterative approach for teams to create value, but its scope is limited to the product level and struggles with dynamics across the whole organization for several reasons.
Without updating the underlying business and financial model at a strategic level, Scrum alone cannot transform organization-wide sustainability.

Sustainability
Short-takes, Inspiration
Robert Galen
Sandy’s Take
Sandy’s Take
Short-takes, Personal Thoughts
Robert Galen
The Human Aspects of Agile Coaching
The Human Aspects of Agile Coaching
Coaching, ACGW, Personal Thoughts
Robert Galen
Keys to Building your Coaching Relationships

I talk a lot about the first step in coaching any client (individual, system, team, etc.) is to build a relationship, gain empathy and understanding, and then gain an idea of where/how to help initially. So, do NOT start to coach until you’ve done some relationship-building. 

But what does a coaching relationship, or a professional relationship in general, look like? What are aspects of that? Here are a few things that come to my mind—

  • Making + taking the time.

  • Explaining what you do—what is Agile Coaching.

  • Building some empathy; walking in their shoes; understanding where they are coming from.

  • Meeting them where they are.

  • Listening; reflective listening; building metaphors together.

  • Connecting with their language, not yours.

Keys to Building your Coaching Relationships
,

You’re WRONG, Jeff!

,
You’re WRONG, Jeff!

I saw this post from Jeff Gothelf.

https://medium.com/@jboogie/fixed-time-fixed-scope-projects-always-end-in-1-of-3-ways-none-of-them-good-9fa66e7d129e 

In which he says that Fixed Time & Scope projects end in one of 3-ways:

  1. We move the deadline

  2. We reduce scope

  3. We implement “crunch mode”, everybody puts in 80-hour weeks till the deadline, burns out, quits and goes to work somewhere else.

I want to respond to Jeff’s thoughts…

First, option #3 is was coined by Ed Yourdon as a Death March. I personally like the imagery that inspires.

Second, I agree 100% with his 3-alternatives. They seem almost as absolute as gravity in software projects.

But he goes on in the article to make the point that Product Management is primarily responsible for these problems.  

,

Oxymoron?

,

Am I the only one who really struggles with the terms:

  • Agile Project Manager?

  • Agile PMO (Project Management Office)?

I see them being used all of the time. I encounter them in adds for open positions and in organizations who are striving to introduce agility. The terminology seems to be pervasive.

But at the same time, if you put on an agile mindset, they seem to be oxymorons.

It’s not the People

And my beef isn’t with the people filling those roles. It’s with the role and responsibilities associated with them.

Here’s another “Test”

One side-effect of using these terms, and I hear it all the time, is the organizations also use the term resources to refer to their people.

Again, this terminology doesn’t align with an agile mindset.

Wrapping Up

It’s simple. Really it is.

If your organizations is moving down the road to aligning with agile principles and the mindset. Then you really don’t need project managers and a PMO.

Instead you need accountable, self-directed, and trusted teams who have a goal and understand the importance of transparency.

And you need leaders who support them, get out of the way, and expect great things. With no real need for “projects and project management”.

Stay agile my friends,

Bob.

BTW: Here’s an article by Anthony Mersino that not only supports my point, but does a MUCH better job of communicating it. Please take the time to read it - https://vitalitychicago.com/blog/myth-agile-project-manager/

Did we need a more diverse Agile Manifesto?

Did we need a more diverse Agile Manifesto?

My daughter Rhiannon is a social worker. And I’ve learned from her that my definition of diversity is much shallower than hers. She has a broad, deep, and nuanced view of it and I’m learning to appreciate hers and broaden my own. 

It’s just part of my ongoing efforts to challenge myself and learn.

That being said, it made me think differently the other day when I was reading the Agile Manifesto again. And it dawned on me that –

  • There are 17 signatories to the Manifesto

  • All 17 were men

  • All seemed to be at or approaching middle age at the time (probably well beyond by now)

  • All were white

  • All were software developers with the possible exception of Brian Marick (was he the token tester ;-)

Don’t go out without an Umbrella!

Don’t go out without an Umbrella!

I recently (January 2019) saw a tweet by someone who speaks regularly in the software / agile testing community. It was short and direct. But it had a broader impact on me beyond the words. Here’s the tweet:  

I’m a practitioner. Most of my days I’m not traveling/speaking but delivering software to partners and users and making that a better experience for us all. You don’t have to do what I do. You don’t have to tell me you disagree. Some use too much effort to correct my reality.

That complained about folks trying to correct “their reality” that they present publicly.

And I’d agree with them if they were a 100% practitioner working on private projects in private companies. That is, not in the public forum.

However, they clearly have chosen to “go public” with their ideas. In recent years, they have become an accomplished public speaker, idea presenter, and role model for many, many testers. And not solely limited to testers, but beyond to software development teams.

And with this sort of role, comes great responsibility…or at least I think it does.

,

Effectively Measuring Agile Leaders

,
Effectively Measuring Agile Leaders

Nearly every time I speak, write, teach, or simply think about agile approaches to software development, someone has to bring up measurement. 

And the measures they’re talking about inevitably focus on their teams and/or delivery dynamics. How do we measure our teams? How do we measure the impact of agility? And how do we measure your value as a coach? Are representative of the types of questions I hear.

BUT, if you subscribe to the theory that leadership sets the culture AND that culture drives performance, like I do, then why aren’t we measuring leaders in agile contexts?

The challenge is, what might that look like? Here are some of my thoughts around what we might measure –

Work Balance Matters

Work Balance Matters

More than a few years ago, I visited a client in Greensboro, NC. I did a little consulting there, but it really wasn’t a longer-term gig.

What stood out to me, after all of these years, is that folks could bring their dogs into work. And everyone seemed to do just that.

  • There were dogs roaming free in the halls.

  • There were dog play areas.

  • There were dogs at their owner’s desks.

  • And those that didn’t have dogs were playing with others dogs.

  • And yes, there was the occasional “doggie accident” ;-)

It was a wonderful environment. Instead of feeling like an office space, it felt like a home that I was visiting. A comfortable home where the family loved their pets.

Another example, kids

Leadership Observations

Leadership Observations

I’ve been telling this story (or details) anecdotally in my agile and leadership classes for a number of years. But I thought I’d also capture it in the blog.

My initial goal was simply to capture my observations. But I’d like to hear from others and their experiences.

My working journey…

I started working as a software engineer at Sperry Univac in 1981 and am still working. If my math is right, that’s 37 years and counting.

Ugh, right!

The Agile Monk

The Agile Monk

First, this is inspired by an attendee of one of my Coaching Circles.

His name was Amaranatho Maurice Robey and he has an introductory video here - https://youtu.be/ImvuQizaMsE

He inspired me to look at Buddism a bit and I found this wonderful article about Buddhist Monk Habits: https://ideapod.com/10-buddhist-monk-habits-hard-to-adopt-but-life-changing-when-you-do/

I’d like to relate them to an agile mindset, both individually, but importantly, at a Leadership Level. I might even include them in my CAL class in some way…

  1. Outer de-cluttering

  2. Inner de-cluttering

  3. Meditating a LOT

  4. Following the Wise

  5. Listen mindfully and without judgment

  6. Change is the only law of the universe

  7. Living the moment

  8. Focus on one thing

  9. Give it everything you’ve got

  10. Let go of what you can’t control

Here are my agile learnings and reactions from this list: 

Pocket Knives & Agile

Pocket Knives & Agile

You all may not know this, but I’m a fairly avid collector of pocket knives. I tend to gravitate towards knives that are:

  • Well-made & high quality

  • Somewhat unique

  • Made by manufacturers with solid reputations

  • That have great customer reviews

While I care about the ultimate price, I care more about all of the above factors. I guess I consider each purchase an investment of sorts as I build my collection.

Chris Reeves Knives

What IS your Legacy?

What IS your Legacy?

I spent over 10 years working at a company in Connecticut called Micrognosis. I wrote about an aspect of my experience there in this post.  

During my tenure at Micrognosis we delivered many, many products and projects. We made millions of dollars on our technologies and our customers were fairly happy with our efforts. All of this happened in the span from 1986 – 1996. If you asked me today whether anyone, and I mean anyone, really cares about the efforts we made (products, effort, blood-sweat-tears, etc.), I’d say no.

One of the hidden factors in all of our legacies, and I know technologists don’t want to hear this, is that what we’re working on really doesn’t matter in the long term. No matter what you’re working on!

For example, Netflix or Google or Spotify of today really won’t matter (technically) 20 years from now. Sure, they’ll be historical notes about them on Wikipedia, but the products themselves won’t matter.

SO, WHAT DOES MATTER?