3 ms·

I see a lot of people using "agile" and Scrum™ interchangeably. Am I just a deluded fool, or is the agile manifesto completely ignored in practice? People talk

I see a lot of people using "agile" and Scrum™ interchangeably. Am I just a deluded fool, or is the agile manifesto completely ignored in practice? People talk about "agile methodology" and I wonder "doesn't the manifesto explicitly reject all 'methodologies'?". I thought that was the point. The manifesto is pretty short already but more or less I understand it as " do what makes sense to you". It's open to interpretation, but that's the whole reason for its existence. If companies think there's a magic book or a system to rigidly define "what makes sense" for all teams on all projects, and that such a system can/should be purchased if only the idiots working for them would just follow the rules, they're doomed anyway.

pcurve 11y ago
I agree 100%. I work in a big corporate environment. The problem with Agile is, it doesn't seem to work in a big corporate environment that loves the followings: 1. Ability to plug and play bodies (PM, Dev, BA, offshore/outsource) 2. Having those bodies held accountable individually 3. Predictable process over progress or quality. 4. Layers of management.
- VLM 11y ago
  With the minor correction that #1 also applies to divisions (east coast office vs west coast office) and cross shift (3rd shift ops has the same written procedures and instincts or whatever as 2nd or 1st shift ops). Programming is a young profession. On the other hand, design and engineering and automation are old, and the giants got that way by following pcurve's list, more or less, not by inventing or implementing Agile. Therefore the higher people go in management and therefore the more abstracted they get get from the front line, the more likely they are to completely uninterested in Agile, as that's just not how big companies are run, even if it works for a ten person startup. So there's going to be a push from the top to call it whatever you want but when you interface with the exec suite you'll talk in terms of micromanaged waterfall because that's how we build jet engines here, or mining machines, or run a worldwide communications system, or whatever.
