Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Che Delilas
Nov 23, 2009
FREE TIBET WEED

Skier posted:

"In typical agile fashion, we've laid out every ticket to be completed in each sprint for the next 12 months." Without asking anyone actually involved in doing the work what needs to be done or an estimate on what it will take for time. :psyduck:

What a manager thinks traditional development is: Ticket goes into developer, developer does magic, product comes out of developer in 6 months.

What a manager thinks agile development is: Ticket goes into developer and says "sprint," developer does magic, product comes out of developer in 2 weeks.

Adbot
ADBOT LOVES YOU

Feral Bueller
Apr 23, 2004

Fun is important.
Nap Ghost
Most managers think Agile means cranking out lovely code faster. The last 7-8 years of my career has consisted mostly of having to clean up after failed attempts at Agile.

ChickenWing
Jul 22, 2010

:v:

So today I get to tear apart and redo my validation code for the -third- time because the goddamn IA keeps changing. The first and second times I could live with but now they've decided they're going to use the JSON library that we found as our DTO instead of the nice, easy map structure we had before that worked really rather nicely with SpEL.


At least I'm not worried about not having any work now :shepface:

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

ChickenWing posted:

At least I'm not worried about not having any work now :shepface:

:toot:

CPColin
Sep 9, 2003

Big ol' smile.
Our sprints would normally end tomorrow (except for my team, because we're on Kanban :smug:), for a release Monday, but the office is closed tomorrow and everybody's scrambling to get stuff through QA today. I proposed we delay the release to Tuesday and it actually worked. I'm completely floored.

Xarn
Jun 26, 2015

CPColin posted:

Our sprints would normally end tomorrow (except for my team, because we're on Kanban :smug:), for a release Monday, but the office is closed tomorrow and everybody's scrambling to get stuff through QA today. I proposed we delay the release to Tuesday and it actually worked. I'm completely floored.

We did a round of sprint planning yesterday.

The plan for this sprint is to enjoy the holidays and get exactly nothing done until January. :D

Che Delilas
Nov 23, 2009
FREE TIBET WEED

Sarcasmatron posted:

Most managers think Agile means cranking out lovely code faster. The last 7-8 years of my career has consisted mostly of having to clean up after failed attempts at Agile.

My company has recently begun doing actual agile development. After one sprint, some of the management is upset that we're no longer committing every developer to three separate long-term tasks each, tasks that in the past have dropped into the next "sprint" half a dozen times before getting completely done. What we did commit to last sprint, we (mostly) got done, with more and better testing than we have in the past. We're not doing any less work, we're just focusing on the few highest short-term priorities so that when priorities change we don't have to stop in the middle (or in the first or last 10%) of something else. That last sentence is EXACTLY what Agile is for.

The management would rather we just keep making GBS threads out inadequately-tested, buggy garbage because it looks like we're doing more that way. Classic American short-term business strategy: present our customers with an ever-increasing pile of annoyances and almost-adequate features until they get fed up and fire our asses. Fortunately despite their complaining they seem to be willing to let us run with this a while and try to smooth out the process and address the problems.

I will say that I love the work environment once we get the managers out of the room and the devs can work together to break out the work items into individual tasks. The product owner and project managers need to stop with the "I'm concerned that we aren't doing enough, we have this deadline and this deadline coming up and we promised this customer this and that" rhetoric, and actually trust the team to organize and know what we can actually get done. If that happens, the whole process should be pretty nice. The passive-aggressive pressure doesn't help anything at all.

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

Che Delilas posted:

I will say that I love the work environment once we get the managers out of the room and the devs can work together to break out the work items into individual tasks.

Imagine if they threw a meeting, and nobody came?

Axiem
Oct 19, 2005

I want to leave my mind blank, but I'm terrified of what will happen if I do

Che Delilas posted:

The management would rather we just keep making GBS threads out inadequately-tested, buggy garbage because it looks like we're doing more that way. Classic American short-term business strategy: present our customers with an ever-increasing pile of annoyances and almost-adequate features until they get fed up and fire our asses. Fortunately despite their complaining they seem to be willing to let us run with this a while and try to smooth out the process and address the problems.

One of the things that I really like about where I work is that management is completely on-board with taking the time we need to make things right. As an agile shop, we try to work closely with our client and if new priorities come up, they jump to the top of our kanban, and we still try to provide some value with each story. But once we start a feature, we want to finish it and finish it right, and our management will fight for that as much as they can.

That doesn't stop the client from still asking for stupid and impossible timelines, but...y'know...clients.

Che Delilas
Nov 23, 2009
FREE TIBET WEED

Volmarias posted:

Imagine if they threw a meeting, and nobody came?

I can imagine it easily: they would abandon agile and go back to giving us commands and hard deadlines and generally involving us in the decision-making process as little as possible. I'd rather the devs continue to have the opportunity to organize our own work, because so far that part of it has been a really positive experience for us.

Axiem posted:

One of the things that I really like about where I work is that management is completely on-board with taking the time we need to make things right. As an agile shop, we try to work closely with our client and if new priorities come up, they jump to the top of our kanban, and we still try to provide some value with each story. But once we start a feature, we want to finish it and finish it right, and our management will fight for that as much as they can.

I feel like we have a chance to get to where you are, it's just that we're just starting to try it the Agile way and not everyone understands the details or the advantages. They just see fewer items on our board than they used to, so they're worried. The reality is that we weren't getting anything more done before than we are now, we just had a bunch of assigned tasks that kept getting put off. And in the meantime we aren't feeling so goddamn pressured (except during planning, when they pressure us to commit to more. But the rest of the time during the sprint, way less pressure).

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...

Che Delilas posted:

I can imagine it easily: they would abandon agile and go back to giving us commands and hard deadlines and generally involving us in the decision-making process as little as possible. I'd rather the devs continue to have the opportunity to organize our own work, because so far that part of it has been a really positive experience for us.

http://www.quotecounterquote.com/2011/12/suppose-they-gave-war-and-nobody-came.html

comedyblissoption
Mar 15, 2006

How are Agile sprints and commitments in a software development context sane in any way?

How does it make sense to commit to accomplishing work in a fixed time-frame that can easily overrun estimates?

Is there some psychological trickery involved in defining sprints and short-term deadlines that can result in greater productivity for some teams?

Sprints only make some sense to me in an organization that uses a source control system that makes it difficult to branch and merge new features (e.g. SVN). Sprints in this context would have the benefit of defining an endpoint of getting the code back into a stable state from a shitfest free for all of untested and interim commits.

Why not use a kanban approach where you just set priorities of estimated items and it's okay if they overrun their estimate because that is part and parcel of software development?

Axiem
Oct 19, 2005

I want to leave my mind blank, but I'm terrified of what will happen if I do
As my last PM was fond of saying, you can either pick the features you want released, or the release date. Not both.

Frankly, I think a Kanban approach is the best way I've seen of managing work. It clearly communicates the order things will be worked, and also pretty much enforces some prioritization. When talking with the client, any time they want some new feature, you can say "okay, where do we put it on the board?" and it shows an obvious deprioritization of the other work.

You can also go to them and say either "tell us where the line is by cards, or give us a date and we'll work things in this order".

New Yorp New Yorp
Jul 18, 2003

Only in Kenya.
Pillbug

comedyblissoption posted:

How are Agile sprints and commitments in a software development context sane in any way?

How does it make sense to commit to accomplishing work in a fixed time-frame that can easily overrun estimates?

Is there some psychological trickery involved in defining sprints and short-term deadlines that can result in greater productivity for some teams?

Sprints only make some sense to me in an organization that uses a source control system that makes it difficult to branch and merge new features (e.g. SVN). Sprints in this context would have the benefit of defining an endpoint of getting the code back into a stable state from a shitfest free for all of untested and interim commits.

Why not use a kanban approach where you just set priorities of estimated items and it's okay if they overrun their estimate because that is part and parcel of software development?

Kanban isn't a project management methodology. It's an apples-to-tractors comparison.

Bruegels Fuckbooks
Sep 14, 2004

Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Ithaqua posted:

Kanban isn't a project management methodology. It's an apples-to-tractors comparison.

Kanban is a power practiced by fake agile practitioners. If fake scrum doesn't work, put your user stories and tasks on a kanban board, and stop telling people that they need to get stuff done by the end of sprints.

comedyblissoption
Mar 15, 2006

Ithaqua posted:

Kanban isn't a project management methodology. It's an apples-to-tractors comparison.
I was comparing a sprint-based methodology to a kanban-based methodology. Both methods are promoted under the nebulous and undefined "agile" umbrella.

Che Delilas
Nov 23, 2009
FREE TIBET WEED

comedyblissoption posted:

How are Agile sprints and commitments in a software development context sane in any way?

How does it make sense to commit to accomplishing work in a fixed time-frame that can easily overrun estimates?

I'm no expert by far, but I've been digging into lately to try and help my company do it in a useful way.

The point of the two week time period is to get a regular feedback loop going, where you can show the stakeholders something and the stakeholders can tell you that yes, this is exactly what we wanted when can we have it, or no, this isn't what we wanted, or it's what we wanted but now we see it we don't like it. It doesn't even have to be a complete feature, maybe the feature was too big to be completely done in 2 weeks. But you can probably build some piece of it in that time, so the stakeholders see it and play with it and tell you about their experiences.

It gets you into a rhythm, a pace. Instead of changing the estimated time to deliver a particular feature or product, you change(break down) the features so that they can get done within a pre-defined time period. As teams work together under this constraint, they will naturally develop the ability to estimate and break down tasks. At the end of a sprint, you stop work, you review, get feedback, and re-prioritize. The scrum guy we had come in to our office to help us understand this said it's not about getting work done, it's about the ability to steer.

If a particular item doesn't get completely done, for whatever reason, it just goes back into the product backlog and gets re-prioritized with the knowledge that work has already been done on it (so it's either smaller or the team knows more about it and will be able to break it down into sprint-length stories better this time around). But again it's possible that someone will have changed their minds or other priorities supplant it anyway. That's cool, only spent two weeks on it anyway.

Che Delilas
Nov 23, 2009
FREE TIBET WEED
I should mention that I'm not sold on scrum. In particular I'm not fond of the meetings that bookend each sprint - they're long and tiring and in my specific case our product owner is not fully participating, which is kind of a problem. There are reasons, but I know this will need to get addressed or this process won't work. Regardless, I want to give this methodology a real chance; a couple of sprints, especially with the holidays as a factor (and they are), are not enough.

Destroyenator
Dec 27, 2004

Don't ask me lady, I live in beer
Scrum™ has been calling them "sprint forecasts" not "sprint commitments" for years now to address the implications of a "commitment". Failing to complete all the tasks (or completing way more than expected) is a failure of estimation. At retrospective you should try to work out why the forecast was off, unexpected absences are obvious but for stories that blew out (or were overestimated) the dev team should consider what assumptions they made that led to that. From there either take steps to address that (eg. new policy of getting all copy to legal for approval before a story is ready to be brought into a sprint) or just keep it in mind for future estimation (eg. anything touching external system X takes a lot more integration testing that expected). Estimates improve over the lifetime of a project as you learn more this way.

The idea of working in sprints is that the development team know what they're expecting to work on over a set time period and locks out the product owner from chopping and changing priorities daily. If you've worked somewhere where the PO can walk in and say "just had a meeting with client X, we need feature Y now, drop everything else" as a regular thing you will appreciate that. The length of a sprint should be decided by the product owner based on how quickly they expect priorities to change, if things are fairly stable they might be happy with one month sprints, if they're expecting to make lots of changes as the project develops then one week gives them more flexibility but forces work to be broken into smaller chunks (with some overhead). (If there is a huge shift in business priorities then can be a valid choice to cancel a sprint and immediately start a new one, this shouldn't happen often and the PO has to accept that all work done in the cancelled sprint is effectively lost and that time is wasted.)

