Still 45 scrum meetings left... (software job rant)

[Linea_Norway]

I have now 45 scrum meetings left before FIREing. That are 45 too many for my taste.

For those of you who are not familiar with the concept of scrum in software development:

You come together with a team on a daily basis and have a stand up meeting. Everyone uses max 2 minutes to tell the others what they accomplished yesterday, what they will accomplish today and whether something is standing in the way for doing that job.

At least our team has decided that we can sit at the table instead of standing up. I have been present at many stand up meetings in the past that lasted much longer than 2 x number of participant minutes. That caused me pain in my back.

I generally dislike having to tell others in detail what I did or will do. It is detailed management of what I am doing and not by my manager, but by my peers. Sometimes I do something very obvious that could be worth mentioning. But most of the time I do lots of minor tasks just to keep things running smoothly, sometimes for different projects, that are not worth summing up at the meeting. Or I am working on the same task for weeks in a row. On the days I am not motivated, I spend a lot of time online, and then need to invent something I worked on. Also, what the others tell me is seldom very interesting for me, like max 10% is potentially interesting. The rest of just an utter waste of time.

As our team starts the day at very different times, the scrum meeting is in the middle of the day. It limits the time I can schedule my half an hour lunch. It needs either before or after. Also, when I am at lunch, I need to keep an eye on the clock, not to miss it. When I am working on something interesting, and come back from lunch and get into a flow, then for scrum, I need to drop everything and go to the meeting. I find it often very disturbing.

Sometimes when we have a period in which I am needed in another part of the building for 2-3 weeks in a row and everyone knows what I am doing there, they still want me to leave the customers and appear at the scrum meeting to tell them what they already know: that I still working on that same thing. I have rejected to do that.

I hate scrum planning sessions, which are very boring and the tempo is way too slow. Backlog refinement meetings are equally boring and sprint reviews are just annoying: every week again finding things that could be better or worse. I do appreciate the sprint demo though, as I actually often learn something there.

I also hate that the (in our case 2 weeks) periods in scrum are called "sprint". You are not supposed to be "sprinting" all year long. That wears people out. It should rather have been called "endurance session".

And if you work with software development and are not your own boss, you cannot avoid some form of scrum. Most companies say they do scrum, but in reality don't. At least my company now finally does something that looks a lot like the real thing, instead of some really bad copy like I experienced during the last 10 years or so.

Please join me in your dislike of scrum.

[SwordGuy]

The thing that really pissed me off about status meetings (in any format) is how very many of them contained scenes just like this;

Manager, speaking to the next person around the room, in order, just like the last 4: "Well, Bob, your status?"

Bob, with a deer in the headlights expression that clearly shows he's never, ever, EVER considered what he would say when his turn came up until this very minute, followed by a rambling, incoherent, pointless report.

It's like each and every time they are astounded to discover they are supposed to report their status!

[MayDay]

My H has these and hates them. I make fun of them/him relentlessly. "Hi honey, how was your marathon today? Did you have a good tackle?".  Who comes up with these ridiculously stupid buzzwords?

He has to do something where he rates his feelings or progress or something, with a 1-5 scale. He uses a random number generator.

Even our kids now say that agile is stupid.

[neo von retorch]

At my last job, we used Microsoft's Visual Studio Online (now renamed to Azure DevOps, because buzz words!) and while some of the developers were terrible at keeping the board showing what column your tickets were in up-to-date, I was my usual obsessive self. So each meeting, we would pull up the board on the projector screen, filter to the person speaking, and in my case, I would read off the board. "As you can see, I've got ticket #31415 in development, and I've moved #31413 to the ready to merge column, because that code is in a pull request and ready to be merged."

Our current "agile" is mostly OK, but this is a bit more "startup" than I'm used to, so we have a product team saying "We think we want...." and then our team working on the things we'll need to build to support that thing... and then halfway through a Sprint, "We realized we definitely don't want..."

We also have "ideas" of how the overall system is going to look like, but it's not completely clear. We've created Stories that move us towards how it will work, but they are often looked at in a sort of silo fashion, and the end result is a lot of last minute Stories that will adjust the edges of the puzzle pieces to fit together! But we keep having scenarios where one system can't be updated until another is ready, and one Story can't be started (or will require later rework) because it depends on a Story in-flight.

I'm sure I could go on, but that's enough for now. Yesterday was an extra long day of Sprint Retro and I'm not sure if I'm emotionally ready to talk about that!

[frugalnacho]

The thing that really pissed me off about status meetings (in any format) is how very many of them contained scenes just like this;

Manager, speaking to the next person around the room, in order, just like the last 4: "Well, Bob, your status?"

Bob, with a deer in the headlights expression that clearly shows he's never, ever, EVER considered what he would say when his turn came up until this very minute, followed by a rambling, incoherent, pointless report.

It's like each and every time they are astounded to discover they are supposed to report their status!

Bob sounds like a real scrum bag.

[AccidentialMustache]

There's nothing wrong with agile. Its a tool. You wouldn't call a screwdriver a bad tool because the idiot who thinks all the world is a nail used the back end of the screwdriver to bang a nail in. Quit handing the idiot useful tools to bang in nails and make them sit in a corner with their hammer and do busy work nailing. Meanwhile, give everyone else screwdrivers, pliers, etc and  get something useful done.

