6 ms·

>Another former employee said that he decided to leave IS&T when he realized “the organization would never truly be able to adopt agile practices such as Scrum

>Another former employee said that he decided to leave IS&T when he realized “the organization would never truly be able to adopt agile practices such as Scrum.” I am curious if anyone in software/IT has successfully lobbied management for a "rollback" of agile development methodology? Anecdote: Last year, I was put on as a tech lead for a project; my boss asked me to use Agile to track and manage the project. I tracked the project's tasks as JIRA tickets, but I did not do morning standup's because I did not think I was going to get buy-in from the rest of my team (my workplace has a 2 day work-from-home policy, common hatred on team for meetings, so it's impossible to have everyone meet in person every weekday consistently due to flex-time). I did not do Sprint planning meeting and ticket estimation (Agile poker cards) because people on my team loved to argue over minutiae's and I strongly suspected half of the team didn't know the details of what the other half is working on; So instead, we had a weekly "flowchart" meeting on a large whiteboard where we brainstormed and added more details to our software project (a big data pipeline lends itself to a flowchart); I found it to be a better visualization of the project than a post-it covered poster. Fortunately for me, I had a much senior technical person in my org also lobby also against Agile. The crux of the argument was Agile wasn't well suited for our team; the sprint model of Agile easily lends itself to arbitrary deadlines and building for the "demo" of the story/epic of that sprint and build-up of tech-debt (e.g., build a demo for one sprint, spent next 3 sprints fixing bugs for the features of the first sprint). In the end, management relented and we ended our Agile experiment. Project tracking is done in Google Doc's with milestones instead. I am curious to hear if there are pushbacks in other places against Agile since it is now the de-facto "industry best-practice" (which means consulting should soon come up with newer set of workshops/manifesto's for a "new best-practice).

JabavuAdams 11y ago
The first place I was introduced to Scrum was at Transgaming. They managed to have a daily scrum across two locations, using only speakerphone. So ... the meeting itself is doable. Not sure about the rest.
RandallBrown 11y ago
Just because you weren't doing SCRUM™ doesn't mean you aren't being agile. The whole point of Agile is to be able to respond to change and make better software. It's good to read the agile manifesto every once in awhile to remind you of what agile really means. http://agilemanifesto.org http://agilemanifesto.org
- lr4444lr 11y ago
  Beat me to it! It's amazing how easily we can get so mired in the jargon and products built around a certain conception of "agile" that we lose sight of the core principles, even to the point of violating them completely.
- noname123 11y ago
  Thanks RandallBrown for teaching me the distinction. SCRUM is the methodology of morning standup's, poker playing cards while Agile is the ideal to which the techniques aspire to achieve.
julian_1 11y ago
> I did not do morning standup's because I did not think I was going to get buy-in from the rest of my team Standup is expressly designed to function as a substitute for meetings - and to avoid the situation where employees waste time in meetings where only 10% of the meeting content is relevant to their particular domain/work. The reason individuals are required to stand, is so that there's a slight physical discomfort in order that people report quickly (ours are about 1 minute per person). If there's some topical convergence on a bit of work that emerges from standup that requires further elaboration and communication between members - then the idea is that those team-members will be able to self-organize a meeting outside standup. The key benefit is that noone else on the team needs to be distracted with things that don't concern them. It really puzzles me, that so few seem to comprehend the basic principles behind Agile workflow.
- chris_wot 11y ago
  How do you do standup with a remote workforce?
  - mindcrime 11y ago
    Don't be overly literal, and use a conference call, Google Hangout, etc. If time zone differences prevent even that, do a "virtual standup" using email, wiki, blog, or whatever you have available.
    - chris_wot 11y ago
      How is that different to a meeting? I'm not an agile practitioner, so apologies if I've missed something important.
      - mindcrime 11y ago
        The thing about the "standups" in Agile, (and Scrum in particular) is that they're supposed to be about intra-team communication. They're not status reports for management, etc. in particular. The goal is to share with your colleages what you're working on, what you're about to work on, what issues you're having, etc., in order to make sure everybody is on the same page and to eliminate misunderstandings. If you have a remote team and people can't meet F2F, you can accomplish the same end using something like I mentioned above. You lose a little something if people are in different time-zones because it makes the whole thing more asynchronous, but you do what you have to do to accommodate your circumstances. Remember, one of the tenets of the Agile Manifesto involves not having rigid adherence to strict ceremony for ceremony's sake (I'm paraphrasing a bit). "Figure out what works for your team, and do that" is kinda how I'd summarize the whole thing.