As with all things the actual planning requirements and interactions between people change for every project so try to be reasonable about things. Scrum is a framework for getting teams into agile development and away from a multi-month waterfall model, both in terms of regular delivery of features and feedback loops but also in terms of redefining the expectations and relationships between the development team and the product owner. Once a team is more mature you're able to assess which bits are working for you and what you'd like to change.

Xarn
Jun 26, 2015

Destroyenator posted:

Once a team is more mature you're able to assess which bits are working for you and what you'd like to change.

This is also how you can tell whether a team is doing Agile or agile. Sadly I think its much more common for this to never happen than it is for it to happen.

FlapYoJacks
Feb 12, 2009
What is wrong with gant charts and a simple research -> implementation setup?

Why do companies think they need to reinvent everything?

Bruegels Fuckbooks
Sep 14, 2004

Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

ratbert90 posted:

What is wrong with gant charts and a simple research -> implementation setup?

Why do companies think they need to reinvent everything?

Gantt charts are useless because nobody really knows how long stuff is going to take to implement past a couple of weeks - the chart is also evidence that you don't know what you're talking about because the dates it shows are incorrect. Now if you start calling two weeks periods "sprints" and story points "days", and get rid of the chart, you don't have to move the bars in microsoft project anymore - this saves the project manager time that can be spent doing something more useless like calling useless meetings or drinking.