I'm sorry you have idiots in your agile processes though. Fight the good fight.

My big pet peeve is "we need to increase our velocity" -- well, velocity is a measure. We don't need to increase it. It may say we have other problems to fix (tech debt, too many stupid meetings about how to increase our velocity, etc) and velocity will take care of itself. Or maybe we have new team members and we size tickets differently now. That's okay too.

The best stand-up process I've seen was a former manager's. Unfortunately I failed to get my new gig to adopt it. On your turn you answer three questions: is your board up to date (note: it helps to have swim lanes per-person, which is kinda Kanban-y), do you have any risks or blockers (ticket more complex than estimated, waiting on another ticket/team, don't understand what to do, upcoming vacation), and do you have any post-standup topics. Standup itself was a 5-10 min affair for a team of 4-5 devs, 1-2 product, 2-3 qa, and 1 manager. We'd then stay and discuss any group topics that came up, but we were still usually done in 15-20 max.

Sprint planning should be pretty boring and route. If your backlog is well groomed, sprint planning is "What was our previous velocity? Anyone have upcoming vacation? Okay, put that many points in the next sprint. Done." Grooming is important. If you aren't getting value out of grooming, that's bad. It should tell you what in general is going on, what is important to get done first, its your place there as a dev to tell product that we can do X but we need to do Y and Z first, so put those in there first (Y and Z can be paying down tech debt, refactoring, etc that supports X). It also ensures that the ticket is well enough specified that everyone can estimate it, which means it should be fairly question free when it comes up in the sprint itself.

[secondcor521]

I studied agile and thought about it deeply for the last two years at my last job.

If everyone really understands it and buys into it and the chosen tool set supports the process, then I could see it working phenomenally well.  Unfortunately, those are some very big ifs.  Most of the time, people do "agile-ish" or "software development the way I like to do it with some agile buzzwords thrown in".

I tried to persuade and explain for those two years and failed to get anywhere.  I was a project manager and a scrum leader of about a third of the dev team, but that wasn't enough to get people to understand or buy in enough to change the way we did things.  Frustrating, but I'm not sure how I could have done better or done anything more.

Most of the things people think are wrong with agile are actually because they're not *really* doing agile.

[BicycleB]

The thing that really pissed me off about status meetings (in any format) is how very many of them contained scenes just like this;

Manager, speaking to the next person around the room, in order, just like the last 4: "Well, Bob, your status?"

Bob, with a deer in the headlights expression that clearly shows he's never, ever, EVER considered what he would say when his turn came up until this very minute, followed by a rambling, incoherent, pointless report.

It's like each and every time they are astounded to discover they are supposed to report their status!

Bob sounds like a real scrum bag.

LOL

[bacchi]

On one project, we got a rigid hard-ass as the new scrum master. He was adamant about not working on anything other than what you committed to.

Me: "The Acme client engagement is somehow getting locked. I'm going to look into that."
SM: "Did you commit to doing that?"
Me: "Well, no, it just came up and it's a serious production issue that's related to the code I wrote and devops asked for help."
SM: "Work on your tasks/stories/features. Don't work on that."
Me: "Ok...."

Of course, this meant that we worked on these issues anyway and just padded our tickets. Then, like linea_norway, we'd make something up for stand-up. (And, no, there wasn't a story for hot fixes. A loosely defined story like that would've thrown off the velocity!)

Except for that project, I actually liked agile and kanban and sprints but maybe because it was often done in a non-strict, lets-get-shit-done, manner.

[thesis]

Oh, man, I stumbled across the right thread!

We have a daily stand-up meeting. It's occasionally meaningful, but mostly worthless. We are in a small office so it isn't a tremendous time-suck, but there's been this ridiculous, "The stand-up absolutely must happen!" attitude, even when key team members are gone or nobody's update is relevant to anybody else. We have a very enthusiastic scrum master, who is a very nice person, but I had no idea anybody could actually be *passionate* about scrum.

I once questioned the value of the stand-up, and was not alone, but the answer was, "This is what we do, because this is what we do!" It's eye-rolling, but I comply. There are good people here.

Agile really is kind of a joke. It's full of buzzwords and processes, and I can't believe some people have actually dedicated their careers to the subject and written 400-500 page BOOKS on MEETING THEORY. Sure, the planning aspects are somewhat helpful (our "sprints" go pretty smoothly), but it's sort of like being thrown into a cult that follows an amalgam of various process theories that have been published, but without really understanding why or what the alternatives are. And sadly, the alternatives are probably no better, likely also being cooked up in dense book format so as to be strictly adhered to. "We follow Agile/Scrum because Agile/Scrum is god!"

When people say that if you do what you love, you'll never work a day in your life, I think about stand-up meetings and how being FI could eliminate them from my life :). Even jobs you "love" have BS, and even then software is something I "like" and occasionally find "very interesting".

[Tyson]

Management LOVES Agile because it lets them micromanage AND use cool sounding terms like 'scrum' and 'standup meeting'. 

[neo von retorch]

Management LOVES Agile because it lets them micromanage AND use cool sounding terms like 'scrum' and 'standup meeting'.

And they can ask for whatever want and change their mind on a dime and then yell at engineering...

Well you're supposed to be agile right??!

[GuitarStv]

I've tried to streamline the scrum meetings I'm in charge of to be pretty minimalist.  I don't ask people for a daily report really . . . I ask them if they have encountered unexpected issues and if there is anything blocking them (management/equipment/other groups).  Everyone knows their status by their tracked time in Jira and their tasks on the board.

Usually our daily scrums are only a couple minutes.  :P

[MayDay]

If the problem with agile is really that no one does it right, and it sucks donkey balls when you do it wrong, then it's still a problem with agile.

[Daisy]

Ahhhh...one of the joys of FIREd life is the thrill of never having to go to a stand-up scrum meeting ever again! I worked 25 years in the software industry and definitely this new fad of agile/scrum was completely annoying, especially since my company used it for micromanaging, in my opinion, and to say how cool and hip they were to take on this new fad in software processes.

I remember in the past having to go through SEI level assessments where documentation was SOOO important, and now nothing was getting documented with the new Agile development processes. In my opinion, this really is dangerous with a product line that had to be maintained for over 10 years for mission critical communications equipment, and no guarantee that the person the designed a feature would be around to debug it.

One of my favorite scrum/agile rants has to do with the time when I was a scrum leader (or whatever its called officially), I noticed a couple of months in advance that one of the "sprint" starts was going to fall on a Monday holiday. Apparently it was very important that the new sprint info just HAD to be done on that first day of the sprint, or apparently hell would freeze over.

Well I thought I would be proactive and mentioned it to my manager. Perhaps we could start the sprint on Tuesday, instead of Monday, considering it was a national holiday and all. The manager thought about it and said "why don't you do it on Sunday instead?". Apparently he didn't realize how ridiculous this sounded. Apparently if I submitted the sprint info on Tuesday instead of Monday, it would screw all of the metrics up. I kindly laughed back at him. I did make sure to submit it on the Friday before and did all of the work a few days early, but such is the case with fixed date sprints.

[FINate]

If the problem with agile is really that no one does it right, and it sucks donkey balls when you do it wrong, then it's still a problem with agile.

THIS^^^ Agile is a scourge on the software industry, second only to open office plans which are, not coincidentally, related. Agile is cultish and mind numbing, and its most ardent practitioners are (in my experience) those who are more interested in telling others how to work rather than getting it done themselves. The only right way to do "agile" is to fire the coaches and find the most minimal project management that works for your team...whatever that happens to be.

[Linea_Norway]

I remember in the past having to go through SEI level assessments where documentation was SOOO important, and now nothing was getting documented with the new Agile development processes. In my opinion, this really is dangerous with a product line that had to be maintained for over 10 years for mission critical communications equipment, and no guarantee that the person the designed a feature would be around to debug it.

At my current job everything has to be documented in detail. Very un-agile, but need to comply to regulations. So that part is still good. We just put the documentation tasks on the scrum board like everything else. For the past couple of years, the developers always liked to do the coding first and wait with the documentation until after code freeze. Testers didn't have the requirements before the code was finished and tested. After a lot of protesting from my side, we are finally finishing some epics with all the tasks, before starting new stuff. But it is generally difficult stopping a developer from wanting to write code.

In my previous company, before we started with scrum, we had documented the complete new system in Enterprice Architect in use case diagrams and sequence diagrams. Everyone in the company used it, including the support people who thought it was very useful. Guess what happened when new external managers came in, we had to do agile and documentation suddenly was less important than delivery. With half a year the documentation was hopelessly out of date and a lot of frustration appeared.

[seattlecyclone]

If the problem with agile is really that no one does it right, and it sucks donkey balls when you do it wrong, then it's still a problem with agile.

Well said. Opening up this thread I sort of knew there would be someone chiming in with the line "oh, scrum isn't working well for you, your team must be doing it wrong. it's totally awesome when done right." I heard that line from more than one person at more than one job. I must never have experienced it being "done right" then, and I've worked for some well-known companies.

Probably the closest I ever came to "doing it right" must have been at my last job. We had no "sprints" with their associated drawn-out planning/retrospective meetings, and a twice-weekly quick standup. Twice a week was frequent enough to give you some idea what the others on your team were doing, but not so frequent that anyone had to try and make excuses for why they didn't accomplish anything significant in the three hours they had to do real, actual work since the last standup.

[AccidentialMustache]

That's okay, most folks here don't really know what agile is, based on the discussion. Here's what agile is, if you've never seen it:

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

ｩ 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.

https://agilemanifesto.org

Agile at its core isn't much. It certainly isn't write code before docs -- its that having extensive docs and no code is not something you can deliver value to a customer with, nor get meaningful feedback on. It isn't "the sprint must start Monday" -- actually you'll notice there's no such term as sprint anywhere. Nor retro, grooming, sprint planning, or anything else associated with the "agile flavor of the year." (which somehow seems to be Scrum year after year, despite that I've never actually been on a team with a scrum master, and thus it isn't actually Scrum.)

Agile mostly boils down to: deliver a MVP and get feedback as soon as possible and use "self"-reflection to improve your team's processes (even if they are all informal processes).

In many ways it isn't that different than these forums. People do case studies well before FIRE to get feedback on what they are doing and now to improve. There's lots of suggestions for doing an early MVP to see if FIRE is right for you -- vacation, time off between gigs, downshifting, doing the activities you want to in FIRE now, etc. All the discussion about sequence of return risk or what happens after the aca is about responding to change.

If all your team does is scrum you aren't really doing agile, because you've failed the "improve your team's processes" test -- scrum isn't the right answer for all teams. I might go so far as to say scrum isn't the answer for most teams, because I think scrum is kinda garbage. I like kanban a lot more.

[FINate]

Over the years I've read books and papers from many of the folks listed. And I've had masters, coaches, gurus and all manner of quasi-religious advocates proselytize their version of "agile" they claim fixes the problems of the previous variation that no one really understood or did right. Early on I even bought into it and embraced agile full bore before realizing it's mostly* unhelpful, and that the most useful parts aren't unique to agile (e.g. TDD).

MVP is not a panacea. It works fairly well for smallish projects with a well defined scope and limited time horizon...you know, the type of projects consultants usually work on. However, on large complex projects with competing stakeholders and requirements it ends up creating Frankenstein software as features are increasingly tacked on to accommodate the sprint cycle with little regard for the overall design.

Similarly, agile is not a good fit for lower-level projects -- things like infrastructure, tooling, and APIs. If you have 100s of thousands of downstream dependencies then a lot of churn in turn creates tons of chaos and whiplash.

*Agile has its place, and I've seen it work well when applied to the right types of projects. But the problem with agile zealots is they continue to insist it's the bee's knees and push it in wildly inappropriate contexts, and when this inevitably fails they blame how agile was put into practice rather than inappropriate application of agile in the first place.

[Tris Prior]

My company is just starting this system. It hasn't officially launched yet, but it sounds terrible. I don't work in software and I really don't see how this is going to work in my field. I agree with you about "sprint" - we ALREADY feel like we are constantly sprinting, and now that is going to be encouraged? Ugh.

[Wrenchturner]

Managers are often zebras, they want to blend in with the herd(much like politicians).  Sometimes it seems projects like this are an attempt to show leadership somewhere rather than tackle large, complex problems pervading a company. 

[FINate]

My company is just starting this system. It hasn't officially launched yet, but it sounds terrible. I don't work in software and I really don't see how this is going to work in my field. I agree with you about "sprint" - we ALREADY feel like we are constantly sprinting, and now that is going to be encouraged? Ugh.

You're in for a...uh...interesting journey. Get ready to drink the Kool-Aid and learn a bunch of silly buzzwords for things you already do and/or things that shouldn't need to be described in excruciating detail.

For what it's worth, my suggestions:

• Find out who is championing this, which may be more than one person. You need to know this because they've invested their reputation, likely hiring outside consultants to help, and a lot is riding on this for them. Under no circumstance should you appear critical of agile in front of them or any of their minions who may tattle. You DO NOT want to be seen as a problem person undermining this grand plan of theirs.
• If you can, figure out what their motivations are. If it seems like they're using this as a way to force more productivity out of workers...sorry, you're probably in for a rough ride. If they've just been taken in by the latest fad(s) then you're much better off.
• Learn the lingo, talk the talk. It's not *all* terrible and you may even learn a few useful things along the way.
• Play nice with any agile consultants. You want to learn it ASAP so they an leave sooner rather than later.
• Sprints don't magically improve velocity or productivity. So be prepared to have conversations with your manager and/or scrum master that go something like: "I have this urgent problem that needs to be addressed, but it's not on the storyboard nor is it part of the current sprint plan. Is it okay to work on X  if this means I won't complete all my stories this week? Please advise."
• Once you know who's pushing this, the consultants are gone, and everyone is attempting to put it into practice, then consider very carefully working with your direct manager/lead (assuming they not the ones leading the charge...if they are, things are way more difficult) to modify the parts that aren't really working and/or are ineffective. Basically, subvert from within, but always make sure you communicate that you're doing Agile. This is where knowing the lingo pays off. Agile is a very squishy term, so you can use that to your advantage if purists start asking questions. Also, if you pay attention to the agile books and materials, you'll see that there's stuff in there about flexibility to change stuff.
• If the project is successful be sure to sing the praises of agile even if you're not really doing agile or the project succeeded despite it.

Using this approach I've successfully led projects where we essentially followed a modified version of a traditional waterfall, yet as far as management was concerned it was "agile."

[neo von retorch]

Say it with me:

Individuals and interactions over processes and tools. Responding to change over following a plan.

. Keep saying that whenever you need to actually get something done and management is more concerned with SCRUM rituals...

https://agilemanifesto.org/

[Tris Prior]

Thanks for the suggestions! We are a big company and this is coming down from the CEO and EVP level.

As far as I can tell, this is happening because the company has always done large behemoths of projects that take years to complete. They want to move to a model where we are doing smaller projects and releasing them more frequently.

We have to go to training on it sometime in the next month or so. It's just..... they keep talking about 2-week sprints and our work does not neatly fit into 2-week schedules AT ALL right now. Even if it's a small project, those are measured in months, not weeks. Maybe it's going to be broken into smaller chunks? It doesn't make sense to me, maybe it will after training.

So..... you're not allowed to stop work on a sprint to put out a fire if the fire has nothing to do with the sprint? Hooooooo boy. That is going to be a big problem. We ALWAYS have fires and they ALWAYS are OMG urgent. (Or, y'know, "urgent." No one is dying.)