gregmac 11y ago
I think you're bang-on. The trouble is approaching it as if it is some prescriptive methodology, where you can implement the processes and magically you're "agile". It doesn't help that several books, blogs and consultants try to convince you this is the case. The reality is that agile is a philosophy, and there are some processes (like Scrum describes) that happen work well with it: but if you don't embrace the philosophy, the processes won't do anything. This sounds a bit hand-wavey, but it has parallels to software itself: if you fix bugs without understanding their cause, you're doomed to keep "fixing" the same bugs over and over (since you're just fixing the symptoms). Likewise, if someone makes a feature request "I need a button here", and you just put a button where they ask without first asking "why?" and understanding the need, you end up building the wrong things and wasting everyone's time and money. Personally, I'd say the most important things about implementing an agile process that seem to me to be the cause of many people's problems with agile are: * Implement retrospectives, with the power granted to the team to change the process in whatever way makes sense * Stop building systems or components, and start thinking about everything as user stories Retrospectives are where you define YOUR agile process. When we started at my company, I think we did some fairly significant changes to our process at every retro for the few months, and often when someone new joins the team, process changes start coming up at retros again. Building User stories is what really breaks out agile from waterfall. You still have to define the system to some degree (to have a sane architecture), but you don't have to actually build it. "As an administrator, I need to be able to create a new user" can be fully implemented before any code to edit or delete the user is written. Like most things, this is of course not black and white: if you don't define the system as a whole enough, you'll rewrite every feature over and over, or have an un-maintainable mess. However, do it properly, and you get working (if incomplete, from a market perspective) software faster. The real benefit comes from doing the most risky things first, getting user feedback, and failing fast. You don't want to find out that the data model you built can't support the insertion speed you need and needs to be changed after you've already started to build the reporting UI.
slavik81 11y ago
I absolutely agree. Whenever this topic comes up for discussion in programmer circles, I see comments along the lines of 'Agile is pointless. It doesn't matter whether you use Agile process or not. Good people can make just about any system work.' But, that's part what the agile manifesto says! Perhaps it should be quoted more: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
Zigurd 11y ago
Agile doesn't abjure methodology, and most working Agile teams use scrum-style meetings and kanban-style task tracking. But the first line of the Agile Manifesto says: >Individuals and interactions over processes and tools Which implies a few things, not least the default excuse for failed Agile-managed projects: "You did not have the right people." Well, duh. With the rightest people you can transcend any methodology. Conversely, piling on the process won't save your ass if you have the wrong people. You have to have good people using good tools, and the wisdom to know if that's good enough.

pcurve 11y ago

I agree 100%. I work in a big corporate environment. The problem with Agile is, it doesn't seem to work in a big corporate environment that loves the followings: 1. Ability to plug and play bodies (PM, Dev, BA, offshore/outsource) 2. Having those bodies held accountable individually 3. Predictable process over progress or quality. 4. Layers of management.

VLM 11y ago
With the minor correction that #1 also applies to divisions (east coast office vs west coast office) and cross shift (3rd shift ops has the same written procedures and instincts or whatever as 2nd or 1st shift ops). Programming is a young profession. On the other hand, design and engineering and automation are old, and the giants got that way by following pcurve's list, more or less, not by inventing or implementing Agile. Therefore the higher people go in management and therefore the more abstracted they get get from the front line, the more likely they are to completely uninterested in Agile, as that's just not how big companies are run, even if it works for a ten person startup. So there's going to be a push from the top to call it whatever you want but when you interface with the exec suite you'll talk in terms of micromanaged waterfall because that's how we build jet engines here, or mining machines, or run a worldwide communications system, or whatever.

gregmac 11y ago

I think you're bang-on. The trouble is approaching it as if it is some prescriptive methodology, where you can implement the processes and magically you're "agile". It doesn't help that several books, blogs and consultants try to convince you this is the case. The reality is that agile is a philosophy, and there are some processes (like Scrum describes) that happen work well with it: but if you don't embrace the philosophy, the processes won't do anything. This sounds a bit hand-wavey, but it has parallels to software itself: if you fix bugs without understanding their cause, you're doomed to keep "fixing" the same bugs over and over (since you're just fixing the symptoms). Likewise, if someone makes a feature request "I need a button here", and you just put a button where they ask without first asking "why?" and understanding the need, you end up building the wrong things and wasting everyone's time and money. Personally, I'd say the most important things about implementing an agile process that seem to me to be the cause of many people's problems with agile are: * Implement retrospectives, with the power granted to the team to change the process in whatever way makes sense * Stop building systems or components, and start thinking about everything as user stories Retrospectives are where you define YOUR agile process. When we started at my company, I think we did some fairly significant changes to our process at every retro for the few months, and often when someone new joins the team, process changes start coming up at retros again. Building User stories is what really breaks out agile from waterfall. You still have to define the system to some degree (to have a sane architecture), but you don't have to actually build it. "As an administrator, I need to be able to create a new user" can be fully implemented before any code to edit or delete the user is written. Like most things, this is of course not black and white: if you don't define the system as a whole enough, you'll rewrite every feature over and over, or have an un-maintainable mess. However, do it properly, and you get working (if incomplete, from a market perspective) software faster. The real benefit comes from doing the most risky things first, getting user feedback, and failing fast. You don't want to find out that the data model you built can't support the insertion speed you need and needs to be changed after you've already started to build the reporting UI.

slavik81 11y ago

I absolutely agree. Whenever this topic comes up for discussion in programmer circles, I see comments along the lines of 'Agile is pointless. It doesn't matter whether you use Agile process or not. Good people can make just about any system work.' But, that's part what the agile manifesto says! Perhaps it should be quoted more: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

Zigurd 11y ago

Agile doesn't abjure methodology, and most working Agile teams use scrum-style meetings and kanban-style task tracking. But the first line of the Agile Manifesto says: >Individuals and interactions over processes and tools Which implies a few things, not least the default excuse for failed Agile-managed projects: "You did not have the right people." Well, duh. With the rightest people you can transcend any methodology. Conversely, piling on the process won't save your ass if you have the wrong people. You have to have good people using good tools, and the wisdom to know if that's good enough.