FlapYoJacks
Feb 12, 2009

Bruegels Fuckbooks posted:

Gantt charts are useless because nobody really knows how long stuff is going to take to implement past a couple of weeks - the chart is also evidence that you don't know what you're talking about because the dates it shows are incorrect. Now if you start calling two weeks periods "sprints" and story points "days", and get rid of the chart, you don't have to move the bars in microsoft project anymore - this saves the project manager time that can be spent doing something more useless like calling useless meetings or drinking.

This makes sense, because I do a lot of project management and I want to call useless meetings WHILE drinking a lot more than I do; however I turn everything into tiny bite sized chunks and make a Gantt chart instead. :smith:

Destroyenator
Dec 27, 2004

Don't ask me lady, I live in beer

Xarn posted:

This is also how you can tell whether a team is doing Agile or agile. Sadly I think its much more common for this to never happen than it is for it to happen.
To be honest it can still be pretty bad even when it does happen. I've seen plenty of places that go from this:

Che Delilas posted:

In particular I'm not fond of the meetings that bookend each sprint - they're long and tiring and in my specific case our product owner is not fully participating, which is kind of a problem. There are reasons, but I know this will need to get addressed or this process won't work.
To not addressing what's actually going wrong, deciding that a particular part of scrum doesn't work for them or doesn't fit the management culture and just dropping it.