I'm fortunate in that my supervisor is as skeptical of corporate stuff like this as I am. If I were to tell my supervisor "this is not working because of XYZ," I think she would be up for working with me to figure out how to fix it. She's really good at getting around politics of this sort; I am very much NOT.

[Dicey]

Wait! You're almost FIRE. You've given notice. Why do you have to attend any more scrums, @Linea_Norway?

[Paul der Krake]

I actually like my daily standup meeting. It's the time of day when we get to hear how our more junior devs are doing and nudge them in the right direction. Or get people's advice on something.

Sprint planning should be less than an hour. Retrospectives are garbage so we don't do those.

[Daisy]

Wait! You're almost FIRE. You've given notice. Why do you have to attend any more scrums, @Linea_Norway?

My favorite excuse to get out of nighttime calls with my Asian counterparts when I was almost FIRE was "I have a personal conflict".

[FINate]

Thanks for the suggestions! We are a big company and this is coming down from the CEO and EVP level.

As far as I can tell, this is happening because the company has always done large behemoths of projects that take years to complete. They want to move to a model where we are doing smaller projects and releasing them more frequently.

We have to go to training on it sometime in the next month or so. It's just..... they keep talking about 2-week sprints and our work does not neatly fit into 2-week schedules AT ALL right now. Even if it's a small project, those are measured in months, not weeks. Maybe it's going to be broken into smaller chunks? It doesn't make sense to me, maybe it will after training.

