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.
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—
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?
My friend and colleague Mike Hall inspired me with a recent article he shared on Choosing a SAFe Training Partner.
To be clear, I was once an SPC but I fell away from being an active practitioner of SAFe. That being said, I’m often quite opinionated about it, but over time, I have less and less direct experience.
Mike is the opposite. He’s incredibly experienced with it. So, when Mike tells me something from a SAFe perspective, I know that’s not based on opinion but on hard-won experience. And I respect that.
I really appreciated his questions about engaging a SAFe training partner. But I felt there might be some additional questions to add. Not only for a training partner but for a consultant who is prescribing SAFe as the scaling solution for my organization.
My friend & colleague Michael McCalla posted the following advice on LinkedIn:
Am I oversimplifying?
Whenever organizations come to us inquiring about Enterprise (or Business) Agility adoption, here is our advice:
1. Start with a thin horizontal slice across different units of an organization in which people collaborate to deliver value. Call it a value stream if you want:)
2. Engage each layer (Individual Contributors, Teams, Middle Management, and Senior Leadership) for all impacted parties and involve them in the change. Call this a vertical slice if you like:)
I read this article from Roman Pichler that took the perspective of a Product Owner working with an underperforming development team and trying to turn things around. While it’s a good article, it inspired me to look at other reasons that a team might not be performing well. Things outside of the team.
So, instead of the Product Owner looking at and trying to improve the team, what if they changed their focus to underperforming influences that surround the team?
I received this question from my friend Christopher Lee—
I have an existential and abstract question for you. How do we stop line managers from adopting micromanaging behaviors as it relates to artificial deadlines? Can deadlines co-exist with Agile? If so, how can line managers trust their people to make good decisions and execute those decisions autonomously? Is there an organization that exists with this ideal culture that I describe? Thanks.
Can deadlines coexist with “agile”?
I certainly think so. I think deadlines, milestones, delivery dates, etc. are a fundamental part of the real world. I think the key focus points for agile contexts include—
What is it about technology that inspires so much silver bullet syndrome? Or people jumping on bandwagons, hoping to get an easy fix or solution?
In 2014, I wrote a blog post about Bandwagon’s. At the time, I was venting a bit about how folks were modeling themselves after companies in the agile space. And that continues to this day. But another long-term trend is jumping on bandwagon’s related to frameworks.
Scaling frameworks seem to be one of the largest culprits in our space, but there are many others. Let’s explore some of the biggest silver bullets—
