8 ms·

By the time a business believes that a “solution provider” is not the same type of person hired for the technical implementation, the battle is already lost and

by mlthoughts2018 8y ago

By the time a business believes that a “solution provider” is not the same type of person hired for the technical implementation, the battle is already lost and you should leave. The idea of wanting to work in these situations as consultant or software engineer is all pretty crazy. For example, Scrum is a pretty stupid and horrible thing, at least as stupid and horrible as Waterfall and often quite worse. Anybody who thinks it’s important to give consulting advice about whether to adopt Scrum is someone to run away from. It’s like a daisycutter of common sense. There are great, small places to work where you can be paid well _and_ have your technical opinion respected and considered as an implementer. You can’t do that in places that are brainfucked with politics and bureaucracy, and the willingness to hire outside “solutions” consultants is a pretty big indicator that a place is brainfucked with bureaucracy and politics.

adrianN 8y ago
Some people work to make money. If providing solutions to bureaucracies pays well, why not do it?
- mlthoughts2018 8y ago
  I was already assuming that was the goal here. Not talking about seeking creative control, idealism about a job, etc.
- saiya-jin 8y ago
  Most people work to make money, even in IT, even in software development. If you don't believe this, stop paying them and lets see who comes next day. Working in bureaucracy is great indicator/training ground for patience, and not really caring about meaningless things in life and instead focusing on those with true meaning. Yes, it wouldn't be work in that case. 'All we need is just a little patience...' music in the background
rumok 8y ago
I'm genuinely curious, why do you believe scrum to be "stupid and horrible"?
- mlthoughts2018 8y ago
  Many years of experience with it across orgs of various sizes and ages. One-size-fits-all software management and metrics about planning and velocity are things that exist to give middle management surface area to tell whatever political blame/credit stories they want, and have not got shit to do with productivity, adjusting to change, or delivering anything. And don’t even get me started on why Agile is emphatically and unequivocally not a different thing than Scrum itself.
  - TomMarius 8y ago
    From my personal experience with scrum in an enterprise environment, I agree with you completely.
  - goodpoint 8y ago
    I've been in many companies including famous ones and I never seen scrum or agile deliver any value. It's just optics.
  - coldtea 8y ago
    For one, Scrum is pure cargo cult. As a field we simply don't have actual scientific research on these methodologies (just some joke papers that are as good as toss coin).
  - beatgammit 8y ago
    No single methodology is right for everyone, but lean principles tend to be a better fit for most. And that's really what Agile and Scrum are. The most important thing for teams is to establish a rapid feedback loop, and make sure someone is tasked with handling that data. Once you know your customers' needs, you can act to resolve them. If you're using a waterfall approach, you can miss the window, which delays your ability to get changes in front of customers, which delays feedback and increases the chance that you're wasting time. Before we adopted an Agile-inspired process, we had several projects get scrapped after weeks or months of work because we misunderstood the customer's problem. When we adopted a new process, we built smaller MVPs (took days instead of weeks) and got customer feedback that indicated we needed to make a shift. Many of our features got smaller because we didn't get time to over-engineer them. The major flaw, IMO, is technical debt. Our product is released on a schedule, but we get feedback from users with alpha products, so we have time to clean up the implementation once we get hands-on feedback from customers. If we adopted Agile 100%, we likely would rack up more technical debt, and I've actually seen this happen in that same company as management made changes (I became trainer and technical lead instead of project manager). If you drink too much of the kool aid, you'll get a stomach ache.
