3 ms·

The main problems I’ve seen are: - followed as a religion, especially when it doesn’t make sense (daily stand up for a team working in the same room and collab

The main problems I’ve seen are: - followed as a religion, especially when it doesn’t make sense (daily stand up for a team working in the same room and collaborating all day long? One day lost every 2 week for planning and review? Trying to do a stand up with too many people?) - using it as an excuse to not prepare the project and without clear objective - trying to fit agile in a fixed schedule (like trying to sync with a big marketing release, complete with pre reserved tv spot 1 year in advance) - not listening to the final customer - heck, not even making sure he’s interested - trying to complexity it by adding a lot of metrics (financial is a big one) - making estimate as the law

agos 4y ago
I don't want to say "no true scotsman", but agile has no requirements on stand ups, schedules, or estimates.
- pydry 4y ago
  Agile has always been extremely vague about what it is. This is at the heart of the problem. This allows everyone to project their own desires on to it - from CEO to PM to programmer to consultant. I get why this happened - the original consultants probably felt that defining it in a way that would alienate people (especially leaders with the budget to hire them) wouldnt be good business. Nonetheless it led to all this. Scrum was almost worse - an attempt to be specific and regimented about process without being alienating which is how I ended up working on a project for BigBank where they asked for N story points to be delivered per month in the contract. Ideally Id like to see some new sort of movement X that follows the heart of what agile is and isnt afraid to get specific in a way that would alienate a CEO/pm with waterfall/controlling tendencies. This way I could ask in a job interview if the companies does X or agile and get a clearer answer about wtf they do.
  - kthejoker2 4y ago
    The manifesto isn't vague. It's an opionated set of criteria preferences for evaluating ways of working (on software.) You can easily uncover in an job interview if they honor those preferences. * How is the customer involved in shaping the software? Give specific examples. * Who decides what will be developed? Where does my role fit in? * Will I be able to ship production code my first week? (Why not?) Et cetera. Even better: come up with your own manifesto of preferences for ways of working. And then score potential employers and your teams against them.
    - pydry 4y ago
      I first realized the problem when somebody hit me with: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." and "Individuals and interactions over processes and tools" to argue that writing code comments, tests and documentation wasnt worth investing in when we can all just talk. This was after a series of disasters that code comments, tests and documentation would all have helped with. It's perhaps hard to imagine that this would be controversial but it was - the fact it was 10 years ago and we were under pressure to deliver can perhaps partly explain why. Try as I might I couldnt argue that his interpretation was wrong. I stared at the words and was shocked when I realized that it was actually perfectly valid. I have my own understanding of "good agile" and no doubt a lot of developers share it after many decades of good experiences and bad experiences and it arguably means putting processes and tools over individuals and interactions some of the time - like using a linter/autoformatter over arguing about formatting. I dont know what we need but probably it looks a lot more like an updated version of the joel score than the vague soft focus angel tinged* crap that is the agile manifesto. For what it's worth, I think your list is also a bit vague. * I swear that the of the agile manifesto web design was also stolen from a baptist church.
      - meheleventyone 4y ago
        The following on bit from those statements is: “That is, while there is value in the items on the right, we value the items on the left more.” So your colleagues view was a pretty extreme one compared to the moderation shown there. But like any philosophy you end up with fundamentalists taking things too far even in the face of reality being more complex. It’s terrifyingly dogmatic to argue from scripture rather than pragmatics.
        pydry 4y ago
        I dont think it was dogmatism. I think they genuinely didnt think we had time to write tests, etc. and when I argued that we should do it to be more "agile" because we'd all committed to being agile up front (in theory) they googled what the principles and said "look, thats not what agile says". I agree that arguing from scripture is awful. I havent tried to do it since. I would like to see some other sort of anti-waterfall set of principles that I could get behind though.
Cederfjard 4y ago
You can follow agile methodologies while working on a fixed schedule, but if the timeframe isn’t flexible, then the scope needs to be. Fill up the backlog, prioritize it by importance, and what’s done by the deadline is what’ll be delivered. If you get work done reliably and at a consistent pace while tracking velocity or throughput, you can use that data to get an idea of what you’ll manage to deliver.

agos 4y ago

I don't want to say "no true scotsman", but agile has no requirements on stand ups, schedules, or estimates.

pydry 4y ago
Agile has always been extremely vague about what it is. This is at the heart of the problem. This allows everyone to project their own desires on to it - from CEO to PM to programmer to consultant. I get why this happened - the original consultants probably felt that defining it in a way that would alienate people (especially leaders with the budget to hire them) wouldnt be good business. Nonetheless it led to all this. Scrum was almost worse - an attempt to be specific and regimented about process without being alienating which is how I ended up working on a project for BigBank where they asked for N story points to be delivered per month in the contract. Ideally Id like to see some new sort of movement X that follows the heart of what agile is and isnt afraid to get specific in a way that would alienate a CEO/pm with waterfall/controlling tendencies. This way I could ask in a job interview if the companies does X or agile and get a clearer answer about wtf they do.
- kthejoker2 4y ago
  The manifesto isn't vague. It's an opionated set of criteria preferences for evaluating ways of working (on software.) You can easily uncover in an job interview if they honor those preferences. * How is the customer involved in shaping the software? Give specific examples. * Who decides what will be developed? Where does my role fit in? * Will I be able to ship production code my first week? (Why not?) Et cetera. Even better: come up with your own manifesto of preferences for ways of working. And then score potential employers and your teams against them.
  - pydry 4y ago
    I first realized the problem when somebody hit me with: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." and "Individuals and interactions over processes and tools" to argue that writing code comments, tests and documentation wasnt worth investing in when we can all just talk. This was after a series of disasters that code comments, tests and documentation would all have helped with. It's perhaps hard to imagine that this would be controversial but it was - the fact it was 10 years ago and we were under pressure to deliver can perhaps partly explain why. Try as I might I couldnt argue that his interpretation was wrong. I stared at the words and was shocked when I realized that it was actually perfectly valid. I have my own understanding of "good agile" and no doubt a lot of developers share it after many decades of good experiences and bad experiences and it arguably means putting processes and tools over individuals and interactions some of the time - like using a linter/autoformatter over arguing about formatting. I dont know what we need but probably it looks a lot more like an updated version of the joel score than the vague soft focus angel tinged* crap that is the agile manifesto. For what it's worth, I think your list is also a bit vague. * I swear that the of the agile manifesto web design was also stolen from a baptist church.
    - meheleventyone 4y ago
      The following on bit from those statements is: “That is, while there is value in the items on the right, we value the items on the left more.” So your colleagues view was a pretty extreme one compared to the moderation shown there. But like any philosophy you end up with fundamentalists taking things too far even in the face of reality being more complex. It’s terrifyingly dogmatic to argue from scripture rather than pragmatics.
      - pydry 4y ago
        I dont think it was dogmatism. I think they genuinely didnt think we had time to write tests, etc. and when I argued that we should do it to be more "agile" because we'd all committed to being agile up front (in theory) they googled what the principles and said "look, thats not what agile says". I agree that arguing from scripture is awful. I havent tried to do it since. I would like to see some other sort of anti-waterfall set of principles that I could get behind though.

Cederfjard 4y ago

You can follow agile methodologies while working on a fixed schedule, but if the timeframe isn’t flexible, then the scope needs to be. Fill up the backlog, prioritize it by importance, and what’s done by the deadline is what’ll be delivered. If you get work done reliably and at a consistent pace while tracking velocity or throughput, you can use that data to get an idea of what you’ll manage to deliver.