4 ms·

Here’s all you need to know about agile: Individuals and interactions over processes and tools Working software over comprehensive documentation

by Swizec 4y ago

Here’s all you need to know about agile: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Unfortunately in my 10+ years in the industry, I’ve seen few teams do it that way. More often it’s a top-down series of waterfalls masquerading as agile. Agile works. But you have to actually do agile. Yes, it’s hard. You have to hire good people and get out of their way. Trust is key. Let them do the work however they want, it’s gonna be okay. Focus on the outcome, not on feeling in control.

ramesh31 4y ago
>Unfortunately in my 10+ years in the industry, I’ve seen few teams do it that way. More often it’s a top-down series of waterfalls masquerading as agile. Ask any software developer how they work (or would like to work): "Yeah I just do the thing until it's done, then I do the next thing" But this doesn't work for management, so we end up with all of these charades, and we have to play along and talk about how "yeah that would be super helpful to have all of these tickets, and track the progress of our burndown chart, and what's our velocity this sprint compared to last?". It's just a game to play with the company folks put in charge of watching over us doing our thing.
- awb 4y ago
  These deliverables are usually tied to external events with lead times of their own like an ad campaign, new hire, funding, etc. Engineering teams that can more accurately estimate their delivery dates add tangible value to their company.
  - Aeolun 4y ago
    For once it would be nice if they figured out those things can adapt to engineering time too, instead of the other way around.
    - awb 4y ago
      At good companies they do adapt to engineering timelines. But marketing (reasonably) wants to know if an app launch is 4 weeks away or 8 weeks away and what features will be included so they can plan their campaign accordingly. And then there are things that are immovable like a holiday or a legal deadline, where it’s helpful to know the progress and ETA as accurately as possible as early as possible.
      - Swizec 4y ago
        And in case of hard/real deadlines, there is usually opportunity to say “We can’t do X, but can Y be good enough?”. Those are important conversations to have.
      - Aeolun 4y ago
        I realize that, and I’m happy to give estimates. It’s when they expect me to estimate something that fits in the schedule they’ve already decided on that it gets iffy.
        awb 4y ago
        For sure. Time and deliverables are the two concerns. Management can define one and engineering should define the other. If time is defined by management (ex. a Christmas sale), then engineering should estimate which features can be done by then. But I’ve definitely seen clients try to define both the timeline and the scope of work and that’s not a successful outcome for anyone.
- Aeolun 4y ago
  The big problem is that it doesn’t fundamentally change the way you work, which is exactly “Do the thing until it’s done, then do the next thing”. What happens is that you get yanked off the thing halfway through, only to have the same thing happen with a few other things. Then folks ask why there’s 4 unfinished things lying around.
  - jermaustin1 4y ago
    Only 4? I have an order of magnitude higher of unfinished tasks since December 2022 in my queue, and about 150 still assigned to me from all time. This is the life of a boring corporate developer in a highly hub & spoke software company where everyone lives in a vertical that is only allowed to speak to their direct manager. Any time I try to just update the branch to bring it rebase onto current master, I'm pulled into another task that is the highest of high priorities, so high, it can't even be added to TFS, and I must drop everything I'm doing to handle. I will usually get 4-10 phone calls during the task (most take me under a 2 hours) asking for my status, and after the PR is submitted, it will get ignored for a couple of weeks until inevitably there is a merge conflict, so I then need to drop everything I'm doing to handle it. I very rarely get to finish a task in my job without being spirited away for hours, days, weeks, months, or even years before being allowed back on that task.
    - tensionheadx 4y ago
      Wow, thx for those insights! Mostly worked in research and this manifests my darkest nightmares about working for corporations.
Aeolun 4y ago
So far I’m at 3 out of 5. It’s a bit sad that all the good experiences were with companies <200 employees.
- Swizec 4y ago
  > all the good experiences were with companies <200 employees My best experience has been at a hyper growth company that roughly 10x’d in 2 years. The extreme focus on keeping up with demand meant that all manner of bullshit just melted away because nobody had time for that.

by Swizec 4y ago

ramesh31 4y ago

>Unfortunately in my 10+ years in the industry, I’ve seen few teams do it that way. More often it’s a top-down series of waterfalls masquerading as agile. Ask any software developer how they work (or would like to work): "Yeah I just do the thing until it's done, then I do the next thing" But this doesn't work for management, so we end up with all of these charades, and we have to play along and talk about how "yeah that would be super helpful to have all of these tickets, and track the progress of our burndown chart, and what's our velocity this sprint compared to last?". It's just a game to play with the company folks put in charge of watching over us doing our thing.

awb 4y ago
These deliverables are usually tied to external events with lead times of their own like an ad campaign, new hire, funding, etc. Engineering teams that can more accurately estimate their delivery dates add tangible value to their company.
- Aeolun 4y ago
  For once it would be nice if they figured out those things can adapt to engineering time too, instead of the other way around.
  - awb 4y ago
    At good companies they do adapt to engineering timelines. But marketing (reasonably) wants to know if an app launch is 4 weeks away or 8 weeks away and what features will be included so they can plan their campaign accordingly. And then there are things that are immovable like a holiday or a legal deadline, where it’s helpful to know the progress and ETA as accurately as possible as early as possible.
    - Swizec 4y ago
      And in case of hard/real deadlines, there is usually opportunity to say “We can’t do X, but can Y be good enough?”. Those are important conversations to have.
    - Aeolun 4y ago
      I realize that, and I’m happy to give estimates. It’s when they expect me to estimate something that fits in the schedule they’ve already decided on that it gets iffy.
      - awb 4y ago
        For sure. Time and deliverables are the two concerns. Management can define one and engineering should define the other. If time is defined by management (ex. a Christmas sale), then engineering should estimate which features can be done by then. But I’ve definitely seen clients try to define both the timeline and the scope of work and that’s not a successful outcome for anyone.
Aeolun 4y ago
The big problem is that it doesn’t fundamentally change the way you work, which is exactly “Do the thing until it’s done, then do the next thing”. What happens is that you get yanked off the thing halfway through, only to have the same thing happen with a few other things. Then folks ask why there’s 4 unfinished things lying around.
- jermaustin1 4y ago
  Only 4? I have an order of magnitude higher of unfinished tasks since December 2022 in my queue, and about 150 still assigned to me from all time. This is the life of a boring corporate developer in a highly hub & spoke software company where everyone lives in a vertical that is only allowed to speak to their direct manager. Any time I try to just update the branch to bring it rebase onto current master, I'm pulled into another task that is the highest of high priorities, so high, it can't even be added to TFS, and I must drop everything I'm doing to handle. I will usually get 4-10 phone calls during the task (most take me under a 2 hours) asking for my status, and after the PR is submitted, it will get ignored for a couple of weeks until inevitably there is a merge conflict, so I then need to drop everything I'm doing to handle it. I very rarely get to finish a task in my job without being spirited away for hours, days, weeks, months, or even years before being allowed back on that task.
  - tensionheadx 4y ago
    Wow, thx for those insights! Mostly worked in research and this manifests my darkest nightmares about working for corporations.

Aeolun 4y ago

So far I’m at 3 out of 5. It’s a bit sad that all the good experiences were with companies <200 employees.

Swizec 4y ago
> all the good experiences were with companies <200 employees My best experience has been at a hyper growth company that roughly 10x’d in 2 years. The extreme focus on keeping up with demand meant that all manner of bullshit just melted away because nobody had time for that.