Viewing entries in
Agile Execution

Are you playing Football by the Rules?

Comment

Are you playing Football by the Rules?

I have to admit that I’m quite the American Football fan. Growing up in Pennsylvania, my team was the Philadelphia Eagles. If you know anything about them, you know that they have a relatively “vigorous and unrelentingly positive” fanbase. 

https://www.facebook.com/UKGridiron/videos/snowballing-santa_15-december/743806219452545/

But then years ago, I moved to the New York tri-state area and became a fan of the NY Giants. I root for those two teams during the season unless they’re playing each other, then I root for the Eagles.

But let’s move it along a bit…

Are you playing Football?

While there is heated play on the football field, I don’t see a whole lot of debate whether one team is playing football or not. The rules are fairly clear and the teams are expected to adhere to them.

For example, 4 – 15-minute quarters, or no tackling with the crown of your helmet, or touchdowns are worth 7 points and occur when you cross the goal line.

The rules are intended to frame the game so that everyone is playing within a rudimentary and relatively simple set of constraints.

What’s truly important?

What’s truly important seems to be—winning the game. And, from a coaching perspective, that involves the following:

  • Finding good people with the appropriate skill levels

  • Forming an identity, establishing an offensive and defensive strategy (identity)

  • Giving them the opportunity to form and operate as a team

  • Practice, practice, practice; learning from the videos and continuous improvement

  • Get out of the team’s way and let them play the game…

  • Rinse & repeat.

Perhaps a little time is spent on the rules, but the critical thing is finding and developing a shared vision and focusing on the goal—winning games.

Not answering the question—are you doing & playing football or not?

The point?

There seems to be an ongoing debate in the agile community around Scrum. That is, are you doing Scrum or not?

As an example, I saw this post from Martin Hinshelwood on LinkedIn where he makes the definitive point—

The minimum bar

for Scrum is a

working usable

increment every

iteration

including the first.

And Martin should know since he’s been a PST (trainer) with Scrum.org for the past 12+ years.

But it made me think…

Is the point of agile, business agility, agile mindsets, the agile manifesto, principles, delivering customer value, lean thinking…

  • Doing Scrum?

  • Delivering a working, usable increment every iteration?

  • Explicitly following the rules as dictated by “experts”?

Or is it something else entirely?

And should influencers, experts, and pundits like Martin be focusing on the rules…or something else?

Wrapping Up

Just to be clear, I’m not arguing with Martin. He’s certainly more experienced in “Scrum” than I am.

And I “get” his point about delivering “working software”. Heck, it’s principle #3 in the Agile Manifesto, so essential and relevant. But they didn’t say every iteration in the Manifesto. Instead, they said frequently.

But should THAT be the focus? Following the rules? Doing Scrum?

I think not. As in football, I believe it’s about setting the table to—Win the Game!

And that isn’t necessarily about Scrum or certification letters or continuously advocating to do Scrum by the book. We must leave these endless debates and positional statements behind us and focus on the game and the results.

Stay agile my friends,

Bob.

BTW: I do apologize for the “football” metaphor. I realize it isn’t very clear globally, but perhaps useful as well…

And I thought I’d share some additional examples of rules over the primary goal.

Comment

Great Teams Don’t Grow on Trees

Comment

Great Teams Don’t Grow on Trees

Heath Nichols wrote a wonderful post entitled—Great Teams Don’t Grow on Trees.  

It reminded me of the importance of investing in your agile teams, trusting and empowering them, and the need to never take them for granted. In other words, it’s about the team, Stupid!

I’ve written a couple of posts surrounding the topic as well—

I hope you take the time to read Heath’s article and perhaps follow up with mine. That being said, never forget to appreciate the value of your teams!

Stay agile my friends,

Bob.

And here are additional resources on this topic—

Comment

Explorations Around Agile Teams

1 Comment

Explorations Around Agile Teams

I’ve been doing agile coaching for over two decades. If there were a Top 5 question I get when doing organizational and leadership coaching, it’s—

  • How do I set up my teams? Vertical, horizontal, hybrid.

  • What exactly is an x-functional team?

  • What about distributed team dynamics?

  • Are the roles full-time? Or can I share everyone?

  • How do I handle shared, service-oriented, or platform teams?

For a long time, I wished for a solid reference that I could send to folks when they have these sorts of “teaming” related questions.

Well, the good news is now I do, but it’s not one book. It’s a triplet of books.

1 Comment

My Learnings on Backlog Refinement

1 Comment

My Learnings on Backlog Refinement

This article by Martin Hinshelwood entitled—If your backlog is not refined, then you are doing it wrong; inspired me to write this article. 

Here’s the LinkedIn post with some valuable commentary…

I wrote the first edition of my Scrum Product Ownership book in 2009, then a second edition in 2013, and a final / third edition in 2019. There was a period of time from ~2007 to 2020, where I was spending a majority of my time teaching and coaching in the agile product space.

One of the top three topics I explored over the time was Backlog Refinement. I would often coach team refinement sessions as a means of exploring, explaining, and show good practices for emerging and maintaining a solid backlog.

Often other product owners would attend to observe it as a fishbowl learning experience. While I’ve found no process or recipe for effective refinement, there are a set of patterns that have proven to be useful.