So..... you're not allowed to stop work on a sprint to put out a fire if the fire has nothing to do with the sprint? Hooooooo boy. That is going to be a big problem. We ALWAYS have fires and they ALWAYS are OMG urgent. (Or, y'know, "urgent." No one is dying.)

I'm fortunate in that my supervisor is as skeptical of corporate stuff like this as I am. If I were to tell my supervisor "this is not working because of XYZ," I think she would be up for working with me to figure out how to fix it. She's really good at getting around politics of this sort; I am very much NOT.

How do you take a large monolithic project with no natural fault lines and break it into a bunch of 2-week sprints? It's all a game of semantics. You invent artificial points and call these releases. Let your current intermediate work outputs lead the way, and get creative. That internal specification that takes weeks to iron out on which everything else depends? Well, that's now a "releasable product." This doesn't mean it gets done in one sprint - remember, you're an Agile team now, and Agile teams iterate. You love to iterate.  So iterate like hell on that spec. You'll end up doing essentially the same work, but dressed up as agile. The important thing is to make lots of noise and have many artifacts to show how much work is getting done. Setup software to track stories and velocities, or even better, whiteboards with lots of Post-It notes (very Agile-y!). And be sure to plot the project velocity on dashboards and graphs. The more Agile looking things you can cram into the office the better. This will give the higher-ups warm fuzzes about the progress of the project, never mind the fact that the increase in process overhead actually makes the project take longer, and the short-term nature of sprints tends to produce sub-optimal designs that once solidified take way longer to fix than if they were just done right to begin with.

