|
Sinten posted:Management consulting + "Agile" = Project Manager -> Scrum Master -> Captain Business Owner -> Product Owner -> Navigator Process -> Sprint -> Exploration Journey Target product -> Epic -> Land Ahoy! / Discover New Land Project Exception -> Impediment -> Rough Seas etc Now create a bunch of cool slides, allow everyone to dress up if they want to and let the money flow in. I call it "Discovery Development: Agile Exploration for Software Sailors". It needs more boat and shipping terms in there, but I am not that much into this kind of thing but can probably crowdsource some of this to the forums.
|
#
?
Aug 10, 2019 07:33
|
|
|
|
| # ? May 11, 2024 15:47 |
|
|
https://luis-goncalves.com/sailboat-exercise-sailboat-retrospective/ It's a common retrospective exercise.
|
|
#
?
Aug 10, 2019 08:35
|
|
|
Carbon dioxide posted:It's a common retrospective exercise.
|
|
#
?
Aug 10, 2019 11:21
|
|
|
Vulture Culture posted:Knowing how to spot interesting and actionable patterns in messy, potentially unstructured data is a vastly different discipline and skillset from what people have traditionally called a statistician I'm going to be a data artist when I grow up.
|
|
#
?
Aug 10, 2019 11:40
|
|
|
I wonder at what point we'll stop using bullshit metaphors and just admit that, as a whole, we have no idea how to efficiently develop software.
|
|
#
?
Aug 10, 2019 20:19
|
|
|
Protocol7 posted:I wonder at what point we'll stop using bullshit metaphors and just admit that, as a whole, we have no idea how to efficiently develop software.
|
|
#
?
Aug 10, 2019 23:06
|
|
|
Vulture Culture posted:This is a lie, but efficient methods are so context-dependent and not whatsoever generalizable I’m just being a facetious rear end in a top hat. I dog on SAFe a lot but it did a good job fixing the problem with my previous employer, being that pretty much every department worked independently of the others, and as much of a pain in the rear end PI Planning was, it was still valuable. It has its own problems but contextually it did solve a big problem with that company. Really, though, I think the people are more important than the methodology, because if people aren’t willing to play along it’ll eventually grind the whole system to a halt. But for me, playing along means following the methodology, but I’m not going to enjoy a fluff meeting with someone trying to dish out an awkward metaphor. We aren’t all sailors on a ship or climbers trying to reach the apex of a mountain or something.
|
|
#
?
Aug 11, 2019 00:03
|
|
|
Protocol7 posted:We aren’t all sailors on a ship That is because you company did not buy the premium package of "The Seas"(tm) yet!
|
|
#
?
Aug 11, 2019 00:35
|
|
|
this seems okay: https://basecamp.com/shapeup
|
|
#
?
Aug 11, 2019 00:39
|
|
|
The problem isn't how to build good software. The problem is how to get the business people on board with what it takes to build good software.
|
|
#
?
Aug 11, 2019 01:46
|
|
|
the talent deficit posted:this seems okay: ultrafilter posted:The problem isn't how to build good software. The problem is how to get the business people on board with what it takes to build good software.
|
|
#
?
Aug 11, 2019 05:51
|
|
|
ultrafilter posted:The problem isn't how to build good software. The problem is how to get the business people on board with what it takes to build good software. And there you have the reason for a lot of methodologies. Not to help devs write better software but to get business on board by hiring consulting that will implement some methodology over the "just what I say today" way of working.
|
|
#
?
Aug 11, 2019 07:00
|
|
|
the talent deficit posted:this seems okay: I fear the problem is in personnel. No matter how clearly a successful organization can identify and describe what works wonders for them - it works for them because of the people that are executing it, not because the methodology itself is profound.
|
|
#
?
Aug 11, 2019 07:37
|
|
|
There's nothing really unique about how software development projects fail (relative to other industries) except the specific project management dialect used.
|
|
#
?
Aug 11, 2019 08:25
|
|
|
Cuntpunch posted:I fear the problem is in personnel. No matter how clearly a successful organization can identify and describe what works wonders for them - it works for them because of the people that are executing it, not because the methodology itself is profound. Distilling further: "Successful companies hire the right people for how the company works." Sounds about right.
|
|
#
?
Aug 11, 2019 08:55
|
|
|
Keetron posted:Distilling further: "Successful companies hire the right people for how the company works." Not really, though. Successful companies try to continue to succeed with the people that stay after they have been hired based on past practices and successes. Every new hire might or might not stay, and might or might not influence how the company works. "The company" isn't an unchangeable entity, and being "successful" is not a permanent guarantee. Culture, cultural fit, success, and methodologies only ever exist at a point in time. Hiring "the right people" based on your current success might or might not lead to further success.
|
|
#
?
Aug 11, 2019 12:43
|
|
|
I've always thought that the big problem is that all the agile methodologies are designed to solve problems at the team level with short time spans, but companies need to think at a large level with long horizons and contractual deadlines, and one's figured out how integrate agile at that level. Some companies use SAFE, some use OKRs, and some use this thing where three times a year everyone throws out agile and "plans" every story you want to do. That's my favorite.
|
|
#
?
Aug 11, 2019 23:43
|
|
|
Hollow Talk posted:Hiring "the right people" based on your current success might or might not lead to further success. Even then, "the right people" can change at the drop of a hat. Putting someone on a new team could improve or worsen their performance based on so many team-specific factors alone. I've seen it myself, I had a coworker who was thriving on one team, moved to a different team to work on newer and "cooler" things, his performance tanked, and then he got canned.
|
|
#
?
Aug 12, 2019 01:31
|
|
|
Protocol7 posted:Even then, "the right people" can change at the drop of a hat. Putting someone on a new team could improve or worsen their performance based on so many team-specific factors alone. Oh hey look it's me whenever someone assigns me to do front end or serverside, things I'm not good at!
|
|
#
?
Aug 12, 2019 02:15
|
|
|
Volmarias posted:Oh hey look it's me whenever someone assigns me to do front end or serverside, things I'm not good at! What are you then, some kind of middleware man?
|
|
#
?
Aug 12, 2019 03:07
|
|
|
Teams also decide to change. The team I'm on isn't really working on the things that were planned and discussed with me last year before I joined. I'm going to work on a few interesting things here in the next month or two, but after that I don't know if there will be much left. They're supposed to have an 18 month plan ready soon, which will at least establish 6mo of projects and/or focus, so I'm hoping to know by the end of this month if I'm working within my current team or taking to managers about doing other things inside this org. ... Or talking to other entirely different groups within or without the company.  Lately I've been thinking that effective software development teams would be nothing more than consultants with short term individual ownership of delivery. Small modification or reconfiguration would be permitted, but there would be no endless refactoring and rebuilding. Code that doesn't solve a problem would simply be thrown out as unmaintainable, inextensible, etc. Any code that isn't modular enough would be dropped as "poor design". Everything in production use would be "this should do one thing well and here's the interface". Of course there are a handful of things that benefit from optimized, compiled, tightly coupled components, but it seems like most big balls of mud are too tightly coupled and don't provide those benefits (nor need to in most applications), instead just serving to over-complicate support and maintenance of the product.
|
|
#
?
Aug 12, 2019 03:15
|
|
|
lifg posted:I've always thought that the big problem is that all the agile methodologies are designed to solve problems at the team level with short time spans, but companies need to think at a large level with long horizons and contractual deadlines, and one's figured out how integrate agile at that level. Some companies use SAFE, some use OKRs, and some use this thing where three times a year everyone throws out agile and "plans" every story you want to do. That's my favorite. But OKRs are also agnostic to the underlying methodology used to structure work. They focus on delivering measurable results and avoid prescription of how teams are organized, what critical paths look like, how work is done or how far in the future it's planned/estimated. Their initial A-list proponent was Andy Grove at Intel, who as a hardware business were not particularly known for their embrace of agile methodologies.
|
|
#
?
Aug 12, 2019 04:10
|
|
|
PhantomOfTheCopier posted:Lately I've been thinking that effective software development teams would be nothing more than consultants with short term individual ownership of delivery. Small modification or reconfiguration would be permitted, but there would be no endless refactoring and rebuilding. Code that doesn't solve a problem would simply be thrown out as unmaintainable, inextensible, etc. Any code that isn't modular enough would be dropped as "poor design". Everything in production use would be "this should do one thing well and here's the interface". PhantomOfTheCopier posted:Of course there are a handful of things that benefit from optimized, compiled, tightly coupled components, but it seems like most big balls of mud are too tightly coupled and don't provide those benefits (nor need to in most applications), instead just serving to over-complicate support and maintenance of the product.
|
|
#
?
Aug 12, 2019 04:23
|
|
|
Vulture Culture posted:All the balls of mud I've worked on grew organically out of systems that did the opposite: they were too modular, ambitious, and aspirationally architected, to the point where it was easier to build a feature the wrong way by bolting it somewhere it didn't belong, because that thing supplied some of the scaffolding or plumbing already, as opposed to purpose-building a thing to just do the loving job. And then people are afraid to refactor when they recognize a part is bolted on wrong because they are unsure how to get the time for that.
|
|
#
?
Aug 12, 2019 05:53
|
|
|
Volmarias posted:Oh hey look it's me whenever someone assigns me to do front end or serverside, things I'm not good at! Rubellavator posted:What are you then, some kind of middleware man? I just saw a recruiter post this on linkedin and thought of this exchange.  I think the worst part for me is that it was posted by someone from a well respected talent/recruiting agency over here.
|
|
#
?
Aug 12, 2019 11:27
|
|
|
Keetron posted:And then people are afraid to refactor when they recognize a part is bolted on wrong because they are unsure how to get the time for that.
|
|
#
?
Aug 12, 2019 12:11
|
|
|
Rubellavator posted:What are you then, some kind of middleware man? I do Android development, preferably the more under the covers stuff. I'll touch UI stuff as needed, but it's not my preference or my forte. I'm happy to let someone else write the backend for me. So, yeah, I guess Middleware isn't the worst way to describe it?
|
|
#
?
Aug 12, 2019 12:40
|
|
|
Volmarias posted:Oh hey look it's me whenever someone assigns me to do front end or serverside, things I'm not good at! I mean, I mostly write microcontroller firmware, which end am I working on?
|
|
#
?
Aug 12, 2019 13:06
|
|
|
Vulture Culture posted:I mostly agree with the general sentiment that most cosmetic refactors (i.e. not to support a known upcoming product need) are like unplugging and redoing a patient's IVs because the tubes look messy at a distance Not if the tubes are tangled in a way that would cut off the supply if not addressed. Ask my about the mobile app my company spent ~1 year designing that does not look good.
|
|
#
?
Aug 12, 2019 13:33
|
|
|
Vulture Culture posted:OKRs really don't solve this class of problem well at all. They perform best in cases where there's a quantifiable goal that people can make tiny needle-shifts towards. My favorite example from the John Doerr book was when Susan Wojcicki talked about setting a four-year company OKR for YouTube of a billion hours in daily user watch time. It was a clear, actionable metric, and anyone who had an idea was empowered to act on it in order to increase eyeballs and user engagement. This worked because it was iterating on an established core value proposition in a way that anyone could get behind. When you have a major initiative that's operating as a feature factory for the fulfillment of distant contracts, how would you structure that OKR? Everything's destined to become a sales metric. You're probably right. It was John Doerr's book that led me to think that some companies are using them well to lead hundreds of smaller agile teams.
|
|
#
?
Aug 12, 2019 13:57
|
|
|
Spring Heeled Jack posted:Ask my about the mobile app my company spent ~1 year designing that does not look good. My last company spent a year and a bit, 28 sprints or so, building an app that in the end looked like every Babby's First Material Design App tutorial. I think the original estimate was 7 sprints. That whole project was a shitshow, actually. They spent about £1m on it because they hired an expensive digital agency based in London to do the brunt of the work, despite being a software company with a dev team on staff. All it had to do was scan barcodes and post some data to an API, then show the user some details about the product they scanned. The agency was charging us £500+ per day per dev, which for London I guess isn't unreasonable, but most of the devs we got had never worked with C# or .Net before, so they kept asking us extremely basic questions. None of the contractors stayed on the project for longer than a couple of months, some of them would pick up extremely small tickets and spend two weeks on it with no progress at all, and in one case we had a "Senior" contractor working with us, who'd only been a developer for around a year. One agency dude giving progress presentations to the managers started writing the "X tickets not done" thing in green so it'd look slightly better at a glance. When we finally released it (and moved onto something else), the first B2B customer to touch it found so many showstopper bugs they threatened to break the contract and stop working with us entirely. Cue organizational panic, lots of "how could this happen?" and a drop-everything-else, three-month firefighting session loosely organised into sprints where every ticket was basically the Product Owner pasting a link to a crash report on our logging tool. About 6 months later they made us redundant, saying there were "too many long-distance communication issues" since we were based a couple of hours away from them. They've been trying to hire a new dev team for about 8 months now I think, and as far as I know, they only have a dev manager, one dev, and two contractors to fill the gaps because they're offering not-London salaries in a very commutable-to-London area.
|
|
#
?
Aug 12, 2019 14:22
|
|
|
Volmarias posted:I do Android development, preferably the more under the covers stuff. I'll touch UI stuff as needed, but it's not my preference or my forte. I'm happy to let someone else write the backend for me. I guess you could call that application layer/service layer. Middleware in a web app is generally a bridge between layers - an example of middleware I've worked on is token authentication middleware so that the developers of individual web apps in our own enterprise app don't have to roll their own authentication, they just call my methods in startup and voila, we all authenticate using token auth without them having to worry about authentication themselves.
|
|
#
?
Aug 12, 2019 14:30
|
|
|
Bruegels Fuckbooks posted:I guess you could call that application layer/service layer. I'm aware of what middleware is, and yes service layer or app layer is a better description, but it was also a joke. feedmegin posted:I mean, I mostly write microcontroller firmware, which end am I working on? Is your micro controller a web service, or is it a GUI?
|
|
#
?
Aug 12, 2019 14:58
|
|
|
Hell is that one coworker who always replies to multiple-recipient email threads by walking over to your office and giving a verbal update, no matter how many times you remind them to please reply-all to the email so everybody's in the loop.
|
|
#
?
Aug 12, 2019 16:45
|
|
|
CPColin posted:Hell is that one coworker who always replies to multiple-recipient email threads by walking over to your office and giving a verbal update, no matter how many times you remind them to please reply-all to the email so everybody's in the loop. That, or the remote equivalent of a direct message reply in Slack. 
|
|
#
?
Aug 12, 2019 17:52
|
|
|
Bonus points for someone replying to an email far back in the chain hours after the email has already been replied to, splitting the email chain into a fork of unintelligible thoughts.
|
|
#
?
Aug 12, 2019 23:08
|
|
|
Vulture Culture posted:There's no objective valuation of what "one thing well" even means as a cultural value. Why should the bulk of software design be based on subjective cultural values? Priority of requests can certainly be established via such subjective or statistical measures, but functionality is a matter for objectivity. You're not getting code approved that just doesn't work, independent of what you might claim as your cultural value. quote:"Designs" are accumulations of point-in-time tradeoffs that hopefully amount to something comprehensible. quote:Doing one thing well implies doing everything else poorly One of us hasn't passed this way before. I'm not sure which way or where, but I'm certain we've arrived at different places.
|
|
#
?
Aug 12, 2019 23:22
|
|
|
quote:Why should the bulk of software design be based on subjective cultural values? Priority of requests can certainly be established via such subjective or statistical measures, but functionality is a matter for objectivity. You're not getting code approved that just doesn't work, independent of what you might claim as your cultural value. lol
|
|
#
?
Aug 12, 2019 23:51
|
|
|
CPColin posted:Hell is that one coworker who always replies to multiple-recipient email threads by walking over to your office and giving a verbal update, no matter how many times you remind them to please reply-all to the email so everybody's in the loop. Now a different coworker just called me back because a spreadsheet I emailed them didn't look right. I apologized that I don't know the system involved well enough to know off the top of my head what the problem is. They said, "Okay, I'll call Coworker B and ask about it, because it sounds like this task needs to be reassigned." I clarified to please email the two of us, because I can't troubleshoot this stuff over the phone. They said okay and hung up. Two seconds later, I hear Coworker B's phone ring in the next office over. gently caress off. Edit: Coworker B wasn't at their desk when the phone rang, but Coworker A must've sent an email, because B just closed their door and called back. Bet I'll hear more about this soon and it'll have a fun extra layer because I've told my boss several times that I didn't think it made sense for me to be even handling running these reports in the first place. Sounds like B is getting annoyed on the phone, so maybe I'm in the clear. CPColin fucked around with this message at 00:16 on Aug 13, 2019 |
|
#
?
Aug 13, 2019 00:03
|
|
|
|
| # ? May 11, 2024 15:47 |
|
|
Protocol7 posted:Bonus points for someone replying to an email far back in the chain hours after the email has already been replied to, splitting the email chain into a fork of unintelligible thoughts. Replying to correct an earlier error or provide relevant information is desirable. The bad part is how crap email is.
|
|
#
?
Aug 13, 2019 00:21
|
|