I think it's mostly an education thing, scrum has been sold as "do these things, be successful" but most of the value is understanding the issues that those processes are there to solve. Changing your process is okay as long as you know what the original point of the process was for, and you understand how the changes help your team while still achieving the original goals.

Not meaning to pick on you Che Delilas, you do sound like you've got the right idea. If you aren't getting the value you expect out of your ceremonies then that's something to discuss at retrospective, make sure everyone is aware of what you should be achieving there and work together to find a way to make that happen. Maybe you change the process, maybe you just reschedule some of your recurring meetings, maybe you do some of them more ad-hoc when the PO is available (but have a way of tracking/ensuring it happens).

CPColin
Sep 9, 2003

Big ol' smile.
All the other teams are doing sprints, but the team I'm on whined enough during the sprint planning meetings they gave up and let us do Kanban. That lent me a lot of credibility last week when I advocated for delaying the release by a day; our team wasn't rushing to complete a sprint, but every other team was.

We had to do a patch release yesterday, anyway. At least we're getting another unit test out of it.

We did catch some flak a few weeks ago because we weren't moving through our tasks quickly enough, but we flatly rejected the criticism, because we're that mature. (Also because all our recent tasks were "investigate how to build this backend that we don't know any requirements for.")

Che Delilas
Nov 23, 2009
FREE TIBET WEED