Fortunately for you, it sounds like you have a good manager. So it will mostly be her job to figure out how to navigate all this, and if she's politically savvy then she'll probably do an okay job of it. But give her a lot of grace. If this is coming from the very top she will likely feel like she has to fall in line, so she will be very discrete about who she confides in, especially early on before some of the dust settles. So play it cool and give it the old college try, and be patient.

The one thing that will drive the higher-ups bonkers is the loss of any sort of project predictability beyond 2-4 weeks. When will the project complete? ｯ\_(ツ)_/ｯ Remember, we're dynamically iterating up in here, not following some stodgy old plan. They will quickly start asking for predictability in the schedule, and this is the opening to start putting a bunch of the old process back in place but with different buzzwords.

[Linea_Norway]

Wait! You're almost FIRE. You've given notice. Why do you have to attend any more scrums, @Linea_Norway?

Part of the office rituals. Everyone needs to be is some scrum team, up to their last day.
Yes, I guess I could just not go at all. They won't fire me for it now. But I want to keep a good atmosphere. And I now feel responsibility towards my coworkers.

At least now, for the first time in years, we are doing the scrum shit like a team following the normal guidelines. Management is not involved in how we do it, as long as we do it. That helps. At least, following the scrum guidelines is slightly better than calling it scrum and not being agile at all, apart from the standup meetings.

@Tris Prior , if scrum ain't working in your company, then suggest that you follow the scrum guidelines more strictly.

For fires, they probably need a task on the scrum board as well. You can just make one as it appears. In Jira, you can show a double scrumboard, with the support board on one half and the big project board on the lower half of the screen. As log as you have a task, you show what you as working on. Which also results in other departments hating you, bacause you will always instruc them to first make you a task before you are willing to help them with a problem (one of my frustrations with another team).

Stil 43 left...

[Tris Prior]

