Co-Creation

I found this short post by Dana Houston Jackson on LinkedIn that I thought I’d share with you—

Co-designing is not the same as: "You'll have a chance to comment before finalized." To get maximum people's embracement, adoption and usage of the solutions then do the hard work and co-design.

Yes-you'll have to deal with human emotions and reactions. Yes-you'll have to move them through a groan zone to arrive at a convergence. Yes-it takes more time and effort at the start. But it is e-v-e-r-y-thing if you want maximum adoption in the end- the result (adoption/usage) that you should be after in the first place.

So, you gotta ask yourself: How much do you want people to sustain the work afterwards?

Then do the harder work at the start.

The post and the comments just struck me as really important considerations if you’re engaging in organizational transformation and change.

And it aligns so nicely with Dan Mesick’s work on invitational leadership.

Stay agile my friends,

Bob.

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.

The Balancing Act of Agile Adoption

I’ve been thinking of balance lately when it comes to agile transformations. And, the sad truth is, I don’t see that much of it.

I either see organizations who are too focused on leadership and leaders driving the transformation, so skewed towards them. Or organizations that are coddling the teams and letting the inmates run the asylum, so skewed towards the team.

What does “Balance” need to look like?

I’ll give you a quick example. There’s the notion of servant-orientation and servant leadership in agile contexts. This is normally focused on leaders serving their teams. For example, a Scrum Master is a servant leader in their mindset and they need to serve their team.

But for every reaction, there should be an equal and opposite reaction to achieve better balance. So, yes, leaders need to serve their teams.

But the reciprocal is that teams need to serve their leaders as well. They need to give be respectful of their roles, inclusive of their ideas. They need to provide the transparency of forecasts, work, and progress to support the leader’s operational needs. 

Josh Anderson and I explored this notion in more detail in one of our recent Meta-casts. We called the episode The Reciprocal Conundrum. I’m hoping you give it a (balanced) listen to see if it changes (or rebalances) your thinking.

Stay agile my friends,

Bob.

Principles as Questions

I saw a tweet by Cory Bryan that referenced a tweet from John Cutler from April 2021. I’m not sure how widely cast it was, so I thought I’d share it again here.  

To say that I love where John went is an understatement. And Cory’s edition of—

• “How” can we…

• “What” can we…

• And “When” can we…

Added even more value for me.

Here are John’s questions—

• Can we do more work we are proud of? 

• Can we work more joyfully, and sustainably? 

• Can we work together more often? 

• Can we learn more effectively? Can we accelerate/amplify feedback loops? 

• Can we shorten the distance between our team and customers/users? 

• Can we create more lasting value for our customers, users, and company? 

• Can we connect more of our work to real impact instead of proxies? 

• Can we delay certain decisions until we have more information? 

• Can we reduce the cost of changing our minds (both now, and in the future)? 

• Can we reduce our “inventory” of unfinished, non-value-producing work?

• Can we reduce waste that doesn’t serve the team, our customers, and our company? 

• Can we lay the foundations that will support our future success?

I think this list is particularly useful for my colleagues in the product space. I hope the questions are as thought-provoking for you as they were for me. John is a treasure in the community in that he makes me (us) think more deeply.

I need to do more of that…

Stay agile my friends,

Bob.

CoP and the LACE

SAFe LACE Alert

In my last post, I shared some ideas around the value of a Community of Practice and how to re-energize it if it’s lost a bit of momentum. Please read that one if you haven’t before reading on here.

Now I want to contrast things a bit between CoP’s and CoE’s. Specifically of the LACE kind… 

Contrasting between a CoP and a Center of Excellence?

There’s another notion you’ll often hear when discussing this area. It’s a Center of Excellence or CoE. My bias is going to shine through a bit here, but please bear with me.

A CoE is a more formal, top-down mechanism whose primary goal is the consistency of practice. That is, it’s focused on regulation and governance. Often metrics and agile performance metrics are tied to it as well. A good example of this idea is the Scaled Agile Framework’s – Lean-Agile Center of Excellence or LACE[1]. And you can also see the idea often marketed or aligned with the Agile PMO or PMI’s Disciplined Agile[2].

I’ve already alluded to the two problems I have with generic CoE’s. First is the prescriptive top-down nature—where the organization tries to mandate practices. I think that’s a non-starter in agile contexts and particularly not aligned with the agile mindset. So, implementing a CoE can actually do harm to your culture you’re trying to instill or support.

The second is that it disengages from the people doing the work. Which are the very people who are part of the “community” you’re trying to create. Typically, the teams and individuals only engage with the CoE because they’re told to. Not because they’re inspired to or are invited to participate.

In my opinion, you don’t create an agile culture by top-down mandate. It’s just doesn’t work. Instead, the organic nature of building a community of practitioners aligns so much better with our agile mindsets.

And the third challenge with creating a balanced and effective CoE relates to the agile maturity of the leadership team. If they’ve not evolved to an agile mindset, across leadership, then the CoE often becomes a mechanism for reinforcing controls and measurement.

All of these lead to problems if your goal is to truly develop and mature as an agile organization. So, approach LACE and all Centers of Excellence with caution and care.

 Stay agile my friends,

Bob.

[1] https://www.scaledagileframework.com/lace/

[2] https://www.pmi.org/disciplined-agile/people/centers-of-excellence