Destroyenator posted:

Not meaning to pick on you Che Delilas, you do sound like you've got the right idea...

Don't worry it doesn't sound like you're picking on me. The good news for my situation is that pretty much everyone agrees where the pain points are right now (mainly the product owner). Once we lock down the sprint and get the management out of the picture, it's really great because as Destroyenator said we know exactly what we're going to be working on and it's not going to change for two weeks unless an emergency happens. Mostly (there are certain recurring tasks that a couple devs need to take care of but we did take that into account during planning).

We've already identified things we could be doing better in terms of communication and organization. In my book that's a success already. I honestly don't think we're doing too badly at this considering it's only been a couple sprints and it's the holidays which means people are bouncing in and out more than usual.

Phobeste
Apr 9, 2006

never, like, count out Touchdown Tom, man
It's a bit weird working where I work, because I work on an embedded development team at a full stack from hardware to web company. We have integrations in both directions, and our software folks (including us) are in a different org from our hardware folks. Software has continually tried agile, but for hardware...

For hardware agile works in early development - prototyping, basically. When you're going through a couple rounds of prototyping, it makes a hell of a lot of sense to do Agile, make quick decisions, have limited scope of work, and make choices based on that limited scope, because otherwise you go crazy. The thing is, when it comes to the actual product development phase, this falls completely apart, entirely because of lead times - it's all very well to expect engineers to make a bunch of decisions in two weeks, but then it takes another six to ten to get the parts back. At that point, gantt charts are king.

The thing is, we're caught in the middle, and it's a weird place to be. We help the prototyping, but we're prototyping too - working up quick software to support boards that purposefully will never see production, helping out to write scripts for mechanical prototypes where if we're lucky a third of them will see the light of day - and again, that's exactly how we want it to work on the hardware side. But then, we go into product development mode, and the thing here is that there's a set of non-negotiable features that we basically have to go down the list of. Because basically if we don't get all of them done, the product is useless.

But at the same time, we're supporting existing products by adding new features/functionality/bugfixes/integrations to upstream with the rest of the software/web team, who are all doing Agile, which works really well for them. So we're kind of caught in the middle.

This isn't really a request for help because I know the answer- somebody (not me, I'm just the dev team lead) decides whether that new product launching on time is more important to the business than x y and z random feature, and we do our prioritized work- but more to say, anybody else who's caught between Agile and non-Agile teams, I feel your pain. Significantly.

ChickenWing
Jul 22, 2010

:v:

Phobeste posted:

This isn't really a request for help because I know the answer- somebody (not me, I'm just the dev team lead) decides whether that new product launching on time is more important to the business than x y and z random feature, and we do our prioritized work- but more to say, anybody else who's caught between Agile and non-Agile teams, I feel your pain. Significantly.

My project is actually experiencing this sort of issue as well - our teams are agile, but our backend is still operating waterfall. Thus, when we say "oh we didn't anticipate this in requirements let's ask backend to update real quick" backend says "no changes without a CR and also we're not touching that feature for another three months so uh get hosed I guess?"

Luckily we don't need the backend to touch too many things (and also I have personal involvement in none of them) but from what I've overheard it's an incredibly unfun clusterfuck.

Che Delilas
Nov 23, 2009
FREE TIBET WEED

ChickenWing posted:

My project is actually experiencing this sort of issue as well - our teams are agile, but our backend is still operating waterfall. Thus, when we say "oh we didn't anticipate this in requirements let's ask backend to update real quick" backend says "no changes without a CR and also we're not touching that feature for another three months so uh get hosed I guess?"

Luckily we don't need the backend to touch too many things (and also I have personal involvement in none of them) but from what I've overheard it's an incredibly unfun clusterfuck.

At my company, marketing doesn't know what the gently caress anymore. They keep wanting to do our same billing for features and give customers promises when it comes to delivery dates that they always have. We haven't done a great job of communicating that we need to work WITH the customers (and probably change our contracts so they take this incremental development into account), rather than just saying "we'll see you in X months."

It really is just forcing people to see reality though. It doesn't matter how many months we work on a thing; if we deliver it and they hate it, we're just going to have to make changes and either charge them more (makes the customer hate us), or just fix mistakes and fold that time into the original price we promised (makes the business hate us). I'm really on board with the idea of having the customer be an active part of a continuous feedback loop.

At least we don't have one layer of development roadblocking everything though, that sounds hellacious.

Drythe
Aug 26, 2012


 
My work claims to the death we are agile despite me even giving all our management a presentation over what agile is and how we are not and what we can do to work towards it. We still require the business to give all requirements at the start, refuse to talk to them to clarify anything, only ever do one release of a product, and testing is still only at the end.

We are also trying to force Salesforce to work for everything, including letting the business make their own web apps. To everyone who isn't an idiot's shock, it sucks rear end at doing all of that but they refuse to move on and do real work. Sunk cost fallacy is a hell of a thing.

Fatz
Jul 1, 2011

Drythe posted:

My work claims to the death we are agile despite me even giving all our management a presentation over what agile is and how we are not and what we can do to work towards it. We still require the business to give all requirements at the start, refuse to talk to them to clarify anything, only ever do one release of a product, and testing is still only at the end.

We are also trying to force Salesforce to work for everything, including letting the business make their own web apps. To everyone who isn't an idiot's shock, it sucks rear end at doing all of that but they refuse to move on and do real work. Sunk cost fallacy is a hell of a thing.

We call that "sloganized agile". It usually happens in an old waterfall style development company with alot of lifer middle management. The terms used in agile are substituted in for old existing practices, (i.e. meetings become standups, design specs become user stories, managers become dual product owners/scrum masters because they're just that good...)

..and I work at that company!

Everything's a disaster. The transparency that agile brings to the table was hijacked into micromanagement every morning where managers show up at stand ups and tell everyone they're doing it wrong. The moment a team starts showing any signs of success middle management is threatened so they work to break up the teams. Things have gotten so bad developers are required to fill out secret surveys at the end of a sprint detailing who they thought the best and worst performers on their team were and deliver it straight to management.

We've something called a Definition of Done that must be met before a team can call a user story done. At some point that became optional because "We don't have time." Following that are celebratory emails about how everything was done on time.

I got a scrum master certification out of it, which looks good on a resume but is virtually worthless as an indicator of skill or talent. It was a 2 day course outlining agile and scrum practices, that's about it. No tests to pass, etc.

Fatz fucked around with this message at 17:44 on Jan 10, 2016

Drythe
Aug 26, 2012


 
Mostly everything I've learned here is state government sucks, and I watch as we waste a few million of tax money every time on a software we use for 4 weeks, abandon it, and then keep paying the license for a year. Good thing they pay for all my training through citizen tax dollars that I can then use to leave state government work.

It just bothers me to see so many tax dollars get thrown in the trash. When a company wants to waste its profits, that's fine to me, but idiots keep raising my taxes so they can throw more of it in the trash.

e: They also love security software that doesn't do poo poo, and refuses to believe it was our fault. When you have a 10% cryptowall infection rate, it stopped being the users faults a long time ago. I wonder how much personal information has been leaked to attacks, since SSNs are basically never encrypted and we don't actually look if a system has ever been compromised. I'll just be over here doing more dumb poo poo in Salesforce while they ignore me some more.

I enjoy talking to my friends about it though, since every time I tell them about a system their response is always along the lines of "yea, someone would have gotten fired for that poo poo here".

Drythe fucked around with this message at 14:08 on Jan 11, 2016

Hargrimm
Sep 22, 2011

W A R R E N
Apparently our co-located, very productive team was declared "too large to be AGILE" by the new CTO who has never set foot in this office, so we've been split into two. Nothing like doubling administrative overhead to improve productivity, right?? Now I'm on a wonderful new team with fully half its members 10.5 hours away in India! Huzzah for high-latency communication and 7am meetings! :suicide:

Volguus
Mar 3, 2009

ChickenWing posted:

My project is actually experiencing this sort of issue as well - our teams are agile, but our backend is still operating waterfall. Thus, when we say "oh we didn't anticipate this in requirements let's ask backend to update real quick" backend says "no changes without a CR and also we're not touching that feature for another three months so uh get hosed I guess?"

Luckily we don't need the backend to touch too many things (and also I have personal involvement in none of them) but from what I've overheard it's an incredibly unfun clusterfuck.

But isn't this what should happen? I mean, agile or not, you cannot just come an throw in a new requirement in the backlog (this sprint's backlog no less) and expect that it will get done when you want it to get done. When it's important, sure, team leads, managers, directors, whatevers meet and agree that X and Y get dropped and feature Z gets done instead.