@FINate, yeah, I suspect that we're either not going to do the huge projects in the first place, or we're going to just artificially break them into small chunks. I asked my boss if, like, one Widget (being vague intentionally) could be considered a sprint (where we would usually do a group of 8-10 Widgets at a time, and she said yes - so, OK, that KIND OF makes sense?

The one thing that will drive the higher-ups bonkers is the loss of any sort of project predictability beyond 2-4 weeks. When will the project complete? ｯ\_(ツ)_/ｯ Remember, we're dynamically iterating up in here, not following some stodgy old plan. They will quickly start asking for predictability in the schedule, and this is the opening to start putting a bunch of the old process back in place but with different buzzwords.

I mean, this bit is giving ME hives and I'm not a higher up. We have deadlines that have nothing to do with our customers. How do we meet those without having an end date in the first place?

As log as you have a task, you show what you as working on. Which also results in other departments hating you, bacause you will always instruc them to first make you a task before you are willing to help them with a problem (one of my frustrations with another team).

We already use JIRA - and not every team has access to it. So, what usually happens is some other team (usually PM) will ask us to do a Thing, and then we have to make a ticket for it ourselves. But, that's a good point, because now if someone who's not a PM asks us for something, we just do it. So this will have to be documented now? Hm. Yeah. That could be an issue.

Question - does having Agile experience make one more marketable? Is it a resume builder? Or just a buzzword?

[Linea_Norway]

@FINate, yeah, I suspect that we're either not going to do the huge projects in the first place, or we're going to just artificially break them into small chunks. I asked my boss if, like, one Widget (being vague intentionally) could be considered a sprint (where we would usually do a group of 8-10 Widgets at a time, and she said yes - so, OK, that KIND OF makes sense?

The one thing that will drive the higher-ups bonkers is the loss of any sort of project predictability beyond 2-4 weeks. When will the project complete? ｯ\_(ツ)_/ｯ Remember, we're dynamically iterating up in here, not following some stodgy old plan. They will quickly start asking for predictability in the schedule, and this is the opening to start putting a bunch of the old process back in place but with different buzzwords.

I mean, this bit is giving ME hives and I'm not a higher up. We have deadlines that have nothing to do with our customers. How do we meet those without having an end date in the first place?

As log as you have a task, you show what you as working on. Which also results in other departments hating you, bacause you will always instruc them to first make you a task before you are willing to help them with a problem (one of my frustrations with another team).

We already use JIRA - and not every team has access to it. So, what usually happens is some other team (usually PM) will ask us to do a Thing, and then we have to make a ticket for it ourselves. But, that's a good point, because now if someone who's not a PM asks us for something, we just do it. So this will have to be documented now? Hm. Yeah. That could be an issue.

Question - does having Agile experience make one more marketable? Is it a resume builder? Or just a buzzword?

When your dealine is fixed, and your team works too slowly to make it for whatever reason (usually getting too many other tasks/fires), you can do two things: increase number of resources (hire consultants) or reduce scope. Some features of the new system are more important than others. Start with the most important ones, what get done, gets done.

[FINate]

The one thing that will drive the higher-ups bonkers is the loss of any sort of project predictability beyond 2-4 weeks. When will the project complete? ｯ\_(ツ)_/ｯ Remember, we're dynamically iterating up in here, not following some stodgy old plan. They will quickly start asking for predictability in the schedule, and this is the opening to start putting a bunch of the old process back in place but with different buzzwords.

I mean, this bit is giving ME hives and I'm not a higher up. We have deadlines that have nothing to do with our customers. How do we meet those without having an end date in the first place?

It depends. There's a spectrum of flexibility vs. predictability and teams pick a point with an appropriate trade-off between these competing concerns. The more you move towards predictability the more it behaves like a traditional waterfall model, even if you're doing sprints/scrum/stand ups and so on.

As log as you have a task, you show what you as working on. Which also results in other departments hating you, bacause you will always instruc them to first make you a task before you are willing to help them with a problem (one of my frustrations with another team).

We already use JIRA - and not every team has access to it. So, what usually happens is some other team (usually PM) will ask us to do a Thing, and then we have to make a ticket for it ourselves. But, that's a good point, because now if someone who's not a PM asks us for something, we just do it. So this will have to be documented now? Hm. Yeah. That could be an issue.

Question - does having Agile experience make one more marketable? Is it a resume builder? Or just a buzzword?

IMO, it's best to always make them create a task/story for whatever the Thing is, no exceptions. And make sure it gets prioritized along with everything else in the sprint planning process, no sneaking to the front of the queue. Yes, they will hate it, and they may escalate their complaints, but this is what you want...you want them to be the ones complaining about the downsides of the new methods. Besides, this is a good opportunity for the higher-ups to understand more of why projects take a long time. They will see that their teams are getting pulled in lots of different directions, such that no one is really working full time on any one project.

Is agile marketable? I suppose so, especially if you're looking at jobs openings which emphasize agile methods, then I would play it up on the resume...assuming of course that you decide that this is something you like doing.

[Tris Prior]

Ooh yeah, they are going to HATE that. But if they escalate their complaints, they'd be escalating to the very folks telling us we have to do it this way, so I guess we'll see how far that gets them.

I left out the probably relevant bit of information that this past week my company had a big layoff and we lost nearly half of our team. Which was already pulled in multiple directions where we really need people FT on one project. So, agile or not, that is going to be a problem.

Linea, I'm really glad that you're able to see the end to this, for yourself. It's definitely more motivation to FIRE (which unfortunately is a long way off for me).

[BicycleB]

Ooh yeah, they are going to HATE that. But if they escalate their complaints, they'd be escalating to the very folks telling us we have to do it this way, so I guess we'll see how far that gets them.

I left out the probably relevant bit of information that this past week my company had a big layoff and we lost nearly half of our team. Which was already pulled in multiple directions where we really need people FT on one project. So, agile or not, that is going to be a problem.

Linea, I'm really glad that you're able to see the end to this, for yourself. It's definitely more motivation to FIRE (which unfortunately is a long way off for me).

Tris - If you learn the problems of Agile, plus how to explain solutions in Agile terms, you'll be able to talk to anyone familiar with Agile. That plus your traditional Waterfall skills should let you interview anywhere.

'Cause it sounds like you might have interviews in your future!!

Only partly kidding. Good luck.

PS. Joking aside, I learned some Scrum, implemented some (big whoop) and interviewed at a few places. It became clear very quickly that no matter what approach a company takes, the skill of getting work done in tech teams is tricky, and experience is valued. People want to know that they can trust you to make things better, or at least rely on you to not make them worse. Everybody has their own opinion about what this means. These days some of those opinions are called "Agile".

PS. Really liking the comments of @FINate, @Linea_Norway herself, and most of all this gem from @Neo von retorch:

Say it with me:

Individuals and interactions over processes and tools. Responding to change over following a plan.

. Keep saying that whenever you need to actually get something done and management is more concerned with SCRUM rituals...

https://agilemanifesto.org/

[Sibley]

My company is trying to do Agile. Which, in some circumstances, it seems to work decently. In one massive, notable circumstance, it's causing serious problems.

My company is doing a new general ledger. Big deal. Not easy. And they're 6 months behind schedule and counting, and as far as I can tell (Internal Auditor, but not working on that project), a big chunk of the problem is that the minimum viable product wasn't defined correctly. When you're building an app, it's ok to build a bare bones version than keep updating it. But when you're building a general ledger, bare bones is pretty much everything. Some genius (idiot?) decided to split out payroll and A/P, and some other "smaller" pieces and do them first, then roll out the main GL (journal entries and reconciliations), then do round 3 for reporting, cost allocations, consolidations, etc.

Payroll went in 1/1. It's now the middle of October, and it's still not working right. AP went in 4/1. The new system stuff was ok-ish, they didn't load all the vendors and open purchase orders into the system, but what they failed to understand was the AP function was something like 4 months behind even without the new system to deal with. So that was a complete mess that they're still trying to clean up. I heard they hired something like 40 temps (base staff is around 10-15).

Then they turned on the GL on 7/1, intending to do dual entry into old and new systems for 3 months, then go fully live 9/1. Well first, something was broken and the accountants couldn't post any entries until the end of July. Then the chart of accounts was missing a bunch of needed accounts, and the cost centers were a complete joke (they had anywhere from 25-50% of the needed cost centers). Plus, there's something like 60 other systems that have direct feeds into the GL, and only about 1/3 of those feeds were working. And the data conversion is in the red, has been in the red, and is going to stay there for a while.

This all boils down to minimum viable product. With a GL, it's not "oh this piece is needed now, we'll get the rest later". You need all of it. It all has to work, basically flawlessly, on day 1. Which means, you have to build it all, test it all, get everything working, THEN you turn it on.

I'm really glad I'm not the one who made these decisions. Because the finance exec's are pissed.

They're also working on replacing another system. This is the main system that makes money. If they screw it up as badly as the related but smaller product line's system change over was, the company will be done. I'm keeping an eye on that one, if necessary I'll jump ship. That's also Agile. In that case, bad business requirements and nonexistent testing are to blame.

[BicycleB]

^What a horror story!!

Sounds like a case where a traditional waterfall method would have been far better. The rollout schedule with numerous deficiencies sounds like a bad sign too - instead of getting it right, they rushed into production without being ready. Disaster.

Very wise to recognize the possibility that another job might be needed.

[FINate]

A nightmare indeed. This is exactly the type of project that's unsuitable for agile.

Sadly, the pain is not likely to end for the devs if/when the project is completely deployed. Due to fragile design and lack of systemic planning (which happens when "working" code is fetishized), it will be difficult to evolve and maintain going forward. Fixing this bug here will surface another bug over there. Why is this bit of logic here? Who knows...nothing was sufficiently documented...so adding new functionality becomes fraught. I really feel for the team, it's super stressful and demoralizing, and eventually people will start dropping off which will make things even worse for the poor souls who remain.

With these types of projects the customer/user often doesn't really know what they want -- they think they do, but they have a lot of anchoring and implicit assumptions -- more often than not they will describe features instead of what it is they are actually trying to accomplish. It takes a lot of time and effort, and a certain type of person (usually not a SWE) to comprehensively draw out and define business requirements, and a team of qualified UX specialists is worth its weight in gold in parlaying these to produce an overall product design that's clean an intuitive, and finally, experienced SWEs to lay out an overall technical design and technical requirements. These documents shouldn't be set in stone and should evolve as the project progresses, but it's super important to have the big picture in mind when working on the smaller parts, and it's a real life saver to know why everything exists the way it does.

I get frustrated with agile, yet I should thank it because I had a very lucrative career (before FIRE) of stepping into complex projects that had painted themselves into a corner using its methods. In many cases projects could be salvaged by stopping the madness: doing a code freeze (except the most urgent/severe bug fixes), and systematically documenting, cleaning up, refactoring, and otherwise stabilizing the project, which could take a year or more. In more extreme cases the patient was too far gone and we'd have to do a full rewrite...I dreaded these most, because it's way more work than anyone realizes, and so much is required before any code is written that it's tough to get management buy-in.

EDIT: I've probably derailed this thread far too much. Linea, congrats on your up and coming FIRE date!

[gooki]

I get the joy of being a member of three scrum teams (UX specialist). Sprinting on multiple teams is a great recipe for burn out. Between all the administration and meetings there痴 fuck all time left to create anything. I learnt this the hard way, and now I知 ver selective about what meetings/stand ups I attend.

I miss the days when we ran a Kanban style system, managing everything trough Trello, with a once a week catchup. I felt super productive during those years and our teams got through a lot of work, and left a well documented trail because of how easy it was to dump information into Trello.

Now I知 stuck with a shit slow project management solution while we wait for someone to migrate us to Jira.

[Linea_Norway]

I get the joy of being a member of three scrum teams (UX specialist). Sprinting on multiple teams is a great recipe for burn out. Between all the administration and meetings there痴 fuck all time left to create anything. I learnt this the hard way, and now I知 ver selective about what meetings/stand ups I attend.

I miss the days when we ran a Kanban style system, managing everything trough Trello, with a once a week catchup. I felt super productive during those years and our teams got through a lot of work, and left a well documented trail because of how easy it was to dump information into Trello.

Now I知 stuck with a shit slow project management solution while we wait for someone to migrate us to Jira.

I am truly sorry for you, 3 different projects/scrum teams to work on.

[Paul der Krake]

Now I知 stuck with a shit slow project management solution while we wait for someone to migrate us to Jira.

HAHAHA, good one.

[Sibley]

A nightmare indeed. This is exactly the type of project that's unsuitable for agile.

Sadly, the pain is not likely to end for the devs if/when the project is completely deployed. Due to fragile design and lack of systemic planning (which happens when "working" code is fetishized), it will be difficult to evolve and maintain going forward. Fixing this bug here will surface another bug over there. Why is this bit of logic here? Who knows...nothing was sufficiently documented...so adding new functionality becomes fraught. I really feel for the team, it's super stressful and demoralizing, and eventually people will start dropping off which will make things even worse for the poor souls who remain.

With these types of projects the customer/user often doesn't really know what they want -- they think they do, but they have a lot of anchoring and implicit assumptions -- more often than not they will describe features instead of what it is they are actually trying to accomplish. It takes a lot of time and effort, and a certain type of person (usually not a SWE) to comprehensively draw out and define business requirements, and a team of qualified UX specialists is worth its weight in gold in parlaying these to produce an overall product design that's clean an intuitive, and finally, experienced SWEs to lay out an overall technical design and technical requirements. These documents shouldn't be set in stone and should evolve as the project progresses, but it's super important to have the big picture in mind when working on the smaller parts, and it's a real life saver to know why everything exists the way it does.

I get frustrated with agile, yet I should thank it because I had a very lucrative career (before FIRE) of stepping into complex projects that had painted themselves into a corner using its methods. In many cases projects could be salvaged by stopping the madness: doing a code freeze (except the most urgent/severe bug fixes), and systematically documenting, cleaning up, refactoring, and otherwise stabilizing the project, which could take a year or more. In more extreme cases the patient was too far gone and we'd have to do a full rewrite...I dreaded these most, because it's way more work than anyone realizes, and so much is required before any code is written that it's tough to get management buy-in.

EDIT: I've probably derailed this thread far too much. Linea, congrats on your up and coming FIRE date!

Luckily, they're not building from scratch, they're just adapting an off-the-box system. And mgmt got smart enough after the previous mess to dictate that they are to modify as little as possible. But still, between the chart of accounts, vendor master file, cost centers, and interfaces, there's plenty to screw up.

[Radagast]

I have no idea what anyone is talking about, and I already want to quit every job of every person on this thread.

[Linea_Norway]

This afternoon, our self-steering scrum team has called in for a meeting to divide my works tasks, for when I am gone. I am invited to the meeting, even though I am of the opinion that it cannot possibly my problem to solve. But I will explain the tasks if needed and learn up the new person when they need it. I made a very detailed list for my manager of things that I do to ensure the quality of the release. I am wondering if we get the exact list with as many details to discuss...

[Wrenchturner]

I have no idea what anyone is talking about, and I already want to quit every job of every person on this thread.

Haha, agreed.

[Sibley]

I have no idea what anyone is talking about, and I already want to quit every job of every person on this thread.

Haha, agreed.

https://en.wikipedia.org/wiki/Scrum_(software_development)

Should help a bit.

[BicycleB]

^Link above may have typo; relink below.

https://en.wikipedia.org/wiki/Scrum_(software_development)

[bacchi]

^^ https://en.wikipedia.org/wiki/Scrum_(software_development)

use the "Insert Hyperlink" button (the globe) in the editor.

[Wrenchturner]

^^ https://en.wikipedia.org/wiki/Scrum_(software_development)

use the "Insert Hyperlink" button (the globe) in the editor.

We'll discuss these issues at tomorrow's scrum.

[bacchi]

^^ https://en.wikipedia.org/wiki/Scrum_(software_development)

use the "Insert Hyperlink" button (the globe) in the editor.

We'll discuss these issues at tomorrow's scrum.

;-) Well played.