|
necrobobsledder posted:I think that sales-eng is probably a far more important dynamic and culture overall than so-called devops. Honest truth. My studio is just me and one other guy and we're both direct contact with clients, sometimes with a design agency between. We've gotten confident enough in our digital process that we know how to knock back proposed projects with poorly defined specs. Instead we push for workshops of 3-4 hrs with the client, that allows us to unearth hidden assumptions and give us enough material with which to estimate the project. Because velocity isn't exactly a stable concept when you're switching projects and they're all short lived (100-250 hrs), we just make our points match up with half hours estimated to be spent on a particular feature. Then when we progress through the job we can map points % completed to budget % spent (we only provide hour estimates, not fixed priced quotes). This way we can also show direct impact to project completion when new stuff gets requested on the board, because story rejections that involve incremental details are added as a new story instead of recycling on the same story. All of this in the service of exposing the realities of development to the ones requesting features & paying the budget. It's not pure agile but we look at it less as a dogma and more as part of our toolbox to facilitate customer communication. But I think it all comes back to development being given access to stakeholders, proper access, ability to discuss, people who know how to dig to the bottom of specifications til there's enough of a framework that you won't be surprised. Sounds like waterfall but we really don't see it that way, because we're still amenable to change, we just expose it and make the impacts of change clear, while ensuring the big ideas are largely understood before we proceed.
|
#
?
Jan 1, 2017 21:58
|
|
|
|
| # ? May 10, 2024 03:46 |
|
|
Che Delilas posted:There was some whining from the product owner about tasks being on the board for such a long time, as if he expected vague epics to get done in two weeks just because we were doing two week sprints. But we haven't been officially reprimanded for not getting things done or anything like that. I think that's partly because we do make lots of incremental progress on our tasks (they're just huge epic tasks so at the high-level overview of the product roadmap it doesn't look like it moves very fast). That doesn't sound too bad. Management that has any grasp of what to avoid doing that would push away the guys who won't have any issues finding better work is decent enough. The underwater problem usually explodes for us not internally but externally when the client has been either over promised or is simply unreasonable. That shouldn't involve Developers, but we inevitable get pulled in to talk said client off the cliff because no one else really understands the product.
|
|
#
?
Jan 1, 2017 23:40
|
|
|
My preferred way is WIP limits for Scrum and Kanban for teams with large amount of support contingencies but that still deliver projects do so in a Kanban style with a velocity burn down.
|
|
#
?
Jan 2, 2017 01:22
|
|
|
Pollyanna posted:That is the broken down version. What I end up doing is looking at the parent story and writing down the requirements/my own breakdown in the ticket before I work on it, just so people aren't like "BUT I EXPECTED THIS" because I constantly run into that problem and am extremely sick of it. Scrum is used when your company has recently decided that the whole "agile" thing is a good idea and hired a bunch of consultants to give everyone planning poker cards. Kanban is used when scrum is not working for your company because it doesn't have enough of an attention span to group stuff into sprints/split user stories into sprint-sized chunks/complete work in time boxed sprints. As near as I can tell, Kanban involves stacking a bunch of tasks into a queue, prioritizing them, and continuing to execute until you run out of tasks, but still filling in the same reports and calling stuff sprints. It's like being a Mennonite instead of being Amish - you dress the same way, but don't quite do all the crazy stuff the consultants tell you to do. Keep in mind I've never worked a place where doing scrum didn't seem like getting paid to play Dungeons and Dragons, so maybe there are like true believers?
|
|
#
?
Jan 2, 2017 06:04
|
|
v (But we still do Scrum because management is absolutely terrified of not having numbers and estimates and things to judge worth, value, and performance with.)
|
I know Kanban doesn't have many rules per se, so it's hard to even do it wrong, but every implementation described on these last two pages sounds like an abomination. The idea is to visualize the entire flow of a piece of functionality and to make sure there's a shared responsibility between biz/dev/ops to pull it through as quickly as possible. If the problem is that not enough stories are ready than that is exactly what Kanban will make visible (you do need to have an agreed upon Definition of Ready). Kanban isn't going to solve the problem for you though. Again, that's the shared responsibility of everyone involved in the process.
|
|
#
?
Jan 2, 2017 08:43
|
|
|
Messyass posted:I know Kanban doesn't have many rules per se, so it's hard to even do it wrong, but every implementation described on these last two pages sounds like an abomination.
|
|
#
?
Jan 2, 2017 15:18
|
|
|
Vulture Culture posted:Anecdotally, having fewer rules seems to make it easier to do it wrong, because you not only need to exercise discipline, you also need good judgment. You can't rely on someone else's canned process to save you. I love the (perhaps unintentional and unfair) implication that you actually can rely on scrum to do this for you
|
|
#
?
Jan 2, 2017 16:59
|
|
|
Steve French posted:I love the (perhaps unintentional and unfair) implication that you actually can rely on scrum to do this for you
|
|
#
?
Jan 2, 2017 17:43
|
|
|
Do you point bugs or not? We have not but our new product owner wants to because they can't get a sense of what will actually be delivered if people work on bugs and that delays stories.
|
|
#
?
Jan 4, 2017 02:16
|
|
|
smackfu posted:Do you point bugs or not? We have not but our new product owner wants to because they can't get a sense of what will actually be delivered if people work on bugs and that delays stories. Yes. Bugs should be prioritized, given point estimates, and assigned to sprints. Ideally, the product owner will agree that bugs come first and that they shouldn't be delayed just to get more new features, especially since bugs tend to beget more bugs and make it harder to implement new features in the first place.
|
|
#
?
Jan 4, 2017 02:26
|
|
|
New Yorp New Yorp posted:Yes. Bugs should be prioritized, given point estimates, and assigned to sprints. Ideally, the product owner will agree that bugs come first and that they shouldn't be delayed just to get more new features, especially since bugs tend to beget more bugs and make it harder to implement new features in the first place. We're trying a thing where product gives us their priorities and we then inject stuff we know needs to happen into that list where we think it should go and then pull from that. We will then have a brutal cage match to agree on the final sprint goal. Note that this does not mean we're taking the same amount of tasks from the product team and just piling on more poo poo, product priorities are getting sacrificed as we decide that this bug or piece of technical debt is more important. So far it seems to be going pretty well; we're getting stuff into the sprint that circumstances were forcing us to do (and therefore not just faking it by committing to extremely light sprints just to leave time for us to do "non-sprint work"). Product hasn't bitched at us for not getting enough features into the sprint (yet; we'll see what happens when we try to make the argument that we can't get any features into a sprint because of our crippling technical debt that we simply cannot let sit anymore, that'll be a fun day). Interested to see where this goes.
|
|
#
?
Jan 4, 2017 03:27
|
|
|
My team assigns all bugs story point values of zero on the grounds that they represent work left over from the original story. Since this work belongs to that ticket, their story point value has already been captured in that ticket. This is a stupid system that doesn't do anything except reduce the quality of our metrics.
|
|
#
?
Jan 4, 2017 03:30
|
|
|
Makeout Patrol posted:My team assigns all bugs story point values of zero on the grounds that they represent work left over from the original story. Since this work belongs to that ticket, their story point value has already been captured in that ticket. This is a stupid system that doesn't do anything except reduce the quality of our metrics. It also intrinsically encourages crunch. You have 40 new story points and 10 bug points to do when 40 hour weeks get you 40 points of velocity. Guess everyone needs to do 50 hours this sprint to meet the story goals!
|
|
#
?
Jan 4, 2017 05:25
|
|
|
Makeout Patrol posted:This is a stupid system that doesn't do anything except reduce the quality of our metrics. This should really be the thread title
|
|
#
?
Jan 4, 2017 06:17
|
|
|
New Yorp New Yorp posted:Yes. Bugs should be prioritized, given point estimates, and assigned to sprints.
|
|
#
?
Jan 4, 2017 10:55
|
|
|
Sagacity posted:How do you give a point estimate to a bug if you're not even sure what's causing the bug? Don't those estimates end up being glorified timeboxes? You can base the estimate on how long it's taken to track down and resolve bugs in that system or systems of similar complexity in the past. Type of error can factor in as well. All estimates are glorified time boxes?
|
|
#
?
Jan 4, 2017 12:23
|
|
|
leper khan posted:All estimates are glorified time boxes? 
|
|
#
?
Jan 4, 2017 12:48
|
|
|
Makeout Patrol posted:My team assigns all bugs story point values of zero on the grounds that they represent work left over from the original story. Since this work belongs to that ticket, their story point value has already been captured in that ticket. This is a stupid system that doesn't do anything except reduce the quality of our metrics. I had a manager who did this for a while. He thought we should do it out of a sense of "pride in our work". For being someone who loved to talk about being a "rational actor" all the time, he sure didn't understand the concept of perverse incentives, and kept insisting that the team would "just take care of" stuff that wasn't being rewarded and was in some cases actively being punished. For example, "bugs" were filed by the support team, so fixing them required talking with the support team and occasionally the original user, which occasionally took days to resolve to support's satisfaction. Then we would get chewed out at our weekly velocity meeting about why we weren't meeting our goals.
|
|
#
?
Jan 4, 2017 14:32
|
|
|
The tricky bit is that sometimes the people suggesting zero point bugs are also suggesting that bugs should be extremely rare. That most things that passed acceptance criteria should only have features to change them, not bugs. So in that environment, bug points are not that important and whether they are zero on principle or given points doesn't really matter. It's not much of an answer to a project owner who says, "if I prioritize a lot of bugs this week, that makes the contents of this sprint completely incorrect???"
|
|
#
?
Jan 4, 2017 15:04
|
|
|
But if you have zero-point bugs and your velocity goes down because of that, isn't that then a valid metric as well? I mean, it shows you're spending more and more time fixing bugs than actually working on stories, which seems like a very useful indication that somewhere in the development process (not necessarily development) something is not going as planned. You shouldn't be chastised for the drop in velocity obviously, that makes little sense.
|
|
#
?
Jan 4, 2017 17:19
|
|
|
Zero points bugs??? If I gotta fix a bug, and it's in my sprint, it's getting a point estimate.
|
|
#
?
Jan 4, 2017 17:23
|
|
|
Sagacity posted:But if you have zero-point bugs and your velocity goes down because of that, isn't that then a valid metric as well? I mean, it shows you're spending more and more time fixing bugs than actually working on stories, which seems like a very useful indication that somewhere in the development process (not necessarily development) something is not going as planned. It's trivial to look at points from bugs vs points from stories in basically every tool used to track that kind of thing. Effort spent on bugs is still effort, and it should still be tracked and understood for sprint planning purposes. Your velocity isn't actually dropping when bugs are being fixed. If the team typically completes 100 points of work in a sprint but is spending 20% of their time fixing bugs, their velocity is still 100, regardless of where the effort is being expended.
|
|
#
?
Jan 4, 2017 17:24
|
|
|
Sagacity posted:You shouldn't be chastised for the drop in velocity obviously, that makes little sense. Right, that's where the whole thing breaks down. If you have a metric, (most) management is going to reward that metric more than something without a number attached. Even without explicit rewards/punishments, people will work to a metric more if given the choice, because it's public and visible. It's incentivized. And that means it will be gamed. In this case, the best way to get the "Points" to go up was to do greenfield development on stories that had lax acceptance criteria. You can imagine what the quality of the code looked like with this as the sole metric. Bugs, tech debt, and other "non-productive" code quality stories should absolutely be given equal points as feature development. Then priorities can be set accordingly.
|
|
#
?
Jan 4, 2017 18:12
|
|
|
Sagacity posted:But if you have zero-point bugs and your velocity goes down because of that, isn't that then a valid metric as well? I mean, it shows you're spending more and more time fixing bugs than actually working on stories, which seems like a very useful indication that somewhere in the development process (not necessarily development) something is not going as planned. Velocity should be treated like a closely guarded secret that must never be released outside the scrum team. If you let the secret out, it will become useless.
|
|
#
?
Jan 4, 2017 19:26
|
|
|
The core problem is that you have people who want to measure and quantize something you can't measure and quantize. Development is a creative process with a gently caress ton of variables. The boss wants a hard set of numbers but actual developers know that you can give estimates at best. There is just no simple measure of anything.
|
|
#
?
Jan 4, 2017 19:44
|
|
|
Me and my team have been able to mostly quantize the dev process. It's not as shoot from the hip creative as I used to think. There is still blurryness, but it can be made small enough to be tolerable. My process goes: 1) Spec gets delievered 2) Spec gets evaluated by dev, questions clarified, etc 3) Spec should be in a spot where it is estimatable. This is still high level here, but it can be estimated. My estimates can range from as small as 30 minutes to days, depending on how blurry the thing is I'm doing 4) Spec estimates get approved and broken up into smaller chunks 5) When a task gets brought into the sprint, it gets thought through enough to break it into 3 hour or less chunks. A big helper for getting clarity on blurry stuff is that a blurry task usually needs research and design before it can be implemented, so that is another task (or tasks) in of themselves. e.g. If I have a 1 day long task - that means its very blurry. I can at least break that up into 3 hrs of research, 3 hours of design, 3 hours of implementation and 1 to 2 hours of writing tests.
|
|
#
?
Jan 4, 2017 19:54
|
|
|
I have to say, for work related stuff, this thread is one of the best on the forums if only because it keeps me mindful of what developers go through when they're interacting with anyone outside of their immediate team.
|
|
#
?
Jan 4, 2017 21:02
|
|
|
After that year of lobbying for a job title change to "Senior Java Architect" and winning the "Technology Leader" award at the company party, which I told my boss I wouldn't attend because failing to get an annual award every year makes me feel bad, the company decided they didn't need an architect after all! I did it, everybody! 
|
|
#
?
Jan 4, 2017 21:25
|
|
|
Cool, I got fired for cryptic reasons today too 
|
|
#
?
Jan 4, 2017 21:44
|
|
|
|
|
#
?
Jan 4, 2017 21:46
|
|
|
smackfu posted:The tricky bit is that sometimes the people suggesting zero point bugs are also suggesting that bugs should be extremely rare. That most things that passed acceptance criteria should only have features to change them, not bugs. So in that environment, bug points are not that important and whether they are zero on principle or given points doesn't really matter. The one blaring alarm in my head when I started learning about Agile methodologies came from this idea, that bugs were going to be very rare. My first question was basically, "that's nice but what about the real world?" In an ideal situation you might be able to get close to that but how often do you get "ideal?" I'll just go ahead and treat bugs like they exist and require work.
|
|
#
?
Jan 5, 2017 03:19
|
|
|
Che Delilas posted:In an ideal situation you might be able to get close to that but how often do you get "ideal?" I'll just go ahead and treat bugs like they exist and require work.
|
|
#
?
Jan 5, 2017 03:55
|
|
|
Every bug happens because a previous story was done wrong. If this happened because it was accepted when it should not have been, then the effort spent on "fixing" it is actually additional effort correctly implementing a rejected story. If it's like that, there's a case to be made that the bug should not be estimated, because the ensuing reduction in velocity is actually accurate - it really did take that amount of time to do it right, and consistently measuring it that way will account for the friction introduced by inevitable human errors. This carries the caveat that it takes a very disciplined organization to process that information effectively; it can exacerbate the consequences of existing bad incentive structures, to say nothing of the complications introduced by prioritization. On the other hand, if the bug is something that was not touched on in the original story, then it's better thought of as an expansion of the scope of that story. That means it merits re-estimation, and the difference between the original estimate and the new one might as well be applied to the bug itself. Most teams are probably better off estimating bugs. I mean, ultimately, like everything else, it comes down to "Why is this being measured?" Bongo Bill fucked around with this message at 04:21 on Jan 5, 2017 |
|
#
?
Jan 5, 2017 04:17
|
|
|
Yea, you are right about that fixing broken past mistakes and promissies could be theoretically billed to past stories, and should be charged at 0 currency now to address BUT IF I DID THAT I WOULD NEVER GET ANYWHERE. NEITHER WOULD MY TEAM My whole life is addressing past mistakes! That's where the inspiration for my best features comes from. Every feature should be billed as an exponential debt to past mistakes!
|
|
#
?
Jan 5, 2017 04:54
|
|
|
Sometimes bugs also come up because that one library when updated decided not to play nicely with that one other library. Or that one hack you did that got everything working 100% of the time at that time turns out to only be 99% effective two months later. Other times you had a tight deadline coming up so you cobbled together anything that works as desired. Hell other times a hardware upgrade makes everything explode. Other times it's just plain ol' human error. Making bugs "very rare" is a pipe dream for anything more complex than a hello world. Anybody who believes bugs can be totally prevented or eliminated doesn't understand what programmers do. A significant chunk of what programmers do is fix inevitable bugs.
|
|
#
?
Jan 5, 2017 04:58
|
|
|
Agile gets even wonkier when you mix in operations work trying to keep a site reliable and healthy while features are being deployed rapid-fire. Sometimes it manifests in a bug, but the effort to research and discover it is oftentimes lost - wtf does that count as then? In pathological cases, engineers will work hard fixing numerous bugs or helping unblock others due to poor comprehensibility of the codebase, getting zero credit for the effort necessary to do even basic tasks, and being summarily fired for fixing the problems caused by others that kept their heads down rather than addressing fires burning in front of them - this literally happened to a guy I worked with. Without following or adequately addressing Deming's 14 points of quality management, I've seen most places regress to the negative social tendencies that drove an organization to "go Agile" in the first place precisely because most low-performing organizations do not practice any of the points. Agile does almost nothing to stop people from breaking all of the principles, so it does not address quality of output by a group of people whatsoever. Adding extra stakeholders might address the one part about eliminating barriers between people, but half the time that's not even Agile, it's (enterprise) devops.
|
|
#
?
Jan 5, 2017 05:33
|
|
|
Also, scaling problems, for example. Maybe not a bug, but also not a user story? But running into a scaling issue doesn't mean the story for the feature that is no longer scaling was done "wrong" since it may have been an entirely correct and reasonable approach to the problem when originally built. Unless you're of the opinion that tech debt is never worth incurring and everything should be built to scale as much as it'll ever possibly have to from step 1.
|
|
#
?
Jan 5, 2017 05:37
|
|
|
Obviously your PO needs to enter an epic to update your stuff to support a certain scale of operation, which will then get broken down, sized, prioritized and assigned to sprints as appropriate for the business!
|
|
#
?
Jan 5, 2017 07:26
|
|
|
Just stop estimating effort, unless it is to make an honest decision whether to deliver a certain feature or not. And in that case demand that at least the same amount of energy is devoted to estimating the value of the feature.
|
|
#
?
Jan 5, 2017 08:43
|
|
|
|
| # ? May 10, 2024 03:46 |
|
|
This last page I am seriously lost if people are being serious, sarcastic or ironic.
|
|
#
?
Jan 5, 2017 10:22
|
|
