3 ms·

Everyone claims they are following “agile methods” but few actually do

3 points by zwieback 9y ago

zwieback 9y ago
At my workplace we're semi-agile but it's been mostly in response to middle and upper managers, who want to claim to be agile. Our practices haven't changed all that much, to be honest. Initially we were aiming for full-blown agile but it felt like too much of a straight jacket and there was a lot of resentment against being micromanaged.
- mindcrime 9y ago
  Initially we were aiming for full-blown agile but it felt like too much of a straight jacket and there was a lot of resentment against being micromanaged. There is no such thing as "agile". Were they talking about Scrum, SAFE, XP, Crystal, AgileUP or what? And in either case, if what was being pitched involved a lot of micromanagement and felt like a "straight jacket" then you can pretty much say that, by definition, it was not a valid implementation of the principles of the Agile Manifesto. Unless your comparing to a complete "cowboy coding" environment with no process at all, in which case even the most lightweight process might feel constraining...
  - zwieback 9y ago
    In our case Scrum was the favored methodology. I'm not arguing against Agile or even Scrum, by the way. I've been following and dreaming about working in a team like they described on the Extreme Programming pages on c2.com years before Agile was a twinkle in our managers' eyes. However, in our case implementing something closer to the pure ideal of the Agile Manifesto proved too challenging: - In internal SW projects it's difficult to find a customer that's willing to put in the time required to drive the development. - Everyone has multiple jobs, some include ME and EE that are hard to agilify - Managers don't really want to turn over scheduling authority to the team - Exploratory and learning takes a backseat to knocking items off the backlog
    - mindcrime 9y ago
      Everyone has multiple jobs, some include ME and EE that are hard to agilify - Managers don't really want to turn over scheduling authority to the team - Exploratory and learning takes a backseat to knocking items off the backlog Yeah, that's usually what happens. It's a shame too. :-(
mindcrime 9y ago
The big problems I see are this: 1. Talking about "Agile" like it's a "thing" you can adopt (it's not). Agile is a description of a family of methodologies. Or, to be more precise, it's a set of principles and ideals which a large set of methodologies claim to incorporate and emphasize (and do so to varying degrees). Anyway, you don't adopt "Agile" you adopt Scrum, or Crystal, or AgileUP, or XP, or SAFE, etc. And yes, this matters, because people say "Agile says you do X" where this statement is basically incorrect for almost every value of X. "Agile" is not some heavyweight, prescriptive methodology that dictates a Jira workflow, blah, etc. It's your shitty implementation of Scrum, SAFE, etc. that dictates these things. But people get to use the excuse "this is Agile" if you argue against any part of the current process. 2. Completely missing sight of how the Agile Manifesto says "favor individuals and interactions over processes and tools" and implementing some highly prescriptive, top-down, command-and-control process. And thinking that "we're Agile" because we have daily scrums, use Jira (or Rally), and work in "sprints". Basically, people adopt the ceremony and some of the language used by some agile-family methodologies, but completely avoid the principles and ideals of Agile (and articulated in the Agile Manifesto). 3. Impedance mismatch between the way developers expect to work in an "Agile" environment, and what management wants. Basically, somebody in management read an HBR article or something that said "Agile lets you move faster" and misinterpreted that as "If we implement Agile, my developers will crank out more code faster, and I don't have to change anything else about how this company works".
- zwieback 9y ago
  Yes, yes and yes!

3 points by zwieback 9y ago

At my workplace we're semi-agile but it's been mostly in response to middle and upper managers, who want to claim to be agile. Our practices haven't changed all that much, to be honest. Initially we were aiming for full-blown agile but it felt like too much of a straight jacket and there was a lot of resentment against being micromanaged.

mindcrime 9y ago
Initially we were aiming for full-blown agile but it felt like too much of a straight jacket and there was a lot of resentment against being micromanaged. There is no such thing as "agile". Were they talking about Scrum, SAFE, XP, Crystal, AgileUP or what? And in either case, if what was being pitched involved a lot of micromanagement and felt like a "straight jacket" then you can pretty much say that, by definition, it was not a valid implementation of the principles of the Agile Manifesto. Unless your comparing to a complete "cowboy coding" environment with no process at all, in which case even the most lightweight process might feel constraining...
- zwieback 9y ago
  In our case Scrum was the favored methodology. I'm not arguing against Agile or even Scrum, by the way. I've been following and dreaming about working in a team like they described on the Extreme Programming pages on c2.com years before Agile was a twinkle in our managers' eyes. However, in our case implementing something closer to the pure ideal of the Agile Manifesto proved too challenging: - In internal SW projects it's difficult to find a customer that's willing to put in the time required to drive the development. - Everyone has multiple jobs, some include ME and EE that are hard to agilify - Managers don't really want to turn over scheduling authority to the team - Exploratory and learning takes a backseat to knocking items off the backlog
  - mindcrime 9y ago
    Everyone has multiple jobs, some include ME and EE that are hard to agilify - Managers don't really want to turn over scheduling authority to the team - Exploratory and learning takes a backseat to knocking items off the backlog Yeah, that's usually what happens. It's a shame too. :-(

mindcrime 9y ago

The big problems I see are this: 1. Talking about "Agile" like it's a "thing" you can adopt (it's not). Agile is a description of a family of methodologies. Or, to be more precise, it's a set of principles and ideals which a large set of methodologies claim to incorporate and emphasize (and do so to varying degrees). Anyway, you don't adopt "Agile" you adopt Scrum, or Crystal, or AgileUP, or XP, or SAFE, etc. And yes, this matters, because people say "Agile says you do X" where this statement is basically incorrect for almost every value of X. "Agile" is not some heavyweight, prescriptive methodology that dictates a Jira workflow, blah, etc. It's your shitty implementation of Scrum, SAFE, etc. that dictates these things. But people get to use the excuse "this is Agile" if you argue against any part of the current process. 2. Completely missing sight of how the Agile Manifesto says "favor individuals and interactions over processes and tools" and implementing some highly prescriptive, top-down, command-and-control process. And thinking that "we're Agile" because we have daily scrums, use Jira (or Rally), and work in "sprints". Basically, people adopt the ceremony and some of the language used by some agile-family methodologies, but completely avoid the principles and ideals of Agile (and articulated in the Agile Manifesto). 3. Impedance mismatch between the way developers expect to work in an "Agile" environment, and what management wants. Basically, somebody in management read an HBR article or something that said "Agile lets you move faster" and misinterpreted that as "If we implement Agile, my developers will crank out more code faster, and I don't have to change anything else about how this company works".

zwieback 9y ago
Yes, yes and yes!