lr4444lr 11y ago
Agile Manifesto (http://www.agilemanifesto.org/principles.html http://www.agilemanifesto.org/principles.html): >I did not do Sprint planning meeting and ticket estimation (Agile poker cards) because people on my team loved to argue over minutiae's and I strongly suspected half of the team didn't know the details of what the other half is working on; So instead, we had a weekly "flowchart" meeting on a large whiteboard where we brainstormed and added more details to our software project (a big data pipeline lends itself to a flowchart); I found it to be a better visualization of the project than a post-it covered poster. Principle #5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. > The crux of the argument was Agile wasn't well suited for our team; the sprint model of Agile easily lends itself to arbitrary deadlines and building for the "demo" of the story/epic of that sprint and build-up of tech-debt Principle #7: Working software is the primary measure of progress >In the end, management relented and we ended our Agile experiment. Project tracking is done in Google Doc's with milestones instead Principle #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Presuming that you're delivering more responsively and quickly to the customer than you were before, which you didn't mention, it sounds like you're doing just fine with Agile.
- noname123 11y ago
  Thanks lr4444lr for highlighting and aligning the various principles the Agile manifesto with the minutiae details of the project I described. I definitely see your point (which I interpret as Agile is not a set of rigid techniques but one can adapt a team's makeup and culture to whatever will make software people feel motivated/empowered to do the work and have quick responsive/iterative cycles with the customer folks). >Presuming that you're delivering more responsively and quickly to the customer than you were before, which you didn't mention In the interest of full disclosure, I think we had a project time over-run of 2x (estimated 4 months to 8 months) mainly due to "feature creep" (is that a feature or a bug in Agile iterative cycles?); the project is a high-throughput data pipeline for genome sequencing and annotation. We overran time as a case of our customers/users wanted to add more bells and whistles to the tail end of the pipeline as they saw the end product more and more and proposed more added steps.
nl 11y ago
You appear to be conflating Scrum with Agile, avoiding doing any Scrum-like practices and avoided the clear communication problems within your team ("I strongly suspected half of the team didn't know the details of what the other half is working on"). And then you say your Agile experiment didn't work. the sprint model of Agile easily lends itself to arbitrary deadlines and building for the "demo" of the story/epic of that sprint "Sprints" isn't Agile, it's Scrum (See for example Kanban). and build-up of tech-debt (e.g., build a demo for one sprint, spent next 3 sprints fixing bugs for the features of the first sprint). That is the complete opposite of anything that any kind of agile process would recommend. To be honest, given that you don't know the difference between Scrum and Agile I think it's fair to say you don't know what you are talking about. I'm no fan of pure Scrum. I think it's an overly ceremonial approach to building software and the ceremonial aspects of it lead to a cargo-cult like mindset, where people concentrate on the process rather than the reasons why things are done. But Agile as a general approach works well, and a properly run Scrum process isn't a bad place to start.
- noname123 11y ago
  Thanks nl for your thoughtful feedback! I'll follow up to all your reply threads here. I think you pointed out my negligence in not dealing with "communication problems" on my team, "weak leadership" for not putting my foot down (not prioritizing the backlog of the project and thus making the project delivery date late), avoiding morning standup's completely instead adapting and adjusting a good process on the fly (ensuring that everyone during their updates are succinct); and finally just my plain ignorance in what is the simple distinction between Scrum and Agile is, all points duly noted :) (And being honest, I don't agree with 100% of your criticism; but I do take to heart all of them and will try to work on improve on those specific things you brought up in terms of project management skills in the future!) Although I think we disagree on what is a good project management methodology for software, I think at least we can agree on the fact that having a proper lead to run the project irrespective of the project methodology is really important.
  - douchescript 11y ago
    Agile/scrum defense arguments are like a doomsday sects defenses for why dd didn't happen, everybody didn't believe enough. Now if all would believe...

JabavuAdams 11y ago

The first place I was introduced to Scrum was at Transgaming. They managed to have a daily scrum across two locations, using only speakerphone. So ... the meeting itself is doable. Not sure about the rest.

RandallBrown 11y ago

Just because you weren't doing SCRUM™ doesn't mean you aren't being agile. The whole point of Agile is to be able to respond to change and make better software. It's good to read the agile manifesto every once in awhile to remind you of what agile really means. http://agilemanifesto.org http://agilemanifesto.org

lr4444lr 11y ago
Beat me to it! It's amazing how easily we can get so mired in the jargon and products built around a certain conception of "agile" that we lose sight of the core principles, even to the point of violating them completely.
noname123 11y ago
Thanks RandallBrown for teaching me the distinction. SCRUM is the methodology of morning standup's, poker playing cards while Agile is the ideal to which the techniques aspire to achieve.

julian_1 11y ago

> I did not do morning standup's because I did not think I was going to get buy-in from the rest of my team Standup is expressly designed to function as a substitute for meetings - and to avoid the situation where employees waste time in meetings where only 10% of the meeting content is relevant to their particular domain/work. The reason individuals are required to stand, is so that there's a slight physical discomfort in order that people report quickly (ours are about 1 minute per person). If there's some topical convergence on a bit of work that emerges from standup that requires further elaboration and communication between members - then the idea is that those team-members will be able to self-organize a meeting outside standup. The key benefit is that noone else on the team needs to be distracted with things that don't concern them. It really puzzles me, that so few seem to comprehend the basic principles behind Agile workflow.

chris_wot 11y ago
How do you do standup with a remote workforce?
- mindcrime 11y ago
  Don't be overly literal, and use a conference call, Google Hangout, etc. If time zone differences prevent even that, do a "virtual standup" using email, wiki, blog, or whatever you have available.
  - chris_wot 11y ago
    How is that different to a meeting? I'm not an agile practitioner, so apologies if I've missed something important.
    - mindcrime 11y ago
      The thing about the "standups" in Agile, (and Scrum in particular) is that they're supposed to be about intra-team communication. They're not status reports for management, etc. in particular. The goal is to share with your colleages what you're working on, what you're about to work on, what issues you're having, etc., in order to make sure everybody is on the same page and to eliminate misunderstandings. If you have a remote team and people can't meet F2F, you can accomplish the same end using something like I mentioned above. You lose a little something if people are in different time-zones because it makes the whole thing more asynchronous, but you do what you have to do to accommodate your circumstances. Remember, one of the tenets of the Agile Manifesto involves not having rigid adherence to strict ceremony for ceremony's sake (I'm paraphrasing a bit). "Figure out what works for your team, and do that" is kinda how I'd summarize the whole thing.

lr4444lr 11y ago

Agile Manifesto (http://www.agilemanifesto.org/principles.html http://www.agilemanifesto.org/principles.html): >I did not do Sprint planning meeting and ticket estimation (Agile poker cards) because people on my team loved to argue over minutiae's and I strongly suspected half of the team didn't know the details of what the other half is working on; So instead, we had a weekly "flowchart" meeting on a large whiteboard where we brainstormed and added more details to our software project (a big data pipeline lends itself to a flowchart); I found it to be a better visualization of the project than a post-it covered poster. Principle #5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. > The crux of the argument was Agile wasn't well suited for our team; the sprint model of Agile easily lends itself to arbitrary deadlines and building for the "demo" of the story/epic of that sprint and build-up of tech-debt Principle #7: Working software is the primary measure of progress >In the end, management relented and we ended our Agile experiment. Project tracking is done in Google Doc's with milestones instead Principle #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Presuming that you're delivering more responsively and quickly to the customer than you were before, which you didn't mention, it sounds like you're doing just fine with Agile.

noname123 11y ago
Thanks lr4444lr for highlighting and aligning the various principles the Agile manifesto with the minutiae details of the project I described. I definitely see your point (which I interpret as Agile is not a set of rigid techniques but one can adapt a team's makeup and culture to whatever will make software people feel motivated/empowered to do the work and have quick responsive/iterative cycles with the customer folks). >Presuming that you're delivering more responsively and quickly to the customer than you were before, which you didn't mention In the interest of full disclosure, I think we had a project time over-run of 2x (estimated 4 months to 8 months) mainly due to "feature creep" (is that a feature or a bug in Agile iterative cycles?); the project is a high-throughput data pipeline for genome sequencing and annotation. We overran time as a case of our customers/users wanted to add more bells and whistles to the tail end of the pipeline as they saw the end product more and more and proposed more added steps.

nl 11y ago

You appear to be conflating Scrum with Agile, avoiding doing any Scrum-like practices and avoided the clear communication problems within your team ("I strongly suspected half of the team didn't know the details of what the other half is working on"). And then you say your Agile experiment didn't work. the sprint model of Agile easily lends itself to arbitrary deadlines and building for the "demo" of the story/epic of that sprint "Sprints" isn't Agile, it's Scrum (See for example Kanban). and build-up of tech-debt (e.g., build a demo for one sprint, spent next 3 sprints fixing bugs for the features of the first sprint). That is the complete opposite of anything that any kind of agile process would recommend. To be honest, given that you don't know the difference between Scrum and Agile I think it's fair to say you don't know what you are talking about. I'm no fan of pure Scrum. I think it's an overly ceremonial approach to building software and the ceremonial aspects of it lead to a cargo-cult like mindset, where people concentrate on the process rather than the reasons why things are done. But Agile as a general approach works well, and a properly run Scrum process isn't a bad place to start.

noname123 11y ago
Thanks nl for your thoughtful feedback! I'll follow up to all your reply threads here. I think you pointed out my negligence in not dealing with "communication problems" on my team, "weak leadership" for not putting my foot down (not prioritizing the backlog of the project and thus making the project delivery date late), avoiding morning standup's completely instead adapting and adjusting a good process on the fly (ensuring that everyone during their updates are succinct); and finally just my plain ignorance in what is the simple distinction between Scrum and Agile is, all points duly noted :) (And being honest, I don't agree with 100% of your criticism; but I do take to heart all of them and will try to work on improve on those specific things you brought up in terms of project management skills in the future!) Although I think we disagree on what is a good project management methodology for software, I think at least we can agree on the fact that having a proper lead to run the project irrespective of the project methodology is really important.
- douchescript 11y ago
  Agile/scrum defense arguments are like a doomsday sects defenses for why dd didn't happen, everybody didn't believe enough. Now if all would believe...