At the end of the day, that's the entire point of agile: "Don't loving bother me with your poo poo today. Wait until planning meeting". Isn't it?

Axiem
Oct 19, 2005

I want to leave my mind blank, but I'm terrified of what will happen if I do

Volguus posted:

At the end of the day, that's the entire point of agile: "Don't loving bother me with your poo poo today. Wait until planning meeting". Isn't it?

Err, no? Agile doesn't proscribe a planning meeting at all, and "responding to change over following a plan" seems to contradict that mentality.

Agile is "hey, we just realized that we have this other thing that's really important to us" and there's a discussion, priorities get reorganized if it makes sense, and you keep going with the new priority list (kanban really helps with this, in my observation). Maybe that means you get the thing when you want, maybe it needs that you have to compete with other people who need things also. That's why you have a face-to-face conversation with the people involved and talk it through.

Che Delilas
Nov 23, 2009
FREE TIBET WEED
He's probably thinking of scrum, which is paradoxically pretty rigid during the sprint. But those sprints are short enough that if priorities do change (and they will), it doesn't screw up big plans and deadlines that were set months ago that are still months away.

And yeah, it's really great to be able to tell a manager that you aren't going to drop everything and do this big mental context switch just because they found a bug. If it's an emergency we'll cancel the sprint but otherwise put it into the product backlog, prioritize it for next sprint, and let me get back to what I'm already working on.

Che Delilas fucked around with this message at 01:20 on Jan 16, 2016

ChickenWing
Jul 22, 2010

:v:

Debugging SpEL is probably going to send me to an early grave

It doesn't help that I'm currently trying to fit an oblong peg in a round hole with it. It's not quite a square peg, but it sure as hell doesn't fit nicely.

Volmarias
Dec 31, 2002

EMAIL... THE INTERNET... SEARCH ENGINES...
I'm getting into serverside programming after about 7 straight years of doing Android.

:iit:

Drythe
Aug 26, 2012


 
Agile means having me cancel my time off and work overtime to get a project done in a week because I'm the only one who knows how to make anything in Salesforce.

The project that we haven't even heard of until yesterday. God it must be nice being able to get a job by sucking Kasich's dick.

Adbot
ADBOT LOVES YOU

ChickenWing
Jul 22, 2010

:v:

Volmarias posted:

I'm getting into serverside programming after about 7 straight years of doing Android.

:iit:

That's a bit of a paradigm shift :stonk: what are you finding to be the hardest part of the transition?

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply