One of my pet peeves, and I think a common source of hatred across most engineering teams, is using old cliché management terms that really do not apply. Or, worse still, they are fundamentally wrong within an agile environment.
Engineering teams are full of uber smart individuals, and I don’t mean the people that cut code, no - I mean your stakeholders, your product owners, team leads; everyone on teams that create value. Most just want to be highly productive, build, and make
things happen. So management speak, even when it is supposed to motivate, can come across as all to fake and blah blah.
Here is a few that you really need to avoid:
“Helicopter view” This means a broad view of what’s going on. Either use “broad” or go with something that really is high level. “Macro view” is the most accurate, or “satellite”.
“Idea shower” Please. This just conjures up wrong thoughts. You are most likely to get lots of giggles and laughs at if you say this in engineering.
“Look under the bonnet” We all know what this means, but really we should be saying “get a deeper technical understanding”. There is another phrase that sadly I hear all too often in financial services, which is a sexist version of this that I rather
not repeat. But if you know anyone who uses that term still, I ask you to please call them out. Do not let anyone, even those at the highest level get away with this.
“All your ducks in a row” The reality is, in an agile world this is just an outdated view. If you wait to get all of your ducks in a row – which can also mean all of your understanding together, then you stand still for a very long time. It’s pretty
much just waterfall, and it simply does not apply in an agile way of working or with an form of iterative approach.
“Don’t let the grass grow too long on this one” Really? Do you mean just get on with it? Engineering teams and agile culture means you need to be transparent and open. If you think something needs to be done faster then call it out and say it.
“Square the circle” I think this one alludes to a culture from the 80s.
Let’s get into a few that I actively believe have no place in an agile culture. People who use these terms do not understand agile, and they have never been in a position to really need to ‘build’ something.
“Cascading relevant information” Firstly, cascading means you want a nice hierarchy, where some are privileged enough to know something and others are not important enough to be in the know. Agile is about transparency. People need to focus on what
matters to them, but if you want to get true alignment of teams, individuals, and drive towards common goals, then be as transparent and open as possible. I’m a strong believer in communicating as much as humanly possible to everyone and doing it in town hall;
let everyone hear directly from you.
“Strategic staircase” You mean an old-fashioned business plan, right? The world has moved on to strategic positioning, product definition, market research, market fit, sales, and more. We need a solid strategy, to make strategic decisions, and form
strategic relationships. We need sales strategy, business strategy. But not a strategy staircase. We need all of these things brought together so that with the right culture, we can execute, learn, iterate, and improve. In agile, everyone needs to know the
strategic direction, and I mean both at a company level and also in terms of what technologies we want to use and why.
“Run it up the flagpole” This means try it out. In agile, we have ‘spikes’ we learn fast and fail fast.
“Put a record on a see who dances” I don’t think I need to say much about this one.
“It’s a marathon, not a sprint” You clearly do not understand agile. We ‘sprint’ all the time, work is broken down into short cycles, in which we sprint, we review, we then move on to the next sprint. I especially do not like this one as it implies
that we should all be taking our time as we move along a lengthy journey. People that use this phrase have never built anything, never innovated, never created something, never been in competition, and never been in agile. Every entrepreneur has felt they
have had to run at a million miles per hour, sprint as hard as possible to make it work. Agile engineering teams get that. They understand it. We sprint because the focus is on delivery, not predictability, not plodding along in some waterfall fashion, its
about delivering product into production, onto customers as soon as possible.