“Agile” Is Not a Noun
Notice that agile methodology offer teams a ton of freedom. We can select from any of the methods/frameworks/approaches and see which, if any, fit our context. An agile approach is one, or a combination, of the many possible lean approaches to software product development. Scrum is just one of the many possibilities.
I saw Dave Thomas’ talk Agile is Dead a couple of years ago. Then, I read his post, Agile is Dead (Long Live Agility). Go to about 10 minutes into the video if you want to see how Dave thinks about agile as an adjective.
We have an “Agile” industry. However, too few people understand what an agile approach is.
Not only is “Agile” not a noun, but it’s also not a proper noun. If you use “Agile” as a way to describe what you do, what does that mean to you? Agile approaches are an umbrella term, not a proper name. You have the number of options to create your successful agile methodology. It’s not one name/term; it’s all the possibilities the principles behind the Manifesto.
Suggested read: Agile project management vs traditional project management
What An Agile Approach Might Be
If you are thinking about an agile transformation or an agile approach for a team or a program, please consider what an agile approach might mean to you. An agile approach helps you release what your customers want when you want to release that value. (See A Working Definition of Agile).
If you don’t need to release too often (that problem determinism again), you might not need an agile approach. That’s not a problem. You don’t have to use a waterfall approach. You can use an iterative or incremental approach if they fit your context/needs better.
If you can identify your business problems and you realize you might need an agile approach, you might decide to ask teams to collaborate as a mob to spread the knowledge and solve problems faster. You might ask teams to limit their WIP so the throughput is faster. You may do this and not require a named agile approach.
When teams move to single-piece flow, they don’t need standups. They might not need planning sessions. They might, every so often, need to look at the roadmap and discuss/create tests/leave breadcrumbs so they don’t forget the risks they need to manage. And, don’t forget the retrospectives.
Also read: How agile certification impact your career?
Don’t Let Process Names Confuse You
I meet a lot of people and teams who tell me they use Scrum. (Sorry to pick on Scrum, but it’s got such name recognition that “everyone” tells me they standardize on it and use it.)
I ask about the retrospectives: How often does the team spend at least 45 minutes reflecting on the past and learning from that work?
“Rarely, because our managers don’t want us to spend the time.” That’s when I explain the role of managers. And, that retrospectives build resilience and learning into the work.
If you’re not retrospecting and learning from past work, you are not using an agile approach. The retrospective is the one practice the Manifesto principles specify. (I recommend you read the principles first, before deciding on a framework/method/approach.)
Read Something
I see too many management teams who want the value of an agile approach and they don’t realize what they’re asking for. I encourage them to read something (maybe more than one something) and discuss it before committing to an agile transformation. Several years ago, I wrote the Minimum Reading List for an Agile Transition.
At that time, I did not understand agile methodologies required a culture transformation. Since then, I commend these books:
- Create Your Successful Agile Project
- Manage Your Project Portfolio
- Agile and Lean Program Management
You don’t have to like my books. There are many other useful books. I happen to be approach-agnostic. I find agile principles much more useful than any specific practice.
Featured article: Amplify agile with DevOps
Managers, please make sure you want what you’re asking for, in terms of an agile transformation. If you don’t want the teams to be autonomous, to collaborate, and to learn with each other, don’t ask for an agile transformation.
As the teams learn, they challenge traditional and hierarchical management. Make sure you want the side effects of an agile approach, not just the supposedly “better, faster, cheaper.”
The more managers read, the more they learn what an agile approach is. And, they might stop asking for “The Agile” which doesn’t make sense. I realize managers have way too much work to do. And, I know managers need to know what they want.
Leave a Comment