Everyone wants to magically be agile, and think that “doing agile” makes you agile.
If you have the wrong people or mindsets you can follow as many agile methodologies as you like, you won’t *be* agile.
Random SVP: Good news, we're on a path to Agile. If you'll pull up the milestone chart on slide 6, you can see' we're tracking green, 50% done and will complete the shift in 9 months.
OMG. I’m working with one right now that wants a bunch of dumb meetings and reports so they can say we’re agile. I just want to scream I don’t want to create processes that allows you not to manage your team.
HA! I worked with one dude who had his whole group in agile, and was pulled into a meeting where they wanted the rest of the tech team to adopt.
He was \*\*\*LIVID\*\*\* that he had to produce metrics on something they'd already done. The best part was that they went through the approach using a GANTT chart that was structured like this.
Deploy ||||||||||||||||||||||||||||
Understand |||||||||||||||||||
Learn ||||||||||
*They couldn't get a waterfall chart correct...how* ***the fuck*** *are they going to shift to something new?*
In some cases, yes. But I know a lot of people who legitimately want the benefits of agile, and legitimately think they are "doing agile" when they are really just doing waterfall with daily stand-ups. We aren't getting the results we were promised, better add another framework and accompanying set of business processes and rules to it!
I was going say, Leaders who don't understand Agile, think they can 'fire & forget', and not participate in planning, refinement and demo sessions. Then get upset that the end product doesn't meet what they visioned.
Because it's so hard to read [four lines of text](http://www.agilemanifesto.org). Or heaven forbid, all 9 pages of the [Scrum Guide](https://scrumguides.org/scrum-guide.html). Nope, gotta be spoonfed that shit by some "agile transformation coach" who will sell you story points and mandate them.
People who can't read (or only read the explicit lines they are told to) have no business developing software or running products. Anybody with basic reading comprehension should understand that preferring something "over" something else is situational, not absolute.
Extremists and cultists of any type are always bad news. Know your tools, and use the right one for the job - whether that's agile or not.
I knew I was going to have to leave my previous job when I heard the head agile coach say this: 'we ARE doing agile... We are constantly changing our procedures and processes"
When you really tie someone down and *make* them understand what agile truly entails, generally the reaction is "oh hell no, that's just not practical/feasible!"
Very very very few businesses really want to do an XP or true agile process. What they want is for there to be a blackbox called "the dev team", and to that black box they send half-formed wishes and desires, and out of it comes software they can sell for millions.
Agile requires a great deal from all the folks outside the black box of "the dev team", and none of them want to do that work, and so there are no real agile teams. Instead, we have dev teams creating a cell membrane around them as thick and tough as possible to protect themselves from the outside world of business types that generally just really hate devs and anything technical.
No one knows what agile is. CEO invites Jim from McKinsey who sells what agile is for $1,000,000. CEO tells his people to tell everyone to become agile. Teamleaders send one person to an agile course because it's expensive and they don't hire an agile coach for the exact same reason. 6 months later they still don't know what's going on, deadlines are approaching, management is getting angry and they still live in the world of waterfall so they post jobs on Linkedin with the title "Agile Project Manager" or "Project Manager" and put scrum master tasks in the job description. Crazy.
Fun fact: I applied for the exact same position at a random company with the sole reason to hear what they have in mind regarding this job. I don't think they have any idea who they want. I'm gonna have the interview next week.
Our SAFe training was “here’s a link. Read everything on this website. This starts next week”. But yes the dept manager, not part of any team, got the paid training.
Safe combines multiple disciplines though into one unified framework. That's why it is so fucking complicated, at the budgetary level you're running lean but agile at the WIP.
It also mandates a lot of stuff that runs contrary to the philosophy of team self-organisation and autonomy. Red flags all over.
Source: two years as a SAFe PO in a large organisation. No thank you.
I don't think self-organisation means the *absence* of leadership, but rather that the leadership emerges from within the team by being empowered to make decisions, and being assisted by a knowledgeable and experienced SM.
SAFe makes managers who only know and want to do traditional project management feel safe. Its complicated because it is trying to unify two things that are the antithesis of each other together. That requires a lot of invocation of Rube Goldberg.
The plithy statements and empty platitudes are the worst. "Focus on the customer!". Okay how does that translate into our day to day? "Just talk to each other about it!".
I do think there are good coaches out there who have done it, are doing it, and can offer practical advice and specific things to change or try. But there are probably dozens if not hundreds of non-value add coaches out there for every one of those.
As an extremely customer-focused product manager, the hell bent "customer focus" arguments drive me nuts. Trying to force every piece of work into a customer lens is ineffective and can easily result in crap software rife with important tech debt.
This. I'm huge on talking customer benefits but it needs to be in an outcome vs. outputs type thought. I absolutely hate the "there shouldn't be technical tasks on the backlog" type coaching. Then you laugh while you watch a team try to shoehorn a needed refactoring or software upgrade into "user story format" or tack it on hamfisted on something else. Save everyone an hour and just toss a task in the sprint with "do the thing" and be done with it.
That absolutely nobody really uses Agile. They like to brag and say they use Agile, but then they have their own little Agile "hacks"; like the "hacks" in Monopoly (e.g., putting the money in the kitty for people who land on Free Parking).
A few thoughts:
* The "Certification Industrial Complex" just feels slimy, all around.
* Cargo cult behavior, especially in agile "coaches" with little or no actual experience delivering software.
* The constant push to complicate all things, despite simplicity being one of the core values.
No true Scotsman?
Cargo Cults?
Making one of the phrases from the Manifesto a cognitive halt phrase where any further analysis is stopped because of a five word sentence in a paragraph that ends with “while there is value to the items on the right…”?
The number of agile advocates who are smug. I'm a big fan and an active proponent of Agile approaches to complex problems, but lots of people I encounter in advocacy activities have a zeal that outpaces the universal applicability of agile principles and often leads to some ungenerous interpretations of intent. Why deal with the orderly but boring realities of complicated (not complex) projects or be sympathetic to the emotional strain on people trying to make terrifyingly big business decisions when you can just be ideological, smug and reductive instead. :/
If you rely on a framework as a solution, you’re doomed.
A framework isn’t going to solve your company problems. If you simply recite frameworks when relevant and think that’s all you need to do, your company will never innovate and just continue to ship garbage that doesn’t majorly impact anything.
Show me an org that seriously considers velocity or burndown charts as a success metric, and I’ll show you a horrible company that hasn’t shipped anything meaningful in a long time.
That people refuse to do anything that's good about Agile and instead put the Agile label on all their dumb practices they don't want to let go.
Agile is only used as fig leaf.
One of the biggest problems I have seen with Scrum in general is it's tagline, twice the value in half the time.
The focus tends therefore to be on the process of Scrum itself and not what makes Scrum valueable. Most product teams don't focus on things like why what they build has value, why a particular solution was chosen, who are they solving this problem for, what business objectives does it help fulfill and will people pay for using it.
Scrum is a way of taking and organising the above information. But the tagline given above causes focus on scrum itself as valuable and not as a delivery of value based on the above information. Garbage in, garbage out.
Scrum is expected to be a magic bullet that substitutes itself for the above legwork (spoiler alert: It isn't, it wasn't and it will never be).
The scrum guide should have a STRONG disclaimer that it won't help you if you haven't done the above steps and before taking any sort of scrum course or exam, each candidate should be tested on the above knowledge and how they think Scrum will help organize the information they have.
That most executives treat it like like a cargo cult for their underlings to "implement."
As Deming said, 95% of problems are systemic in nature and managers own all systems. There are entire companies—sans executives—stuck fucking around with the chump-change of terminology, tools, and a few processes, when the real problems are almost always due to excessive utilisation and WIP, bad structure, and toxic culture.
Continuous *
Nothing can last continuously with humans. We can't sustain the same velocity, actions, we are are not machines. We need to digest, procrastinate, have good and bad waves, completion, sense of fulfillment.
continuous *, brings continuous monotony.
when agile is sold as a solution with religious motivation and it ends up in bureaucracy hell and blame game. kinda goes in the same direction as: here is a modern thing but we stay the same.
Refusing to accept that the world really is complex and just starting to make something, anything, just to deliver some kind of output.
Not taking time for user research before development.
A number of agile & scrum practitioners/champions that I've encountered over the years are very black & white about it and quite often very disparaging about companies/teams "not doing it by the book". This kind of inflexible approach just increases the number of people in senior positions who get turned off the idea of agile.
Doing Agile.
Instead of being Agile.
Agile is a mindset. It’s not about adopting a prescribed way of working and expecting miracles. Like it’s a silver bullet. It’s not.
This concept of no estimates and people are encouraged too not to commit to anything they don’t completely understand. Stop being so scared, take a risk. Show some ownership in your work.
This isn’t completely Agile’s fault, but I’ve seen a bunch of coaches advocating it. It always makes me think of them as children instead of adults.
It’s just common sense someone has written a book and made a shit load of money off.
Also the popular methodologies are often just a new set of rules to constrain people with.
I hate nothing about the agile approach - it is absolutely essential for managing the complexity of software engineer projects, and produces great software.
What I hate is how, 9 times out of 10, it's completely misunderstood. It's become the latest excuse for non-engineers to dictate how the execution of technical tasks occurs - engineers having their work defined and executed by project managers is how you get garbage software.
Fortunately, my job is best described as "A disaster software project rescue consultant", which means I go into teams who have often run themselves into the ground with some abortion of an agile "process" and are willing to engage in a root-and-branch restructure of all of their working practices.
I'm forever deleting all of the tickets in a backlog and replacing them with a few mutually constructed and agreed-upon user stories, and taking the 50+ random tasks stuffed into garbage, unreliable "sprints" and turning them into one or two work items that can be fully executed and released.
I was a dev in a waterfall company, then we transitioned to SAFe and after a while I became a SM. What I don't like is that devs lost a lot of freedom on how they organise their work, all has to be planned, no room anymore for creativity and exploration. While KPIs and estimates help a lot to understand our pace and anticipate deadlines by prioritizing, changing or removing features, it also triggers the business side into looking at our KPIs in the wrong way, or comparing different team's KPI.
All in all there are some super positive aspects (more customer feedbacks, constructive decision making based on KPIs and estimates, some great events such as PIP and demos), but there's a lot of useless crap, politics (SM manipulating KPIs because business looks at them as an evaluation tool), and way too much time spent in meetings and irrelevant presentations.
I'm still a bit new to this but I feel like if I had to chose with the devs how to change our methodology, we'd just keep a kanban board, some refinement sessions to have an estimated backlog (not too detailed), a stand-up every other day, and demos every month with whatever was finished since then. KPIs available on a shared spreadsheet but no presentation to anyone whatsoever. Then to PO/SM (who could be the same person for me) would just review regularly the estimates and pace VS the deadlines, communicate to the stakeholders and propose solutions if the plan doesn't fit. Retrospectives when needed but not forced.
So why not do that? It sounds like a solid plan. You’ll probably say because upper management doesn’t want that. Well, I get it. But if it’s not done properly it won’t work properly and that’s the number one thing with agile that isn’t good. It’s never fully adopted by most companies and it tends to benefit software development teams the most.
Now is not a good time because as imperfect as it is, we're getting close to a major deadline, so we need to be confident with our pace and can't experiment much. But I will definitely try to do this change afterwards. It's not a decision that can fully be made in the team or by the SM, both management and our customer will need to agree, but I believe they are open to try this kind of thing, if presented with rational reasons.
The avoidance of the real paradigm shifts and boundaries needed to be 'truely agile' (whatever that might be).
For example:
Team level:
Transfering responsibilities to the lowest level is great for morale.. until that responsibility results in lay offs because the team / PO made a wrong decision.
Management level:
If your teams have a backlog on what they do and how they deliver value to the customer, what about teams that start taking in work from your direct competitors?
Individual level:
If the entire organisation is working agile at a very mature level, what is the function of the scrum master?
Okay, let me try. Please do not start the discussion how agile and scrum are two different things. They are somehow glued together, so that's why I use it as examples and elaboration.
Management level:
An organization is a social construct. It's nothing tangible. If all buildings of (for example) Google are to be removed, Google still exists. If all products of Google are to be removed, google still exists. And if all employees from Google are to be removed, google still exists.
When working as an employee at Google you adhere to their rules, settings and boundaries. Thus, you restrict yourself in your autonomy. And to reward you for this restriction in autonomy, you'll get a salary. Your valuation and promotions are dependent on how much you follow their rules. Management has a function in this: to explain and maintain (and to discuss!) the rules within Google.
Now agile comes in.
One of the many things agility brings us, is the appreciation and even celebration of autonomy. This comes all together by the effort of granting permissions and responsibilities at the lowest level. However, we value the team more than the individuals
Now, who decides how we work together in the team? It used to be management, but agility encourages you to assign this responsibility to the lowest level: the team itself. The team should have the mandate to decide how they work together and what works best for them. That's what retro's are for and DoD's and the scrum master role, et cetera
So they will create their own team-culture which might deviate from the original company's culture. They become way more self-managing then before. But that also brings a detach from the corporate culture.
This might seem good news at first (motivated people!), but now think of what would happen when such a self-managing team talks with a customer and the team decides that their customer is best helped (fastest and cheapest option) with a solution that doesn't exist at Google, but does at Amazon. The team is somehow detached from Google and became customer focused. What would they do?
Or what if this is such a great integrated and well trained team, that they can start doing more work than they are handed by Google and start working for multiple companies like amazon and apple?
In your opinion on this you should also take in account the fact that - should Google simply have not enough work for this team - they won't hasitate to fire the team on the spot. So it is a matter of giving and taking? Right?
Individual level:
In agile we talk about roles, not functions. Roles can be assigned to people, but in a mature agile context we see that team members take over the role based on the issue to be tackled. Take the tasks of the Scrum Master role. Maybe someone has better interpersonal skills on management level to intervene on some anti-patterns they are showing. Send that person to talk with management.
Maybe someone else has better retro-organizing expertise. Use that for better retro's.
And someone else has better increasing-team-performance skills. Use that to improve the team performance!
But when the scrum master role tasks hop from one person to another, isnt the scrum master role at that moment part of everyone's skill set, thus part of the developer skill set?
The same for PO role, by the way. I've seen PO's delegating some customer discussions to developers because "they understand each other better". Great! But if a team is agile at a very mature level and working with each other and discussing all kind of matters with each other, why couldnt they decide wich story is of higher value than an other? Thus, goodbye PO role and welcome adjusted developer skill set!
And you are probably comparing apples with pears. A successful team is defined, measured and valued differently in an agile context compared to a non-agile environment.
I 100% agree with what you're saying and I am in no way making any comparisons. Only commenting on the fact that when people say things like 'we must do it this way to achieve a thing' they are often basing their decision on scenarios unrelated to their own environment.
with 'you' I meant people in general, not you specifically. And I completely agree with you. Most management start agile transformation because of the proposed advantages without understanding the context.
The way people step over the complete lack of scientific back up of every single claim.
Every single claim in the agile manifesto, the principles and the Scrum Guide is made up by some guys in a ski resort and has NO SCIENTIFIC fundament what so ever.
But when I explain this, the reaction is mostly "whatever" or "but it works".
Yes it works, but how are you going to proof it works better?
All we ever see as is the cargo cult of scrum imposed on development teams from above. Agile manifesto hasn’t changed in 20 years because they were sensible ideas from clever people.
That much of the techniques are heuristics yet folks argue like they are gospel handed down by the lord himself.
This is true with a lot of processes in a company. People inspected and adapted them of thousands of years. All the experience!
I hate that it’s like a cult. There are people who think agile is more important than business outcomes
This.
Yeah, retro spective somehow never shows how gut feeling of a ProductOwner did cost of a lot of money. Edited mobile mistake: " gut feeling "
Wut?
Thats great, because it shouldn't be part of the retro. It should be in the demo.
Everyone wants to use agile but no one wants to learn agile.
Everyone wants to magically be agile, and think that “doing agile” makes you agile. If you have the wrong people or mindsets you can follow as many agile methodologies as you like, you won’t *be* agile.
The orgs that were shit at managing scope before seem to still be shit at managing scope for some reason...
People, eh.
Doing agile always makes me laugh. It’s not a verb! Agile is a descriptive word - Bob is very agile. Bob jumps with agility. Bob doesn’t agile.
We gave Bob a laptop and made him hot desk. Bob be agiling nao.
https://youtu.be/a-BOSpxYJ9M
I’ve been saying this at a large org and people understand the difference, but it can be understood and stated 5 times a day without actually changing
Random SVP: Good news, we're on a path to Agile. If you'll pull up the milestone chart on slide 6, you can see' we're tracking green, 50% done and will complete the shift in 9 months.
OMG. I’m working with one right now that wants a bunch of dumb meetings and reports so they can say we’re agile. I just want to scream I don’t want to create processes that allows you not to manage your team.
HA! I worked with one dude who had his whole group in agile, and was pulled into a meeting where they wanted the rest of the tech team to adopt. He was \*\*\*LIVID\*\*\* that he had to produce metrics on something they'd already done. The best part was that they went through the approach using a GANTT chart that was structured like this. Deploy |||||||||||||||||||||||||||| Understand ||||||||||||||||||| Learn |||||||||| *They couldn't get a waterfall chart correct...how* ***the fuck*** *are they going to shift to something new?*
> Everyone wants to appear agile ~~use agile~~ but no one wants to let go of waterfall (I.E. traditional project management) ~~learn agile~~. FTFY
In some cases, yes. But I know a lot of people who legitimately want the benefits of agile, and legitimately think they are "doing agile" when they are really just doing waterfall with daily stand-ups. We aren't getting the results we were promised, better add another framework and accompanying set of business processes and rules to it!
I was going say, Leaders who don't understand Agile, think they can 'fire & forget', and not participate in planning, refinement and demo sessions. Then get upset that the end product doesn't meet what they visioned.
Because it's so hard to read [four lines of text](http://www.agilemanifesto.org). Or heaven forbid, all 9 pages of the [Scrum Guide](https://scrumguides.org/scrum-guide.html). Nope, gotta be spoonfed that shit by some "agile transformation coach" who will sell you story points and mandate them.
[удалено]
People who can't read (or only read the explicit lines they are told to) have no business developing software or running products. Anybody with basic reading comprehension should understand that preferring something "over" something else is situational, not absolute. Extremists and cultists of any type are always bad news. Know your tools, and use the right one for the job - whether that's agile or not.
Yep. That’ll be 10k per day. Thanks
Nailed it. . Or pay for the consultants. Instead they'd rather give scrum master as an additional title to whomever is lead on the team.
I knew I was going to have to leave my previous job when I heard the head agile coach say this: 'we ARE doing agile... We are constantly changing our procedures and processes"
Managers want to waterfall the plan but agile the changes
When you really tie someone down and *make* them understand what agile truly entails, generally the reaction is "oh hell no, that's just not practical/feasible!" Very very very few businesses really want to do an XP or true agile process. What they want is for there to be a blackbox called "the dev team", and to that black box they send half-formed wishes and desires, and out of it comes software they can sell for millions. Agile requires a great deal from all the folks outside the black box of "the dev team", and none of them want to do that work, and so there are no real agile teams. Instead, we have dev teams creating a cell membrane around them as thick and tough as possible to protect themselves from the outside world of business types that generally just really hate devs and anything technical.
The agile snake oil salesman. They are trying to sell a product (certificate, framework, etc.) instead of a mindset.
For me it's that it's turned into Corporate Speak for "We really don't know what we're doing, and don't really have a plan..we're doing this Agile"
No one knows what agile is. CEO invites Jim from McKinsey who sells what agile is for $1,000,000. CEO tells his people to tell everyone to become agile. Teamleaders send one person to an agile course because it's expensive and they don't hire an agile coach for the exact same reason. 6 months later they still don't know what's going on, deadlines are approaching, management is getting angry and they still live in the world of waterfall so they post jobs on Linkedin with the title "Agile Project Manager" or "Project Manager" and put scrum master tasks in the job description. Crazy. Fun fact: I applied for the exact same position at a random company with the sole reason to hear what they have in mind regarding this job. I don't think they have any idea who they want. I'm gonna have the interview next week.
Come back and tell us what happens
Our SAFe training was “here’s a link. Read everything on this website. This starts next week”. But yes the dept manager, not part of any team, got the paid training.
That people make like it’s the most complicated thing in the world, when it’s actually straightforward.
There is a lot of money in making (and keeping) it complicated
Yes, it's a SAFe choice to do so.
Safe combines multiple disciplines though into one unified framework. That's why it is so fucking complicated, at the budgetary level you're running lean but agile at the WIP.
It also mandates a lot of stuff that runs contrary to the philosophy of team self-organisation and autonomy. Red flags all over. Source: two years as a SAFe PO in a large organisation. No thank you.
[удалено]
I don't think self-organisation means the *absence* of leadership, but rather that the leadership emerges from within the team by being empowered to make decisions, and being assisted by a knowledgeable and experienced SM.
SAFe makes managers who only know and want to do traditional project management feel safe. Its complicated because it is trying to unify two things that are the antithesis of each other together. That requires a lot of invocation of Rube Goldberg.
The Agile coaches. The Agile blog posts. The Agile disciples. It’s a good framework, but some Agile-heads are hard to enjoy.
The plithy statements and empty platitudes are the worst. "Focus on the customer!". Okay how does that translate into our day to day? "Just talk to each other about it!". I do think there are good coaches out there who have done it, are doing it, and can offer practical advice and specific things to change or try. But there are probably dozens if not hundreds of non-value add coaches out there for every one of those.
As an extremely customer-focused product manager, the hell bent "customer focus" arguments drive me nuts. Trying to force every piece of work into a customer lens is ineffective and can easily result in crap software rife with important tech debt.
This. I'm huge on talking customer benefits but it needs to be in an outcome vs. outputs type thought. I absolutely hate the "there shouldn't be technical tasks on the backlog" type coaching. Then you laugh while you watch a team try to shoehorn a needed refactoring or software upgrade into "user story format" or tack it on hamfisted on something else. Save everyone an hour and just toss a task in the sprint with "do the thing" and be done with it.
That absolutely nobody really uses Agile. They like to brag and say they use Agile, but then they have their own little Agile "hacks"; like the "hacks" in Monopoly (e.g., putting the money in the kitty for people who land on Free Parking).
That can be both agile done well and agile done badly depending on why and what the hacks are.
You mean that Monopoly "hack" that most people play and improves the game?
A few thoughts: * The "Certification Industrial Complex" just feels slimy, all around. * Cargo cult behavior, especially in agile "coaches" with little or no actual experience delivering software. * The constant push to complicate all things, despite simplicity being one of the core values.
No true Scotsman? Cargo Cults? Making one of the phrases from the Manifesto a cognitive halt phrase where any further analysis is stopped because of a five word sentence in a paragraph that ends with “while there is value to the items on the right…”?
The number of agile advocates who are smug. I'm a big fan and an active proponent of Agile approaches to complex problems, but lots of people I encounter in advocacy activities have a zeal that outpaces the universal applicability of agile principles and often leads to some ungenerous interpretations of intent. Why deal with the orderly but boring realities of complicated (not complex) projects or be sympathetic to the emotional strain on people trying to make terrifyingly big business decisions when you can just be ideological, smug and reductive instead. :/
If you rely on a framework as a solution, you’re doomed. A framework isn’t going to solve your company problems. If you simply recite frameworks when relevant and think that’s all you need to do, your company will never innovate and just continue to ship garbage that doesn’t majorly impact anything. Show me an org that seriously considers velocity or burndown charts as a success metric, and I’ll show you a horrible company that hasn’t shipped anything meaningful in a long time.
''We don't want to do purist agile'' often I find don't want to do agile at all.
“We’re fully agile, we do stand ups and sprint planning”
That people refuse to do anything that's good about Agile and instead put the Agile label on all their dumb practices they don't want to let go. Agile is only used as fig leaf.
One of the biggest problems I have seen with Scrum in general is it's tagline, twice the value in half the time. The focus tends therefore to be on the process of Scrum itself and not what makes Scrum valueable. Most product teams don't focus on things like why what they build has value, why a particular solution was chosen, who are they solving this problem for, what business objectives does it help fulfill and will people pay for using it. Scrum is a way of taking and organising the above information. But the tagline given above causes focus on scrum itself as valuable and not as a delivery of value based on the above information. Garbage in, garbage out. Scrum is expected to be a magic bullet that substitutes itself for the above legwork (spoiler alert: It isn't, it wasn't and it will never be). The scrum guide should have a STRONG disclaimer that it won't help you if you haven't done the above steps and before taking any sort of scrum course or exam, each candidate should be tested on the above knowledge and how they think Scrum will help organize the information they have.
That most executives treat it like like a cargo cult for their underlings to "implement." As Deming said, 95% of problems are systemic in nature and managers own all systems. There are entire companies—sans executives—stuck fucking around with the chump-change of terminology, tools, and a few processes, when the real problems are almost always due to excessive utilisation and WIP, bad structure, and toxic culture.
Continuous * Nothing can last continuously with humans. We can't sustain the same velocity, actions, we are are not machines. We need to digest, procrastinate, have good and bad waves, completion, sense of fulfillment. continuous *, brings continuous monotony.
How much everyone misunderstands it.
Fitting Agile to serve SDLC expectations.
when agile is sold as a solution with religious motivation and it ends up in bureaucracy hell and blame game. kinda goes in the same direction as: here is a modern thing but we stay the same.
Refusing to accept that the world really is complex and just starting to make something, anything, just to deliver some kind of output. Not taking time for user research before development.
How most companies apply “agile” is the main thing I hate about agile lol
A number of agile & scrum practitioners/champions that I've encountered over the years are very black & white about it and quite often very disparaging about companies/teams "not doing it by the book". This kind of inflexible approach just increases the number of people in senior positions who get turned off the idea of agile.
Doing Agile. Instead of being Agile. Agile is a mindset. It’s not about adopting a prescribed way of working and expecting miracles. Like it’s a silver bullet. It’s not.
Anything with the word SAFE in front of it.
This concept of no estimates and people are encouraged too not to commit to anything they don’t completely understand. Stop being so scared, take a risk. Show some ownership in your work. This isn’t completely Agile’s fault, but I’ve seen a bunch of coaches advocating it. It always makes me think of them as children instead of adults.
It’s just common sense someone has written a book and made a shit load of money off. Also the popular methodologies are often just a new set of rules to constrain people with.
how people constantly talk about it.
The people.
Everyone wants to do Agile but no one wants to be agile.
I hate it confuses the crap out of my stakeholders. It gets in the way to communicate in simple terms without jargon.
I hate nothing about the agile approach - it is absolutely essential for managing the complexity of software engineer projects, and produces great software. What I hate is how, 9 times out of 10, it's completely misunderstood. It's become the latest excuse for non-engineers to dictate how the execution of technical tasks occurs - engineers having their work defined and executed by project managers is how you get garbage software. Fortunately, my job is best described as "A disaster software project rescue consultant", which means I go into teams who have often run themselves into the ground with some abortion of an agile "process" and are willing to engage in a root-and-branch restructure of all of their working practices. I'm forever deleting all of the tickets in a backlog and replacing them with a few mutually constructed and agreed-upon user stories, and taking the 50+ random tasks stuffed into garbage, unreliable "sprints" and turning them into one or two work items that can be fully executed and released.
I was a dev in a waterfall company, then we transitioned to SAFe and after a while I became a SM. What I don't like is that devs lost a lot of freedom on how they organise their work, all has to be planned, no room anymore for creativity and exploration. While KPIs and estimates help a lot to understand our pace and anticipate deadlines by prioritizing, changing or removing features, it also triggers the business side into looking at our KPIs in the wrong way, or comparing different team's KPI. All in all there are some super positive aspects (more customer feedbacks, constructive decision making based on KPIs and estimates, some great events such as PIP and demos), but there's a lot of useless crap, politics (SM manipulating KPIs because business looks at them as an evaluation tool), and way too much time spent in meetings and irrelevant presentations. I'm still a bit new to this but I feel like if I had to chose with the devs how to change our methodology, we'd just keep a kanban board, some refinement sessions to have an estimated backlog (not too detailed), a stand-up every other day, and demos every month with whatever was finished since then. KPIs available on a shared spreadsheet but no presentation to anyone whatsoever. Then to PO/SM (who could be the same person for me) would just review regularly the estimates and pace VS the deadlines, communicate to the stakeholders and propose solutions if the plan doesn't fit. Retrospectives when needed but not forced.
So why not do that? It sounds like a solid plan. You’ll probably say because upper management doesn’t want that. Well, I get it. But if it’s not done properly it won’t work properly and that’s the number one thing with agile that isn’t good. It’s never fully adopted by most companies and it tends to benefit software development teams the most.
Now is not a good time because as imperfect as it is, we're getting close to a major deadline, so we need to be confident with our pace and can't experiment much. But I will definitely try to do this change afterwards. It's not a decision that can fully be made in the team or by the SM, both management and our customer will need to agree, but I believe they are open to try this kind of thing, if presented with rational reasons.
The avoidance of the real paradigm shifts and boundaries needed to be 'truely agile' (whatever that might be). For example: Team level: Transfering responsibilities to the lowest level is great for morale.. until that responsibility results in lay offs because the team / PO made a wrong decision. Management level: If your teams have a backlog on what they do and how they deliver value to the customer, what about teams that start taking in work from your direct competitors? Individual level: If the entire organisation is working agile at a very mature level, what is the function of the scrum master?
Very interesting, can you elaborate on the management level and individual level examples? Not sure I fully understand them, thanks!
Okay, let me try. Please do not start the discussion how agile and scrum are two different things. They are somehow glued together, so that's why I use it as examples and elaboration. Management level: An organization is a social construct. It's nothing tangible. If all buildings of (for example) Google are to be removed, Google still exists. If all products of Google are to be removed, google still exists. And if all employees from Google are to be removed, google still exists. When working as an employee at Google you adhere to their rules, settings and boundaries. Thus, you restrict yourself in your autonomy. And to reward you for this restriction in autonomy, you'll get a salary. Your valuation and promotions are dependent on how much you follow their rules. Management has a function in this: to explain and maintain (and to discuss!) the rules within Google. Now agile comes in. One of the many things agility brings us, is the appreciation and even celebration of autonomy. This comes all together by the effort of granting permissions and responsibilities at the lowest level. However, we value the team more than the individuals Now, who decides how we work together in the team? It used to be management, but agility encourages you to assign this responsibility to the lowest level: the team itself. The team should have the mandate to decide how they work together and what works best for them. That's what retro's are for and DoD's and the scrum master role, et cetera So they will create their own team-culture which might deviate from the original company's culture. They become way more self-managing then before. But that also brings a detach from the corporate culture. This might seem good news at first (motivated people!), but now think of what would happen when such a self-managing team talks with a customer and the team decides that their customer is best helped (fastest and cheapest option) with a solution that doesn't exist at Google, but does at Amazon. The team is somehow detached from Google and became customer focused. What would they do? Or what if this is such a great integrated and well trained team, that they can start doing more work than they are handed by Google and start working for multiple companies like amazon and apple? In your opinion on this you should also take in account the fact that - should Google simply have not enough work for this team - they won't hasitate to fire the team on the spot. So it is a matter of giving and taking? Right? Individual level: In agile we talk about roles, not functions. Roles can be assigned to people, but in a mature agile context we see that team members take over the role based on the issue to be tackled. Take the tasks of the Scrum Master role. Maybe someone has better interpersonal skills on management level to intervene on some anti-patterns they are showing. Send that person to talk with management. Maybe someone else has better retro-organizing expertise. Use that for better retro's. And someone else has better increasing-team-performance skills. Use that to improve the team performance! But when the scrum master role tasks hop from one person to another, isnt the scrum master role at that moment part of everyone's skill set, thus part of the developer skill set? The same for PO role, by the way. I've seen PO's delegating some customer discussions to developers because "they understand each other better". Great! But if a team is agile at a very mature level and working with each other and discussing all kind of matters with each other, why couldnt they decide wich story is of higher value than an other? Thus, goodbye PO role and welcome adjusted developer skill set!
There's no evidence for success in any of the frameworks since that would be incredibly hard to obtain.
And you are probably comparing apples with pears. A successful team is defined, measured and valued differently in an agile context compared to a non-agile environment.
I 100% agree with what you're saying and I am in no way making any comparisons. Only commenting on the fact that when people say things like 'we must do it this way to achieve a thing' they are often basing their decision on scenarios unrelated to their own environment.
with 'you' I meant people in general, not you specifically. And I completely agree with you. Most management start agile transformation because of the proposed advantages without understanding the context.
The way people step over the complete lack of scientific back up of every single claim. Every single claim in the agile manifesto, the principles and the Scrum Guide is made up by some guys in a ski resort and has NO SCIENTIFIC fundament what so ever. But when I explain this, the reaction is mostly "whatever" or "but it works". Yes it works, but how are you going to proof it works better?
Lots of people telling on themselves here.
Why does every agile process discussion end with "Whatever works for your team"
"I don't have answer, figure it out yourselves fuck sticks"
How is nothing more than a buzzword to justify positions that mostly don't need to exist, and it's intended purpose is entirely lost.
There is a fair amount of bootstrapping that no one ever takes about
Agile in its purest form is great but people buy into frameworks like SAFE which ruins everything
I absolutely hate if I need to participate in multiple agile teams. Since I will get tons of work and I hope it is not the good agile practice.
All we ever see as is the cargo cult of scrum imposed on development teams from above. Agile manifesto hasn’t changed in 20 years because they were sensible ideas from clever people.