1 Comment

Visible & Invisible Impediments

Comment

Visible & Invisible Impediments

I was in one of our Moose Herd sessions the other day and one of the Moose (or is it Meese) brought up a scenario around impediments. The topic was—how to encourage (inspire, make) the team take ownership of resolving their impediments.

The question elicited a wonderful Herd discussion that felt like it helped the questioner. But as it went on, I began to remember that I’d historically formed a view of 4-Types of Impediments that I hadn’t thought about in a long time or articulated. Thus, this post.

4-Types of Agile Impediments

The first thing is that there might be more than four that some of you can come up with. These are just some that have helped me decide how to describe and act on them uniquely. I like drilling down into different types because it adds contextual flavor to handling the wide variety of challenges we aggregate into the word impediment.

1 - Team Impediments

I think the Scrum Guide refers to these as impediments the Scrum Master should be helping their teams resolve. They are within the span of control of the team and can usually be “struck down” quickly and easily. Or relatively easily.

Comment

Why so much resistance to guardrails?

1 Comment

Why so much resistance to guardrails?

I saw this post on LinkedIn the other day from Damon Poole where he was responding to a question about daily standup. And it made me think of all the debates I see today around folks in the agile community, how do I say it, following the “rules” of the various frameworks, methods, and tactics. 

Now I get it. We’re agile, right? So, we should be inspecting, adapting, experimenting, not becoming dogmatic, etc.

But at the same time, I don’t get the point about all rules being bad. Especially when you’re just beginning (Shu for those familiar with that metaphor) or new to agile ways of working.

Learning to drive

For example, if you’re learning to drive, there are typically rules for learning to and maturing your driving, then the following is a fairly sensible path—

1 Comment

Clean Agile Language

Comment

Clean Agile Language

With an homage to clean language, I was inspired in a Moose Herd session the other day as we explored the damage that agile terminology can do when we’re coaching.

So, the thought that jumped in my mind was the notion of an Agile Coach coaching using Clean Agile Language.

I know what you’re thinking…what is that?

Well, we coach without using any agile terminology. Zero, zilch, nada, none! Inclusive of—

No Scrum terminology

For example—no talk of roles/accountabilities, no events, or sprints.

No XP terminology

For example, no talk about user stories, acceptance criteria, or CI/CD.

No Kanban terminology

For example—no talk of WIP, flow, or SLA’s.

No SAFe terminology

For example—no talk of value streams or trains, SAFe Scrum Masters or other roles, and no talk LACE.

No Agile book or guidance references

For example, stop referencing Agile 2, LeSS, Scrum Guide, Agile Manifesto, or Scrum: The Art of Doing Twice the Work in Half the Time.

You can’t say anything with “agile” or “Agile” in it. And don’t get me started about Agile Coaching terminology—powerful questions, reveal the system, stances, competencies, and wheels, oh my!

Bob, are there any exceptions?

I think I might make an exception for lean language or business agility language, but be super careful with it. And begrudgingly, I must allow an exception for any trainer teaching one of the above methods, frameworks, or approaches.

My Challenge to Myself and other Agile Coaches

First, let me acknowledge that I’m not good at this now. If judged harshly, one might say I suck at it. Given that, I understand how challenging making this shift might be, so I’m going to start with some small experiments—

  1. Can I go for a day of interactions applying clean agile language?

  2. Can I deliver one of my existing presentations applying clean agile language?

  3. Can I have a coaching client conversation, just one, by applying clean agile language?

Then reflect on how that felt for me and its impact on whoever I was talking to.

Wish me luck, everyone. I think I’m in for a bumpy ride…

Stay agile my friends,

Bob.

Comment

Value Stream or Organizational Structure?

Comment

Value Stream or Organizational Structure?

The chicken or the egg

It’s a bit of a chicken and egg problem. Which comes first when transitioning to agile ways of working? Do you re-organize or restructure your organization first – setting teams and roles up for more agile execution? Or do you align your product, application, and workflows into value streams to feed to your teams? What a conundrum.

Ten years ago, I saw most organizations leaning into organizational changes and not putting much thought into the value streams their teams would be working on.

Now it’s flipped a bit, and there’s a strong focus on value streams, probably influenced by SAFe, amongst many factors. And then, the executing organization is composed as an afterthought.

Comment

Call the Agile Tow Truck

1 Comment

Call the Agile Tow Truck

Anthony Mersino is a good friend and colleague of mine, and he asked the following question:

What are the disadvantages of using agile and Scrum? 

And it made me think a bit. Not only about the question but what would be the best way to answer it.

At the risk of offending some, I kept thinking of a car. Putting the pollution aspect to the side for a second, cars are inherently good. They’ve provided transportation to humans for well over a century. They’ve also evolved, becoming safer, more efficient, and more intelligent. They’re even beginning to self-drive, which is an exciting development.

But then I think the primary disadvantages (or problems) are not in the cars themselves, but in the users—us. It’s how we use them that’s the more significant challenge. For example, driving recklessly or under the influence. Not maintaining them safely. Or allowing unlicensed/inexperienced individuals to drive them too soon.

1 Comment

Co-Creation

Comment

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.

Comment