Why is Agile so... ANNOYING?
HTML-код
- Опубликовано: 2 июн 2024
- 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"
→ www.developmentthatpays.com/w...
= = = = = = = = = = = =
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
• Why is Agile so... ANN... 
Хобби
I want to know: what is about Agile that ANNOYS you? Let me know!
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.
I feel your pain!
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.
You had likes on your comment before I got here: you seem to have struck a cord! I've just read it three times... couldn't find anything I didn't agree with... and now I want to make a video in which I just read the entire thing verbatim!
@@Developmentthatpays Feel free... 😉
@@Developmentthatpays I'll add a further comment: Agile is always explained in terms of a simple problem domain, with a clearly defined Business Process that leads to the creation of the Backlog, and then Agile magically kicks in from that point. It makes sense to take this approach for a basic explanation, but it is unrealistic; so people have a presumption that "following Agile" will address all the historical problems they have encountered, if they "do it right". But it won't.
A more realistic scenario is something along the lines of:
Business: "Part number 123, is subject to a new tax in market XYZ, to be applied from 15th July, if the total value of The Product is over 1000 Groats."
So the Refinement conversation becomes:
Dev Team: (Looks at the code...) "How does that affect the existing rebates we offer to corporate customers for the Product when the value is over 900 Groats in all markets? Do we calculate that before or after that new tax in market XYZ? Should the taxable threshold be before the rebate? What about existing orders that have been received that are manufactured after that date?"
Business: "That wasn't discussed. But it has to be in place before the Product launch at the trade show next Thursday"
Dev Team: "So... what are the actual business rules? Do you have some sample calculations we can refer to, and base our tests on?"
Business: "No, I'll see if I can get more information"
Product Owner: "Well we'll include it as it has a Cannot Fail Date, but mark it as more information required"
Dev Team works on the Jira tickets that seem to make sense, while waiting for more information on the ones that don't make sense, but were snuck into the Backlog as it's a Business Priority... later in the Sprint:
Business: "So how are we doing for the trade show tomorrow? Is everything ready with that new tax for part number 123?"
Dev Team: "What were the business rules for that? It's still not clear."
Product Owner: "Let's jump into a meeting..."
It ends up as a Hotfix, never to be properly addressed - or even documented outside the code - as Technical Debt is always deprioritised. Everyone moves onto the next Sprint, until a large customer notices it has been overcharged... and that is then logged as a Bug - "you're calculating the price wrong", which then needs Investigation Under Pressure, as nobody agreed and documented the business rules; it's only in the code.
As I say, much more emphasis needs to be put on the roles and responsibilities of the Business side in Agile - organisation of meetings, decision making, and creation of requirements, writing documents. I have encountered very few Business people that were ever given formal training in their role, let alone Scrum or similar.
While it's all very well to say "unless it is properly defined, it doesn't go into the Sprint", the reality is that usually doesn't happen unless you have a very strong-willed Product Owner; and Business doesn't tend to like those, as then they have to think a lot, and commit to decisions.... and they have so many meetings to go to...
When you repeat the above enough times, you have a failed project that needs an expensive rewrite - and the dev team takes the blame, due to those "Bugs", reinforcing the idea that Agile has to focus on developers...
@@Developmentthatpays I might actually turn my two comments on this thread into a LinkedIN post, just so you know... would it be ok to mention your video?
@@mcquiggd - Absolutely!
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.
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.
It's (too) often about busting false myths. Great comment.
Hi Davide I'm in the same role as you are (although I've got an extra 20 years on you nearing 65). I was about to comment pretty much exactly what you said. I for sure am seeing developers in the beginning stages of their career hating on Agile. If they only knew what that "bad old days" were like they might have a different opinion. That said there is plenty to still not like about how Agile is being practiced in most shops today. For example right in your comment about developers being on multiple teams, red flag! Similarly I can't even count the number of times I have heard "that is your number one priority" in stand up to the *same* person for multiple issues. Folks, you can only have ONE number one priority! It's right in the name!
If I had to pick a single pet peeve with Agile practice today it would be Scrum masters who are pedantic. The reason I like Gary's site so much is that he is one of the few people who want Agile to be practiced, but see that it has some problems and hey what can we do to fix those. I believe the root cause of this are Scrum masters (or so called) that have not had their boots on the ground as developers. I don't think Program Managers make good Scrum masters, and (controversially maybe) I don't think there should be a Program Manager on the Scrum or Kanban team. The team needs to be self-organising.
As Fred Brooks said so long ago there is no silver bullet, so Scrum masters please close your Scrum bible and do the hard work of figuring out what works for this team at this time.
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.
Wow. Talk about unrealistic expectation!
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.
"My experience is that business representatives and management would rather treat their own IT as an external contractor than working tightly together"
"business representatives and management would rather treat their own IT as an external contractor"
Funny thing really, most IT departments I've worked in for large companies half the staff literally *were* from external contacting firms.
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... 😉
You know I like a good Slicing reference :)
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.
Have you / your team tried Three Amigos?
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)
Can you say more about that?
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)
Another thing came into my mind: team's scrum master checks that a story with 2 story points must be closed exactly after 2 days otherwise team statistics will look bad what management is closely watching.😂
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.
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’.
Yes, that's REALLY annoying!
Too many stand-ups! Having them every single day can dilute their importance. 3-a-week is more than enough.
In my most recent team, we skipped standups on Wednesday. But I would have preferred 5 standups per week - providing that they are useful. (I must do a episode on what I mean by "useful".)
I have actually found end-of-day recaps to be more efficient; without reading out Jira, everyone can end the day saying what they achieved, and have a clear priority on what they should start or continue with the next day. So they can begin the day without a dreaded meeting that basically ruins your mood before you even start work. It's just more positive. I recently organised this with a remote team, and it worked well; communication happened naturally throughout the day, and so the actual meeting was more lighthearted, a chance to talk; I referred the stakeholders to Jira to see status updates, and kept them in the loop on behalf of the devs, who I wanted to be allowed to focus.
I worked with a team of Standing-Desk-ers that did a daily SIT DOWN - at the end of each day. Worked for them!
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.
I think the fundamental flaw is breaking up large complex design problems into 2 week sprints... especially when doing something new where planning can't be templated from an old project. Breaking things down into 2 week chunks results in a lot of planning of detailed work without any planning of big tasks (resulting in bogging the team down in multi-day planning meetings every 6-8 weeks, but also a team working for months in the wrong direction and big goals getting delayed). Also, many, many managers abuse agile to show metrics of closing off lots of tickets even though they are making very little progress towards the big goals (I call this "checky-boxes"). And on top of this, using most of the software associated with agile (*cough* jira *cough*) is slow and frustrating (see: ifuckinghatejira.com).