Is not using Agile going to doom my career?

I’m a pretty early in my career as a PM. I like my company, I like my coworkers, and I feel good about the work I’m doing and the industry I’m in.

But the company doesn’t REALLY use agile methodologies. It’s a bit loose, a bit day-by-day, and since I share a dev team across multiple PMs, and there’s a Head of Product, there’s not a ton I can do to change that.

I’m a little worried that it will be hard to sell the skills I’m using here for the next step in my PM career. I’m also a little worried that I’m learning bad habits and forgetting what I learned in my PM courses. Anyone else ever dealt with this?


Agile is hard to define and all companies/leaders do it differently. This is partially because each company is run differently and has different needs/drivers. I would not be so concerned about if they are following what you learned is Agile. Instead, I would pay close attention to what is working and what isn’t.

This will be the experience you can take with you in your career. Take this knowledge and use it when you are in a place to influence change. Things will get changed by nudging in a direction and by showing people “what good looks like”.


No lol most people are not working in environments that are truly agile.


Ask a big4/MBB tech consultant on how many companies actually do agile properly. Hint: almost none.


@BethanyGrey, Didn’t expect MBB/Big4 in the context of Agile. And no, doing Agile ‘by the book’ is not the same as ‘doing it properly’. Teams need to customize Agile to whatever works in their environment.


Why ask big4/mbb specifically. What makes them agile experts in your opinion?


@LawrenceMartin, not necessarily that they’re experts, but they’re brought in to consult with a lot of companies, so they get to see what a lot of orgs are (not) doing.


They consult a lot of companies and get exposure to an infinite amount of them, so they always see behind the scenes. It’s generally a whole lot more than a non-consulting person’s exposure.

If you work at like a bank for 2-3 years, you’ll see how agile works there. Working in consulting for 2-3 years and you’ll see 10x that and have to adapt or teach. Some of them are hired specifically to just get an agile environment set up.


Every company is different.

But Agile as a proper noun, in terms of software development, is not hard to define. It’s 4 values and 12 principles. Everything else is a specific framework (or lack of one).


Actually, agile is better thought of as a verb or adjective, not a noun.

Quote from one of the original writers of the manifesto: “Agile is not a noun, it’s an adjective, and it must qualify something else. “Do Agile Right” is like saying “Do Orange Right.””


@RobMartin, this changes nothing about what I said. When people refer to “Agile”, meaning the Manifesto and its contents, they are referring to a specific thing, not the general sense of “flexible”. There would be no point in using the word in its general sense. There is no “hard to define”, it’s a list of Values and Principles.

If people haven’t bothered to read the manifesto, or the Scrum Guide (or XP, Crystal, Spiral, whatever) then they can certainly talk vague horseshit about “agile”, or “slippery” or whatever vague adjectives they want to use. I’ve seen what those environments look like. Business as usual, lots of buzzwords, and they can’t ship software.


@MartyRoss, I take it you didn’t bother to read any of the links I shared, particularly the one where an author of the agile manifesto explicitly says, “agile is not a noun.” But OK.


What do you mean by not using agile though?

FYI most of FAANG is not particularly adhering to Agile.


@AngelaBlue, We don’t do proper sprints, we just kind of assign tasks and set due dates. Prioritization is mostly improvised. We’re not continuously developing a backlog in any methodical way, and we do very little collaborative discovery or user interviews.

It does generally work okay for us, but I’m just worried when I see PM job posts that require “5+ years cross functional agile product development” that the work I’m doing won’t prepare me to get or excel at those jobs down the line.


Just lie on your next interview. As everyone said, everyone applies Agile differently.

Personally, I’ve never been asked much about the methodology. Usually, it’s just asking if I’ve worked with it/different tools and then just a business case.

Dont worry :slight_smile:


This sounds more agile than the average scrum implementation to me.


@AlbertChappel, You mean scrum, agile is an extremely open-ended approach to development that prioritizes working software over anything else. Do yourself a favor and read the agile manifesto!


That is absolutely not what it says. To quote the agile manifesto directly:

Working software over comprehensive documentation […] That is, while there is value in the items on the right, we value the items on the left

Literally the only thing the agile manifesto says about software is that it’s better to get working code than to spend time documenting theoretical code upfront.


My comment is simply pointing out that agile is a very open-ended approach to software development. Scrum is a very opinionated approach to software development, that may or may not approximate agile depending on how you interpret it. Agile = set of guiding principles. Scrum = specific development process.


In any event, the Scrum Guide is pretty light on opinions. It is strict on roles and ceremonies but outside of that isn’t particularly prescriptive of how the team should go about things. This is a common misperception of Scrum as sold by various consultants, who make it overly complicated. The actual Scrum Guide itself is only 9 pages and says nothing about things like user stories, points estimation, and all the other fluff that people usually assume is required.