Why is Agile so... ANNOYING?

Cast your mind back to your first Agile team. What was the first thing that struck you? The first ANNOYING thing?

= = = = = = = = = = = =

New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"

= = = = = = = = = = = =

That's the question I'm asking in today's brand-new episode. Enjoy!

-------------------
155. Why is Agile so... ANNOYING?
# #DevelopmentThatPays

if pressed I could probably come up with a list of things about agile that are not ideal today I'm going to talk about just one of those and then I want to hear from you hi my name is Gary welcome back to the shed at the bottom of the garden and welcome to development that pays the channel where we actually what is it that we do it's a question I've been musing about over the last few weeks and at the beginning of this week I put up a poll to ask what you thought might be a good tagline for development that pays the options were your agile Survival Guide getting stuff done without losing your mind agile for me Immortals and agile gain without the pain which one I wonder would you have chosen here are the results have to say I'm pretty pleased with how that turned out and interesting isn't it that the top two results both have some element of pain annoyance frustration built into them and it had me thinking back to my first encounter with agile and the first time I experienced some frustration if you've been with me for a while you'll know that I was dropped into an agile team at the BBC a team that was doing scrum although I hadn't heard of that term just yet and my initial impression was one of well Fascination I'd never seen anything like it the daily stand-ups the planning meetings retrospectives think we even had beer from time to time so yeah initially it was all fascinating but that wore off quite quickly and I I shared the frustration that I think many people do expect maybe especially on the coding side I don't know maybe with other roles as well that felt like my time might be better spent doing more coding and doing a little less of these various meetings ceremonies I think they were called back then if you know the full story you'll know that the team split in two one team wanted to do kanban one stage doing scrum and that was when I started to take notice of what both teams were doing to compare and contrast and eventually get to a point where I understood why we would spend time at the beginning of the week planning I understood why we would spend some time at the end of a Sprint doing a retrospective doing a Sprint review the pieces started to fall into place in my mind and that's when I discovered my second frustration and that was when I started to understand I wanted to help other people understand so that they would be less frustrated about some of the stuff they were doing and I found that I was very poor at communicating that long story short that's the origin of development that pays it was me getting my thoughts together on these various things these crazy things that were happening in agile and putting them down in a coherent way that would hopefully be useful to explain to others so that's two or one depending on how you look at it pain points from me but I'm interested to hear from you especially your first one so can you remember back to your very first or second maybe experience with agile and what it was that first annoyed you frustrated you drove you crazy I hope that never happened to you but if it did I'd really love to hear about it let me know in the comments and as you've continued your agile journey I wonder if that pain has been replaced by a different pain perhaps something even more acute if so I'd love to hear about it let me know and then their comments below and I look forward to seeing you next time

[Developmentthatpays]

I want to know: what is about Agile that ANNOYS you? Let me know!

[eAviation-Switzerland]

One is the endless discussion and getting aligned on the time vs complexity in estimations. Although the concept is kind of understandable, it is always a pain to not fall back into the "that-takes-3h"-trap. The other thing is managing the size a sticky note captures. If we would estimate too detailed, you'd have 50 sticky notes, which you would want to start grouping to not loose the overview. So that's when the third problem comes in, people would start working on the tasks from a group - and then not mix up anymore but keep progressing on the tasks from that group. Which then felt like why would you go through all of this pain of creating all these tasks, where in the end just person would burn through those from that group of tasks...

As a summary - it's a constant struggle against the invisible forces trying to loosen or wash out the mental model of the agile processes in your brain, which you are desperately trying to uphold. Again and again you get back to the question - why not just relax and work on the stuff which needs to be done.

[mcquiggd]

Perhaps my biggest fundamental problem with Agile is that it assumes the Business actually knows what they want, and it's "simply a case of discussing that with the developers, getting estimates, measuring developer productivity". In 32 years experience, in multiple industries, startups to global corporates, I have yet to encounter a single company that can coherently and accurately describe their key requirements, and yet the focus is always on how to "ensure the DEVELOPERS deliver". It's rearranging the deck chairs on the Titanic.

Business Analysts are typically spread thin over multiple projects, and are often not capable of giving proper descriptions of features. Sometimes you will encounter a good Product Owner, but in general, nobody seems to have a clear picture, nobody is willing to make decisions and take responsibility. There is typically no direction or management of the overall strategy or prioritisation, just reacting to "urgent sales opportunities" that mean we drop everything and swerve over in another direction, and then swerve back when it turns out to be a mirage.

This alone means the basic tenet of Agile - a prioritised backlog, with clearly defined tasks, falls at the first hurdle.

So the whole thing turns into a merry-go round of meetings to actually get detail that developers need - at one major car manufacturer, they hadn't a clue what they were doing, and kept on coming up with various meetings as sticking plasters - "coarse refinements", "fine refinements", "after-parties", etc. etc. Developers were forced to sit through 2 hour long meetings in which Business stakeholders discussed "what should we be discussing, and who knows anything about those subjects? Shall we book another meeting when we know what we are meeting about?". It all added confusion and noise, and the whole Scrum ceremony became something everybody hated. And then we had the focus-destroying daily standups where people read out Jira to everyone.

You can't estimate something the Business can't describe, you can't prioritise development work when the Business is coming up with high-priority issues on a daily basis; as an aside that particular car manufacturer was "surprised" that they released a new model... which they do every year. You get the picture...

The frustration comes as the technical team is expected to be very highly skilled, cutting edge, up to speed with all latest tech etc. The interview process is as if they are hiring for NASA, requiring deep thought, logic, analysis, testing theories ; but the actual job is working at MacDonalds, dishing out quick fixes with a constant queue of different demands, with the expectation they are delivered in minutes.

In most companies today, it's often probably a better choice to follow Kanban, and try to work with organised people to bring some sanity to a project, than to try to follow Scrum, which tends to set artificial expectations. It's the Business culture and workflow that needs to be focused on, not the development teams.

And then the second problem with Agile - it seems nobody can actually agree on what it is. The amount of time wasted over "you aren't doing Agile right" is just exhausting.

[TimHarris_chasingalion]

For me, it was the disconnect between the agile/scrum team and the immutable demand of business stakeholders (external to the agile team) to ask traditional waterfall questions, even though the answers to those questions were historically embarrassingly-inaccurate.

It is striking to me that Jeff Sutherland, inventor and author of Scrum, was _the boss_ who was driven to scrum by the need to improve team output and performance. Typically, in my experience, corporate agile efforts are driven by end-line workers, often developers or first-level development managers. And it is the executive and senior managers who resist or refuse to buy in to agile/scrum concepts.

If I could wave my magic wand, I'd like to be armed with easy-to-use/reference material (especially short videos) that prove effective at convincing top managers why they need to change their mindset and how agile/scrum can help IF they fully buy in.

[judas]

My experience (which is not about a selling a digital product, but more supportive systems for employees and members) is a lot of cargo culting, Agile (TM), inexperience and not much focus on feedback nor product management.

I’ve heard it from some talk that IT used to keep core business at arms length and they then got used to not working with IT, which also lowered the trust of IT to actually deliver.

So it’s quite a paradigm shift that we now need them close for direction and feedback. As IT we would like to have a business representative taking ownership of the workflows and data which are implemented in the supportive systems. Because we do have users that wants available and functional tools to improve their own capabilities.

My experience is that business representatives and management would rather treat their own IT as an external contractor than working tightly together. Sometimes to such an extent that I wonder why they even have an internal IT department at all.

All I want is to deliver digital services that at least fulfills most of my users’ needs and to an acceptable level that is economically viable and technically feasible.

[DavideTarasconi]

As a consultant, trainer, coach, mentor, etc. I'm annoyed by other people annoyance. Interestingly I'm hearing a lot of people in their early 20s (I'm pushing 40) talking about Agile with extreme annoyance and in the same way we talked (and talk) about waterfall. Agile as something slow and unnecessary, to get rid off. Wow. I don't blame them, when I asked them to describe me what annoys them, they proceed telling me nightmarish stories about how the are forced (forced!) to attend multiple daily meetings every day (because they work on multiple teams). It's madness, they have all the right reasons to be upset.

So I'm not surprised at all that people mention "survival" and "gain without pain". I've been fortunate enough to choose Agile, I was never forced to, and, moreover, never forced to do things that were Agile only in theory. I spend my consulting days fixing what's broken about Agile adoption and busting false myths: this is not what I though I would be doing most of the times, but unfortunately that's what people need.

[fcomarchena]

That "holy grail" of producing a releasable, valuable, DoD-compliant, cute, awesome increment in Sprint 1 still annoys me. Reality is that in Sprint 1 most of the clients don't even get our accounts/permissions provisioned/granted.

[michaelforni]

Coming from a self sufficient "Scrum" Team of 3 (PO, 1 Dev & me as SM) I was ANNOYED a lot was by the dire discovery that ... external dependencies were accepted by PO and Devs in my new team as ... an unavoidable pain in the ****!

It got resolved only when I understood that it was a right (and a duty) of US as a team to address, discuss, resolve and possibly prevent them.

PS: Yes, I know Gary... I wasn't good at story slicing at the time, otherwise... 😉

[steventurner]

My annoyance is with those who are too busy to write a good story, to define acceptance criteria, to come to agreement on a definition of done and then to spent the effort to ensure these completion gates are met.

[tothaa]

We do SAFE framework.
- micromanagement, i sometimes got very simple coding tasks and overseed by 2 people, while I am senior developer 15 years experience.
- 1 to 2 hours long daily standups
- more time spent on planning and talking and drafting future work, multiple demos of plans than actual work
- no clear and consistent definition of when a work is ready; like coding ready in dev env or uat passed or solution patched to stage or prod...
- jira is not always convinient to search stories, no training on expected conventions.


(the good thing is that multiple teams can coordinate in which PI and iteration a certain dependent story is expected to be ready and so we can balance our team's workload)

[Adrikei]

I often don't feel related to what it's been discussed so avidly by a sizeable majority of my peers. (By majority of I mean majority of the people speaking)

[BeckNovaes]

I think a lot of teams get upset because they're trying to adopt Agile to succeed on projects with scope and deadlines. They don't understand the Story Points, they don't refine the work, and they want to be precise in their planning, even if they're doing it wrong. They think Agile is like magic to make the old way of thinking work and that's why they are not annoyed but frustrated.

[sybamunki]

I get annoyed when people avoid good process amd planning by saying ‘oh, but we’re agile, we don’t need to do all that’.

[yahyaseventeen]

Too many stand-ups! Having them every single day can dilute their importance. 3-a-week is more than enough.

[RocektshipMonkey]

My experience is with agile applied to aerospace engineering. I've seen it applied on several different projects and at several different companies and I've never seen it add value for aerospace engineering problems (usually it is actually a huge negative). However, I have seen it work for software -- especially when the software is similar to something that has been done before.