Agile was and is only ever adopted by organizations because of what it promises organizational management, to wit: fine grained observability and control of the software development process. That's it. Take that away and the advantages to Agile crumble, and your boss will be back to breathing down your neck asking for estimates that are really signed-in-blood commitments.
Nobody making the decisions really gives a shit about what's on the manifesto.
False. It was adopted at an organization where I worked because of what it promised management, which was greater productivity. It died because management wanted greater observability (and, I presume, control). There was an impedance mismatch (so to speak) between the agile team and upper management - management wasn't getting their GANTT and PERT charts, and couldn't figure out how to manage the agile team. "Trust us, bro, we're delivering" didn't cut it, though the agile team had a track record of delivering.
> Nobody making the decisions really gives a shit about what's on the manifesto.
That's probably true. But if agile is any good, shouldn't it be good for the organization, not just the programmers? Shouldn't it deliver actual value faster than other approaches? (And in fact, we did. But management just had to have their charts to be sure we were going to...)
And here we go with an entire thread of cynical comments where people assume that the jacked-up Agile implementations they've seen at their own organizations are the only way it ever can be implemented . . .
Unfortunately, doing it well requires managers willing to give up power and developers willing to take the headphones off, go talk to other human beings, and be more proactive than just "I did what I was told." Some companies/teams struggle with these things.
There's nothing wrong with any of that, and a lot that's quite good. Failing to take into account the realities of corporate politics and human psychology when you implement it doesn't make the idea bad. There's no cause so noble that it won't have a few incompetents following it.
What's more, there's a difference between expecting someone to change at a healthy pace as opposed to RIGHT NOW, and saying that they don't need to change at all. Implementing whatever flavor of Agile requires growing pains in the same way that getting physically fit or learning a new skill does. That's healthy. A lot healthier than just sitting on the metaphorical couch with a bowl of Cheetos. Just because a bad personal trainer pushes someone to the point of injury is not evidence that exercise itself is bad.
Your bullet points may (or may not) be fine for commercial software. If you're working on anything governed by the US Federal Acquisition Regulations (FAR), they are a minefield.
- Process compliance is usually baked into the contract. If the contractor stipulates to complying with a process, especially a government process, then it had better be followed and documented
- Documentation is not optional. People move on, get fired, and/or die. Because the s/w works today, it may not tomorrow when MS, Redhat, or whomever push patches
- "Customer collaboration over contract negotiation": Once the contract is in place, it is in place. Customers will _always_ try to add scope and eventually try to direct the individual performers. If you're Firm Fixed Price, you are dead in the water. If you are Cost Plus Fixed Fee (CPFF), you will dilute your profit when you inevitably overrun.
-- Aside: CPFF means the fee is fixed at contract start. If you overrun you may get your costs but the fee stays the same.
And so on.
An even bigger problem is when Lean/Agile gets glommed on to hardware efforts where you can't simply issue a patch every 30 minutes and where you can't have the customer in your day-to-day shorts.
And yet the government is starting to realize that the FARs need a major overhaul if the DOD is to have a prayer of staying competitive in the 21st Century.
You're not describing a critique of Agile so much as you're describing why the government sucks out loud at software.
This characterisation of Agile methodologies is exactly what I’d expect if someone has spent their career in the US govt contracting machine for long enough to have been convinced that it is a remotely good idea.
So, they don't talk to the direct customer (the Product Owner is a proxy), they do the parts of Scrum that they want to do, and there is no proof whatsoever offered. No graphs, no data, no circles and arrows. It sounds like an article written for a Scrum consulting blog which, whaddya whaddaya, it is.
Thanks for the chuckle. Got some new terms to add to our Bullshit Bingo cards.
> There's nothing wrong with any of that, and a lot that's quite good.
There's a lot wrong with it. The problem with even these four foundational principles is: there are a significant % of situations where they are the exact wrong thing to do. Sometimes they are good! Sometimes they are very very bad.
There's no replacement for good management and judgement.
Individuals and interactions over processes and tools — there's a lot of value in having things done in a standard manner. Most of the time, you shouldn't try to be a special flower.
Working software over comprehensive documentation — have you ever seen a team develop themselves into a corner? Or run head first into a pit of real-life complexity? Try implementing USB without comprehensive documentation.
Customer collaboration over contract negotiation — customers will often take advantage of you. Both internal and external customers. The contract helps a lot when the customer is antagonistic.
Responding to change over following a plan — sometimes you should just stick to the plan.
Once again, someone mistakenly assumes that the Agile Manifesto favoring the items on the left magically means ignoring the items on the right. This is a strawman.
"That is, while there is value in the items on
the right, we value the items on the left more." It doesn't say we junk the items on the right.
The complexities of human interaction implies that every system will fail to take into account realities. It's a sociological version of Gödel's incompleteness theorems - either the system is comprehensive and inconsistent, or it's consistent but not comprehensive.
Even so, if every model will fail, which one minimizes the quantity and quality of failure? The solution still seems to be, "let's be aware of our system, whether formal, informal, or somewhere in between, and be conscious designers of our interactions with others in the social organization of software development."
It requires system-level thinking, which at face value, appears to be something that engineering folks would love to sink their teeth into.
At the very least, Agile recognizes that time, features, and effort exist in relation to each other, and that if one[effort] is held constant, social interactions are constrained in a number of important ways.
Which is why Scrum in particular is express about being "purposely incomplete." It's intended to leave wiggle room for people to adapt it to their context.
Unfortunately mediocre people and mediocre organizations take this as a license to fill the gaps with inane bullshit and call it "Scrum" or "Agile," instead of mindfully determining what makes sense in their context.
No no no! Scrum doesn’t get to escape that easily! This is blatant retconning by the Scrum folks. Look at how the scrum guide has changed over the years and you’ll see clear evidence of “fine, we’ll stop being so prescriptive”. And there’s such an essentially-first-party certificate culture associated with Scrum, a completely self-imposed one, that it’s the NORM for Scrum practitioners to be prescriptivist rule-followers lacking any sense of nuance.
The plural of "anecdote" is not "data," and just because you feel strongly about something does not make you an authority on the topic or make it universally true.
> Agile fails to take into account the realities of corporate politics and human (i.e. manager) psychology?
No, it does. Each of the 12 principles calls attention to what developers need to be thinking about when there are no managers. Agile is, in effect, a framework to help you operate without managers. If you already have managers, and they aren't willing to let go, agile was never on the table.
Seems a bit like blame shifting.
Almost any approach will work if perfectly executed by a team with a perfectly matching skill sets, but yeah we have to account for the imperfections (to put it lightly).
> Almost any approach will work if perfectly executed by a team with a perfectly matching skill sets
Will it though? The assumption that any project no matter what it is will always succeed if only the team is right seems naive and at the core of many unreasonable critiques of any framework for project execution.
Failure is a part of the reality of projects, and when executed correctly agile will let you identify and pivot away from failure early. While more ridged frameworks will keep trying to expand resources, extend deadlines until they explored under the load of living up to ever increasing promises they made to justify the growth.
> Unfortunately, doing it well requires managers willing to give up power
Agile is the best micromanagement process there is. Nothing even comes close. I guess there is a fitting LoTR quote here about tempting weak mortals with power.
These levels of micromanagement did not exist before agile. Sure the bosses could try earlier, but there were no tooling or developer self-imposed mindset for the modern worst practice nightmare. And the process is so stiff I wanna cry, but you are gaslighted into being blamed for it, as you "can change it" -- maybe after the next retro though. Just need to align your agile with the other teams agile first.
> And here we go with an entire thread of cynical comments where people assume that the jacked-up Agile implementations they've seen at their own organizations are the only way it ever can be implemented . . .
Probably one of the most agile projects ever was Windows 95. They started by building prototypes of the UI elements they wanted to implement in frickin' Visual Basic, putting them in front of end users, gathering feedback and iterating the next set of UI prototypes, till they converged on the design with the start menu, taskbar, and desktop. About the only thing missing was CI/CD.
But that was Microsoft at the peak of their powers. They had enormous resources and top-tier talent. And they had bet the company on Windows 95; if it flopped, it would be a disaster. It is very, very hard to have the stars align just right, to put together a team that cared enough about the product to actually do this sort of development rather than cargo-cult it to check off some process compliance checkbox.
Yes, I know Windows 95 was a buggy mess. Given the constraints Microsoft was operating under, it's a miracle it worked at all.
Isn't that a bit like a defense of communism though?
"If only people implemented it properly we would all live in paradise".
What matters is how it works in reality, how it incentivizes people and fits in with human nature.
Agile seems to leads to more micromanagement and kafka-esque situations for the majority of software engineers that have to deal with it. If anything it provides a framework for bad managers who are mistrustful of engineers to play far outside of their comfort zone, and suggest childish measures that they wouldn't have dared to dream up on their own.
"And no, this is not a post where I will say “corporate” agile bad or “scrum-but” bad or any other truth worn thin. On the contrary, I’m talking about the “good” Agile that the cheerful but barely experienced in software development coaches will share with you in a two-day training session. I’m talking about one of the huge pillars of modern agile - Scrum itself.
My biggest problem with Agile is that it has become a cult, full of fanatics, dogmas, sermons, its own mythology, and of course the holy inquisition that fiercely fights heretics. I’m a heretic now. In this post I will say a few anti-Agile things, so you may think I have completely embraced the Dark Side, where all the Evil Managers in their suits sit, and where the looming shade of the Great and Terrible Waterfall instills fear into the hearts of the bravest developers."
I think most stressful development environments happen because a manager either isn't familiar with how software development is done (resulting in unreasonable expectations), or the manager isn't communicating expectations upwards effectively.
It's important to understand when the business needs a certain capability, and that should be communicated to the development team (so that the correct scope tradeoffs can be made). Bonus points if the business can communicate the challenge they're trying to solve as opposed to the desired output. (Sometimes, you can start with a simple shell script that relieves the pressures of the business while iterating towards a more feature-rich solution.)
It's also important for the business to understand that the goal is a minimum functional implementation for the capability, and that there are development quality standards that must not be sacrificed to hit a date (bad code is a liability). Also, they have to understand that the date they are communicating to the development team is a "I would like it by this date", not a deadline / guarantee that they'll have that software capability on that date. (As a consumer, I do not set deadlines on a provider in many industries.)
Finally, a manager needs to understand the project health on a regular interval and communicate progress and confidence levels as the project continues. This is usually where expectation management goes wrong -- because the conversation about the work becomes metrics driven (instead of talking about the true story of what is actually happening with the work).
Everyone involved needs to understand the flexibility required to develop a useful, trustworthy product -- and that the time required will vary depending on a number of factors (some knowable / mostly unknowable).
As long as there is trust and expectation management between all stakeholders, a program will usually go positively (and relatively stress free).
(Lessons learned from shipping enterprise software applications & running a development consultancy.)
What are the expectation from a developer in this world? I ask because you listed a bunch of expectations from management and business. But the “system” consists of a third element too - developers! What are your expectations of them, in this idealized set up?
- Transparency about the work.
(Communicate progress without being prompted. Share screenshots & be excited about what you develop!)
- Don't be a hero. (If something is difficult, collaborate with the team and don't go it alone.)
- Be minimal. (Development is an additive process, and it's easy to "chrome plate" a development story. Be minimal and discuss above & beyond opportunities with the team before working on them [or just create a ticket for later discussion].)
- Don't compromise quality. (It's easy to want to skip tests or refactor later, but that carries invisible costs & churn during PRs.)
- Refactor as you go, but don't over do it. (Nobody likes a 1000 line PR. A major refactor means large code change [risk], large review, churn on correcting the PR, long time before feature is merged, ...)
- Solicit feedback when you do want to cut corners. (Explain what the cost is in a quick implementation and why it's a good idea to implement minimally at this phase. Identify ways to mitigate risk / make refactor simple later.)
- Don't overwork. (Developers tend to work harder in off hours and burn themselves out. What they don't realize is that their total contributions to the team go down significantly when they overwork.)
- Be honest. (In a team development setting, some folks will communicate that they're further along on a story than they actually are, with the intention of making up the development effort. This causes overwork -- and the rest of the team can pick up on the dishonesty. I would rather have a member of my team say that they're having an issue with solving a problem [or there are external life factors] than feeling like they have to go it alone.)
- Ask for what you need. (Organizations can easily pull developers into meetings and monopolize their time. Push back and ask for focus blocks.)
- Be candid in retrospectives. (It's the one venue where management is literally asking you what could be better. So many times, people are waiting for someone else to speak before they voice their opinions. Have a conversation with a team member before retro to validate your opinions if you are self-conscious about them.)
- Be candid in 1:1s with your management. (Typical management will lose the developer perspective and rely on feedback to be able to adjust team policies. If there's no feedback, then problems fester.)
--
I get that this list leans on being extroverted -- and that some folks are introverted. It's totally a vulnerable position to put your hard work / opinions out in front of a team for review. It's even more intimidating (impostor syndrome) when you're working with really smart people.
A good manager will mentor their staff on how to follow through on these expectations, and will also actively work to make the team environment a safe space for constructive conversation.
There's a lot more micro nuance depending on the team and business environment, but generally, I believe this is a good starting point.
I’ve worked at a lot of places that said they do Agile but they all really do waterfall with Kanban and call it Agile. Sometimes they do retros too.
If you’re someone that studied Agile and knows how it really works I think you’re in the vast minority.
Admittedly I am not one of those people and haven’t a clue of what “real” Agile looks like. I can’t say that I feel like I’m missing out either.
Where did the word Spike come from? How does it mean “research” (kinda)? Dunno, I’ll google that now I guess. But the word itself feels out of place if you’re not in the Agile mindset.
Seems like it’s from track running terminology for a short, quick sprint. Okay. Why not just call it what it is, just research and/or planning?
Because a spike was supposed to originally represent a short, quick, narrow trip through all levels of the stack from UI to DB to figure out how to approach a given gnarly problem. Narrow and deep . . . looks like a spike.
The scrum guide is also like 16 pages, pretty simple and anyone could read and understand it in 20 minutes.
What's surprising to me is, these processes are actually well defined. But my suspicion is that that's not what sells. No "aspiring manager" will take the "scrum class" if it's ideas are really pretty simple and not that revolutionary and hard to understand.
I have come across so many managers who have had a vague idea seemingly from a few youtube videos (or perhaps a class they took) but they seemingly never had researched in the same way software engineers e.g. read API documentation. The same is true for the waterfall model too these days though. If you fully put in the time and actually research these things as am engineer, a lot of managers will feel threatened and stop that in its tracks.
I've seen this. I interviewed at a place that said they implemented "extreme ownership; it's from a book by some army guy." But they had never read the book or knew the guy's name, or really knew how to explain extreme ownership.
But what they told me was that if you do some work you're on the hook if it fails, which is, IMO, pretty normal. Extreme ownership is a whole different beast.
That kinda told me enough about senior leadership to decline.
35 comments
[ 4.2 ms ] story [ 88.1 ms ] threadNobody making the decisions really gives a shit about what's on the manifesto.
> Nobody making the decisions really gives a shit about what's on the manifesto.
That's probably true. But if agile is any good, shouldn't it be good for the organization, not just the programmers? Shouldn't it deliver actual value faster than other approaches? (And in fact, we did. But management just had to have their charts to be sure we were going to...)
Unfortunately, doing it well requires managers willing to give up power and developers willing to take the headphones off, go talk to other human beings, and be more proactive than just "I did what I was told." Some companies/teams struggle with these things.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
And also to comply with 12 principles listed here in all their 2001 internet glory: https://agilemanifesto.org/principles.html
There's nothing wrong with any of that, and a lot that's quite good. Failing to take into account the realities of corporate politics and human psychology when you implement it doesn't make the idea bad. There's no cause so noble that it won't have a few incompetents following it.
What's more, there's a difference between expecting someone to change at a healthy pace as opposed to RIGHT NOW, and saying that they don't need to change at all. Implementing whatever flavor of Agile requires growing pains in the same way that getting physically fit or learning a new skill does. That's healthy. A lot healthier than just sitting on the metaphorical couch with a bowl of Cheetos. Just because a bad personal trainer pushes someone to the point of injury is not evidence that exercise itself is bad.
- Process compliance is usually baked into the contract. If the contractor stipulates to complying with a process, especially a government process, then it had better be followed and documented
- Documentation is not optional. People move on, get fired, and/or die. Because the s/w works today, it may not tomorrow when MS, Redhat, or whomever push patches
- "Customer collaboration over contract negotiation": Once the contract is in place, it is in place. Customers will _always_ try to add scope and eventually try to direct the individual performers. If you're Firm Fixed Price, you are dead in the water. If you are Cost Plus Fixed Fee (CPFF), you will dilute your profit when you inevitably overrun.
-- Aside: CPFF means the fee is fixed at contract start. If you overrun you may get your costs but the fee stays the same.
And so on.
An even bigger problem is when Lean/Agile gets glommed on to hardware efforts where you can't simply issue a patch every 30 minutes and where you can't have the customer in your day-to-day shorts.
You're not describing a critique of Agile so much as you're describing why the government sucks out loud at software.
https://www.scruminc.com/wp-content/uploads/2015/09/Release-...
Thanks for the chuckle. Got some new terms to add to our Bullshit Bingo cards.
There's a lot wrong with it. The problem with even these four foundational principles is: there are a significant % of situations where they are the exact wrong thing to do. Sometimes they are good! Sometimes they are very very bad.
There's no replacement for good management and judgement.
Individuals and interactions over processes and tools — there's a lot of value in having things done in a standard manner. Most of the time, you shouldn't try to be a special flower.
Working software over comprehensive documentation — have you ever seen a team develop themselves into a corner? Or run head first into a pit of real-life complexity? Try implementing USB without comprehensive documentation.
Customer collaboration over contract negotiation — customers will often take advantage of you. Both internal and external customers. The contract helps a lot when the customer is antagonistic.
Responding to change over following a plan — sometimes you should just stick to the plan.
"That is, while there is value in the items on the right, we value the items on the left more." It doesn't say we junk the items on the right.
Even so, if every model will fail, which one minimizes the quantity and quality of failure? The solution still seems to be, "let's be aware of our system, whether formal, informal, or somewhere in between, and be conscious designers of our interactions with others in the social organization of software development."
It requires system-level thinking, which at face value, appears to be something that engineering folks would love to sink their teeth into.
At the very least, Agile recognizes that time, features, and effort exist in relation to each other, and that if one[effort] is held constant, social interactions are constrained in a number of important ways.
Unfortunately mediocre people and mediocre organizations take this as a license to fill the gaps with inane bullshit and call it "Scrum" or "Agile," instead of mindfully determining what makes sense in their context.
No, it does. Each of the 12 principles calls attention to what developers need to be thinking about when there are no managers. Agile is, in effect, a framework to help you operate without managers. If you already have managers, and they aren't willing to let go, agile was never on the table.
Will it though? The assumption that any project no matter what it is will always succeed if only the team is right seems naive and at the core of many unreasonable critiques of any framework for project execution.
Failure is a part of the reality of projects, and when executed correctly agile will let you identify and pivot away from failure early. While more ridged frameworks will keep trying to expand resources, extend deadlines until they explored under the load of living up to ever increasing promises they made to justify the growth.
Agile is the best micromanagement process there is. Nothing even comes close. I guess there is a fitting LoTR quote here about tempting weak mortals with power.
These levels of micromanagement did not exist before agile. Sure the bosses could try earlier, but there were no tooling or developer self-imposed mindset for the modern worst practice nightmare. And the process is so stiff I wanna cry, but you are gaslighted into being blamed for it, as you "can change it" -- maybe after the next retro though. Just need to align your agile with the other teams agile first.
We are way past agile being nothing but a farce.
I encourage you to read 'the art of agile development' as they do provide some guidance around that.
But if there is micromanaging going on your org has ignored one of the core principles.
"Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done"
There are places Agile is inappropriate or impossible and the book I suggested above calls that out.
While I like agile, I don't think of it as gospel.
But the people I see who bristle at the mention of it have probably only been exposed to the productized version.
Even if the methods don't work the above book provides alternatives that may help.
But I promise you, you haven't experienced an agile development environment if you believe the above.
Micromanaging is the the polar opposite of that collection of values and principles.
Probably one of the most agile projects ever was Windows 95. They started by building prototypes of the UI elements they wanted to implement in frickin' Visual Basic, putting them in front of end users, gathering feedback and iterating the next set of UI prototypes, till they converged on the design with the start menu, taskbar, and desktop. About the only thing missing was CI/CD.
But that was Microsoft at the peak of their powers. They had enormous resources and top-tier talent. And they had bet the company on Windows 95; if it flopped, it would be a disaster. It is very, very hard to have the stars align just right, to put together a team that cared enough about the product to actually do this sort of development rather than cargo-cult it to check off some process compliance checkbox.
Yes, I know Windows 95 was a buggy mess. Given the constraints Microsoft was operating under, it's a miracle it worked at all.
"If only people implemented it properly we would all live in paradise".
What matters is how it works in reality, how it incentivizes people and fits in with human nature.
Agile seems to leads to more micromanagement and kafka-esque situations for the majority of software engineers that have to deal with it. If anything it provides a framework for bad managers who are mistrustful of engineers to play far outside of their comfort zone, and suggest childish measures that they wouldn't have dared to dream up on their own.
My biggest problem with Agile is that it has become a cult, full of fanatics, dogmas, sermons, its own mythology, and of course the holy inquisition that fiercely fights heretics. I’m a heretic now. In this post I will say a few anti-Agile things, so you may think I have completely embraced the Dark Side, where all the Evil Managers in their suits sit, and where the looming shade of the Great and Terrible Waterfall instills fear into the hearts of the bravest developers."
It's important to understand when the business needs a certain capability, and that should be communicated to the development team (so that the correct scope tradeoffs can be made). Bonus points if the business can communicate the challenge they're trying to solve as opposed to the desired output. (Sometimes, you can start with a simple shell script that relieves the pressures of the business while iterating towards a more feature-rich solution.)
It's also important for the business to understand that the goal is a minimum functional implementation for the capability, and that there are development quality standards that must not be sacrificed to hit a date (bad code is a liability). Also, they have to understand that the date they are communicating to the development team is a "I would like it by this date", not a deadline / guarantee that they'll have that software capability on that date. (As a consumer, I do not set deadlines on a provider in many industries.)
Finally, a manager needs to understand the project health on a regular interval and communicate progress and confidence levels as the project continues. This is usually where expectation management goes wrong -- because the conversation about the work becomes metrics driven (instead of talking about the true story of what is actually happening with the work).
Everyone involved needs to understand the flexibility required to develop a useful, trustworthy product -- and that the time required will vary depending on a number of factors (some knowable / mostly unknowable).
As long as there is trust and expectation management between all stakeholders, a program will usually go positively (and relatively stress free).
(Lessons learned from shipping enterprise software applications & running a development consultancy.)
- Transparency about the work. (Communicate progress without being prompted. Share screenshots & be excited about what you develop!)
- Don't be a hero. (If something is difficult, collaborate with the team and don't go it alone.)
- Be minimal. (Development is an additive process, and it's easy to "chrome plate" a development story. Be minimal and discuss above & beyond opportunities with the team before working on them [or just create a ticket for later discussion].)
- Don't compromise quality. (It's easy to want to skip tests or refactor later, but that carries invisible costs & churn during PRs.)
- Refactor as you go, but don't over do it. (Nobody likes a 1000 line PR. A major refactor means large code change [risk], large review, churn on correcting the PR, long time before feature is merged, ...)
- Solicit feedback when you do want to cut corners. (Explain what the cost is in a quick implementation and why it's a good idea to implement minimally at this phase. Identify ways to mitigate risk / make refactor simple later.)
- Don't overwork. (Developers tend to work harder in off hours and burn themselves out. What they don't realize is that their total contributions to the team go down significantly when they overwork.)
- Be honest. (In a team development setting, some folks will communicate that they're further along on a story than they actually are, with the intention of making up the development effort. This causes overwork -- and the rest of the team can pick up on the dishonesty. I would rather have a member of my team say that they're having an issue with solving a problem [or there are external life factors] than feeling like they have to go it alone.)
- Ask for what you need. (Organizations can easily pull developers into meetings and monopolize their time. Push back and ask for focus blocks.)
- Be candid in retrospectives. (It's the one venue where management is literally asking you what could be better. So many times, people are waiting for someone else to speak before they voice their opinions. Have a conversation with a team member before retro to validate your opinions if you are self-conscious about them.)
- Be candid in 1:1s with your management. (Typical management will lose the developer perspective and rely on feedback to be able to adjust team policies. If there's no feedback, then problems fester.)
--
I get that this list leans on being extroverted -- and that some folks are introverted. It's totally a vulnerable position to put your hard work / opinions out in front of a team for review. It's even more intimidating (impostor syndrome) when you're working with really smart people.
A good manager will mentor their staff on how to follow through on these expectations, and will also actively work to make the team environment a safe space for constructive conversation.
There's a lot more micro nuance depending on the team and business environment, but generally, I believe this is a good starting point.
If you’re someone that studied Agile and knows how it really works I think you’re in the vast minority.
Admittedly I am not one of those people and haven’t a clue of what “real” Agile looks like. I can’t say that I feel like I’m missing out either.
Where did the word Spike come from? How does it mean “research” (kinda)? Dunno, I’ll google that now I guess. But the word itself feels out of place if you’re not in the Agile mindset.
Seems like it’s from track running terminology for a short, quick sprint. Okay. Why not just call it what it is, just research and/or planning?
https://agilemanifesto.org/ Read this and you'll know agile in 5m. Forget all the buzzwords.
You won't know scrum or any other monstrosity call agile today, but that's not agile.
What's surprising to me is, these processes are actually well defined. But my suspicion is that that's not what sells. No "aspiring manager" will take the "scrum class" if it's ideas are really pretty simple and not that revolutionary and hard to understand. I have come across so many managers who have had a vague idea seemingly from a few youtube videos (or perhaps a class they took) but they seemingly never had researched in the same way software engineers e.g. read API documentation. The same is true for the waterfall model too these days though. If you fully put in the time and actually research these things as am engineer, a lot of managers will feel threatened and stop that in its tracks.
But what they told me was that if you do some work you're on the hook if it fails, which is, IMO, pretty normal. Extreme ownership is a whole different beast.
That kinda told me enough about senior leadership to decline.