|
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. 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.
|
# ? Dec 17, 2015 09:14 |
|
|
# ? Apr 28, 2024 13:18 |
|
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.
|
# ? Dec 17, 2015 09:31 |
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
|
|
# ? Dec 17, 2015 15:16 |
|
ChickenWing posted:At least I'm not worried about not having any work now
|
# ? Dec 17, 2015 15:17 |
|
Our sprints would normally end tomorrow (except for my team, because we're on Kanban ), 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.
|
# ? Dec 17, 2015 21:37 |
|
CPColin posted:Our sprints would normally end tomorrow (except for my team, because we're on Kanban ), 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.
|
# ? Dec 17, 2015 22:02 |
|
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.
|
# ? Dec 17, 2015 23:37 |
|
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?
|
# ? Dec 18, 2015 05:17 |
|
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.
|
# ? Dec 18, 2015 05:46 |
|
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).
|
# ? Dec 18, 2015 08:55 |
|
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
|
# ? Dec 19, 2015 06:57 |
|
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?
|
# ? Dec 23, 2015 04:50 |
|
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".
|
# ? Dec 23, 2015 04:59 |
|
comedyblissoption posted:How are Agile sprints and commitments in a software development context sane in any way? Kanban isn't a project management methodology. It's an apples-to-tractors comparison.
|
# ? Dec 23, 2015 05:05 |
|
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.
|
# ? Dec 23, 2015 05:13 |
|
Ithaqua posted:Kanban isn't a project management methodology. It's an apples-to-tractors comparison.
|
# ? Dec 23, 2015 05:38 |
|
comedyblissoption posted:How are Agile sprints and commitments in a software development context sane in any way? 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.
|
# ? Dec 23, 2015 07:26 |
|
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.
|
# ? Dec 23, 2015 07:46 |
|
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.
|
# ? Dec 23, 2015 11:28 |
|
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.
|
# ? Dec 23, 2015 12:27 |
|
What is wrong with gant charts and a simple research -> implementation setup? Why do companies think they need to reinvent everything?
|
# ? Dec 23, 2015 13:10 |
|
ratbert90 posted:What is wrong with gant charts and a simple research -> implementation setup? 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.
|
# ? Dec 23, 2015 13:43 |
|
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.
|
# ? Dec 23, 2015 14:09 |
|
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. 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. 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).
|
# ? Dec 23, 2015 15:59 |
|
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.")
|
# ? Dec 23, 2015 16:29 |
|
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.
|
# ? Dec 23, 2015 18:06 |
|
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.
|
# ? Dec 27, 2015 07:20 |
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.
|
|
# ? Jan 4, 2016 15:04 |
|
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?" 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.
|
# ? Jan 5, 2016 01:12 |
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.
|
|
# ? Jan 5, 2016 13:16 |
|
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 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 |
# ? Jan 10, 2016 17:31 |
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 |
|
# ? Jan 11, 2016 13:55 |
|
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!
|
# ? Jan 13, 2016 18:20 |
|
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?" 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?
|
# ? Jan 16, 2016 01:02 |
|
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.
|
# ? Jan 16, 2016 01:14 |
|
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 |
# ? Jan 16, 2016 01:17 |
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.
|
|
# ? Jan 21, 2016 15:20 |
|
I'm getting into serverside programming after about 7 straight years of doing Android.
|
# ? Jan 21, 2016 17:36 |
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.
|
|
# ? Jan 21, 2016 19:43 |
|
|
# ? Apr 28, 2024 13:18 |
Volmarias posted:I'm getting into serverside programming after about 7 straight years of doing Android. That's a bit of a paradigm shift what are you finding to be the hardest part of the transition?
|
|
# ? Jan 21, 2016 19:44 |