ljm 8y ago
Just to pick on the example a little bit (understanding it's not your main point). A scrum consultant would have most likely failed at the first step anyway, because a consultant is going to sell scrum as a tried and tested, repeatable offering, and all it takes is to implement the framework. That's not how 'organisational transformation' works at all, but the process piece is easily marketable and looks exactly like a checklist you can tick off item by item: standup? check. Sprint review? check. Jira? check. Self-empowered teams and servant leaders? Errrr, that's not on the list! Retrospectives? Hesitant check. It takes a lot more effort to shift habits, empower teams, and reframe leadership expectations, and you need coaching and mentorship to make that happen. That's where the real work is once you've read the scrum framework instruction manual. So on that level I can understand why scrum might seem so dreadful. I've dealt with enough of that kind of crap myself and it's stressful, but I've seen it done brilliantly too and it's been a fantastic way to work.

adrianN 8y ago

Some people work to make money. If providing solutions to bureaucracies pays well, why not do it?

mlthoughts2018 8y ago
I was already assuming that was the goal here. Not talking about seeking creative control, idealism about a job, etc.
saiya-jin 8y ago
Most people work to make money, even in IT, even in software development. If you don't believe this, stop paying them and lets see who comes next day. Working in bureaucracy is great indicator/training ground for patience, and not really caring about meaningless things in life and instead focusing on those with true meaning. Yes, it wouldn't be work in that case. 'All we need is just a little patience...' music in the background

rumok 8y ago

I'm genuinely curious, why do you believe scrum to be "stupid and horrible"?

mlthoughts2018 8y ago
Many years of experience with it across orgs of various sizes and ages. One-size-fits-all software management and metrics about planning and velocity are things that exist to give middle management surface area to tell whatever political blame/credit stories they want, and have not got shit to do with productivity, adjusting to change, or delivering anything. And don’t even get me started on why Agile is emphatically and unequivocally not a different thing than Scrum itself.
- TomMarius 8y ago
  From my personal experience with scrum in an enterprise environment, I agree with you completely.
- goodpoint 8y ago
  I've been in many companies including famous ones and I never seen scrum or agile deliver any value. It's just optics.
- coldtea 8y ago
  For one, Scrum is pure cargo cult. As a field we simply don't have actual scientific research on these methodologies (just some joke papers that are as good as toss coin).
- beatgammit 8y ago
  No single methodology is right for everyone, but lean principles tend to be a better fit for most. And that's really what Agile and Scrum are. The most important thing for teams is to establish a rapid feedback loop, and make sure someone is tasked with handling that data. Once you know your customers' needs, you can act to resolve them. If you're using a waterfall approach, you can miss the window, which delays your ability to get changes in front of customers, which delays feedback and increases the chance that you're wasting time. Before we adopted an Agile-inspired process, we had several projects get scrapped after weeks or months of work because we misunderstood the customer's problem. When we adopted a new process, we built smaller MVPs (took days instead of weeks) and got customer feedback that indicated we needed to make a shift. Many of our features got smaller because we didn't get time to over-engineer them. The major flaw, IMO, is technical debt. Our product is released on a schedule, but we get feedback from users with alpha products, so we have time to clean up the implementation once we get hands-on feedback from customers. If we adopted Agile 100%, we likely would rack up more technical debt, and I've actually seen this happen in that same company as management made changes (I became trainer and technical lead instead of project manager). If you drink too much of the kool aid, you'll get a stomach ache.

ljm 8y ago

Just to pick on the example a little bit (understanding it's not your main point). A scrum consultant would have most likely failed at the first step anyway, because a consultant is going to sell scrum as a tried and tested, repeatable offering, and all it takes is to implement the framework. That's not how 'organisational transformation' works at all, but the process piece is easily marketable and looks exactly like a checklist you can tick off item by item: standup? check. Sprint review? check. Jira? check. Self-empowered teams and servant leaders? Errrr, that's not on the list! Retrospectives? Hesitant check. It takes a lot more effort to shift habits, empower teams, and reframe leadership expectations, and you need coaching and mentorship to make that happen. That's where the real work is once you've read the scrum framework instruction manual. So on that level I can understand why scrum might seem so dreadful. I've dealt with enough of that kind of crap myself and it's stressful, but I've seen it done brilliantly too and it's been a fantastic way to work.