8 ms·

I'm a big advocate of Agile but at the same time I'm leery of joining teams that say they do Agile. Why? Because they usually mean, "We do standups and burndo

I'm a big advocate of Agile but at the same time I'm leery of joining teams that say they do Agile. Why? Because they usually mean, "We do standups and burndown charts and that's it." It's cargo-cult Agile, at best, and micromanagement by story point, at worst. Football teams don't do standups saying "I will run X yards". Each and every player on the team -knows precisely what the objective is -knows precisely what his/her role is and is capable of fulfilling it -knows what s/he needs to communicate to other teammates for them to fulfill their roles and does so promptly -is capable of assessing what needs to be done next given the current situation on the field without having to be told and takes on that task on their own initiative -doesn't have anyone breathing down their neck saying "A point must be scored by X:XX on the clock or else!" regardless of whether the tactical situation makes it possible Together, such a team functions like a well-oiled machine. _That_ is what Agile is trying to teach. But more often than not, few, if any of the personnel or business conditions are met to make it possible and so it's a painful, miserable charade for all involved. I have seen Agile work exactly once in my career; it's absolutely beautiful when it does.

faitswulff 10y ago
Would you mind elaborating on when it did work?
- jgust 10y ago
  A colocated, self-contained (read: no dependencies) team that had clear goals and everything they needed to accomplish them.
jerf 10y ago
Agile is properly a meta-methodology, a methodology for helping you build the proper methodology for your team. If you're not trying things out every so often, keeping what works, and discarding what doesn't (even if it's officially part of some named methodology!), you're not doing Agile Manifesto-Agile. Mistaking a meta-methodology for a methodology is a major category error. It pretty much guarantees failure. I'm at least reasonably agile. Looking back over the last five years, someone who thinks Agile is a methodology would think I'm very inconsistent and all over the map, because my methodologies keep changing. But that's because my needs, responsibilities, task types, and indeed even customer type have shifted over that time. What would be weird is if I did the exact same thing the whole time, because "Agile".
- yojex 10y ago
  >"If you're trying things out every so often, keeping what works, and discarding what doesn't (even if it's officially part of some named methodology!), you're not doing Agile Manifesto-Agile." Are you missing a "not" here?
  - jerf 10y ago
    Yes. Thank you. Fixed.
- DanielBMarkham 10y ago
  What would be weird is if I did the exact same thing the whole time, because "Agile". It wouldn't just be weird; it would be very bad. I like your definition of it as a meta-methodology. I think 90% of the blogs I read about Agile completely miss this -- even those, like this one, that rail against Cargo Cult Agile. I think what people get so messed up about is the mix of discipline and performance. If your team decides that in your situation you need daily standups and burndown charts? Then you got stuff to rigorously do every day. You make your own rules, sure, but whatever they are, they're meaningless unless you have the discipline to stick with them. Some folks naturally want to focus on the "make your own rules" part. Some folks naturally want to focus on the discipline part. But focusing on either is a terrible mistake. They're equally important. (Insert long discussion here a bout Shu Ha Ri)
  - st3v3r 10y ago
    I'm willing to wager that 95% of teams don't have a choice when it comes to a lot of this stuff. The burndowns and standups are mandated by management. So a lot of this "If your Agile isn't working for you, just change it!" doesn't really apply.
    - DanielBMarkham 10y ago
      To some degree, yes. I've worked in tons of multi-team environments. Being able to walk into a team room and ask simple questions like "How much work do you guys think you have?" or "About that feature. Have any idea when it might be done", or "Anything I can help you with?" is a reasonable thing to ask if you're burning the kind of money businesses burn. The counter to what you say is that none of this crap should take more than 10-15 minutes a day. I find that if I establish that upfront, SMs and managers don't end up creating Agile Death Marches. Instead they come back and ask how that can possibly work. Because Agile is meta, it really should disappear. Aside from setting up things and tweaking them, it shouldn't be a topic of discussion. If you're talking about it too much, you're probably doing it wrong. But you are correct. It is not like that in most places. Sadly.
brianwawok 10y ago
Do you have personal football team experience? And is this american football or European futball? Because most american people I know in football, know their EXACT role. Mr. Offensive lineman - I smash whoever is in front of me. If the play is to the left, I smash left. If the play is to the right, I smash right. They know nothing about defense. They know nothing about receiver routes. They don't care. They stand up and smash people. The QUARTERBACK knows a bunch. But he also has a headset on, with 3 people feeding him tips for each play. It would be like a PM coming by every 5 minutes and telling you that you should use a Dictionary to store the current data, and then on the next problem you should maybe look into an ArrayList. Basically.. football is a terrible analogy to software development.
- the-dude 10y ago
  Maybe it is lost in translation and he meant soccer?
  - sqeaky 10y ago
    If is about it still works pretty well. Stupid top-down deadlines are different than the effective communication the QB gets. And a dev team does need effective communication.
  - ralmeida 10y ago
    Unlikely, since in soccer the sentence "I will run X yards" doesn't fit.
- wnevets 10y ago
  >Because most american people I know in football, know their EXACT role. Mr. Offensive lineman - I smash whoever is in front of me. If the play is to the left, I smash left. If the play is to the right, I smash right. They know nothing about defense. They know nothing about receiver routes. They don't care. They stand up and smash people. That's a very oversimplification of american football. For a basic example even the "dumb" offensive lineman has to play differently whether it's a run or a pass. A more complicated play like a screen will require a lot of coordination with his other teammates to perform correctly. American football is actually a pretty good analogy for a the typical development team and the different roles an offense has. You have people in the trenches, people doing flashy stuff and a field general trying to tie it all together.
MIKarlsen 10y ago
Interesting. I was actually JUST watching this on Youtube, which says somewhat the same thing: https://www.youtube.com/watch?v=a-BOSpxYJ9M&t https://www.youtube.com/watch?v=a-BOSpxYJ9M&t
wpietri 10y ago
Yeah. I was involved in the movement before the term "Agile" existed, and I'm deeply disappointed with what the word has come to mean. Everybody meant well, and everybody was very smart. In retrospect, though, I think the big mistake we made was thinking that if our hazy principles (as expressed in the manifesto) collided with typical American managerialist business culture, our principles would win out. In practice, we ended up with what I think of as "mini-Waterfall with Agile labels". Release cadence is faster than with traditional Waterfall. But it is still generally a top-down, push-oriented, document-heavy system. Line workers still seem just as miserable and disempowered as before. I personally have used Kent Beck and Mary Poppendieck's work to create some extraordinary teams and some great working environments. So I think the principles and the original insights have deep merit. But I recognize little of that in the typical "Agile" environment.
- BurningFrog 10y ago
  So how do I find a decent Agile team to join?
  - UK-AL 10y ago
    Perhaps in other aspects of how they develop. How do they do releases(Continuous?). Code review? Automated Testing? Do they test individual features as they are completed or do they test releases as big chunk at the end? Do they have big up front planning, or do they have a plan little bit - implement a little bit-> deploy a little bit -> learn loop. How much ownership does developer have over a feature? Does he ability to say "No" if it isn't ready.
  - peterwwillis 10y ago
    If the word Agile is in the job description, run screaming?
  - jeremiep 10y ago
    Usually, the more a team advertise itself as Agile, the less agility it actually has. I myself have never seen Agile work well, not even close. I saw plenty of make-believe and head-in-the-sand and as mentioned in earlier comments, insane amounts of cargo culting. I really like the way Dave Thomas put it: https://pragdave.me/blog/2014/03/04/time-to-kill-agile/ https://pragdave.me/blog/2014/03/04/time-to-kill-agile/ He also made a talk about it: https://www.youtube.com/watch?v=a-BOSpxYJ9M https://www.youtube.com/watch?v=a-BOSpxYJ9M These days this is the only methodology I follow and it works wonders, anything more I feel is just noise. At the end of the day nothing replaces actual engineering and understanding what you're doing.
Cacti 10y ago
If teams can't consistently implement "Agile", then maybe it's not really that great of a method. Or perhaps it's not much of a method at all, just a bunch of pseudo-philosophical nonsense, measuring things that aren't relevant and using methods whose correlation with actual results is near random. I mean, look. We _know_ there is no single project management method that produces good results across the board. That is a fundamental result of undecidability (and related no free lunch theorems). There is no single method, there never has been, and there never will be. The teams that work well do so because they are good at what they do, they have a specific skillset for what they are working on at that time, they work well together and adapt to the circumstances, and frankly, are a bit lucky. That is a moment in time. Most, if not all, teams cannot reproduce that result consistently year after year, nevermind among different teams. It is a fleeting attribute, not a systemic byproduct of _process_, unless the field is so narrowed so far that optimization is in fact possible (which is exceedingly rare, and certainly doesn't manifest itself in general software development).
- AnimalMuppet 10y ago
  A big part of the point of "agile" is that process is something that you hack/adjust/tune. If you're trying to do agile by dogmatically following a process, expect to fail. When you can say, "Let's tweak our process in this way for the next two sprints, and see if it works better than what we've been doing", that's agile. But you're right, it's fragile. The reason it's fragile is because, as you go up the management tree, eventually agile runs into big-process management. And big-process management wants their reports so that "they know what is going on". Real agile looks sloppy, out of control, even though it delivers more value to the business faster than big-process development does. So real agile scares big-process management, and eventually gets killed by a layer of management that can't deal with it.
  - js8 10y ago
    "When you can say, "Let's tweak our process in this way for the next two sprints, and see if it works better than what we've been doing", that's agile." We did that in our company for about 3 years. Then some guy at the top decided (or maybe that's how he got misunderstood in the middle) what we are doing is not true agile, or whatever, and we are back at square one. So he basically decided to waste all the time we spent in retrospectives and all what we learned. It's like when people say that true Christianity is about forgiveness and other values, which sounds great, until you run into some fundamentalist with the holy book.
acbabis 10y ago
> knows precisely what his/her role is and is capable of fulfilling it I also like Agile when it works, but I'm of the opinion that not following it is a symptom and not a disease. If you're fortunate enough to be on a team of people who know precisely what their role is and how to fulfill it, they'll tend toward Agile by virtue of being able to work quickly and having time to help each other. If you're not that fortunate, then it no longer becomes feasible to divide the work into semi-predictable chunks. The problem is in thinking that Agile is a suitable substitute for skill coverage in a team.
mingyeow 10y ago
I love your description. That said,that is more "well-oiled" than agile. Agile have been taken over by standard and process gurus that want the certainty of a process rather than the ambiguities of people.
aikah 10y ago
IT's just like anything in IT. "serverless", "nosql","cloud", "Agile","REST" . These become buzzwords because everybody sees what he wants to in these words. But I'd also argue that if a concept is hard to implement or every implementations are somehow broken because there is no formal definition, then the problem is the concept at first place.
ryandrake 10y ago
Here are a few problems with your football team analogy: 1. The football team that has the knowledge and judgment you described are all A-players. A-players tend to not need a lot of process. One of the reasons we have project management and software methodologies and all that process is to help the team's B- and C- players perform predictably and consistently, if not close to as good as the A-players. If you actually found that mythical group of software people where each and every one of them knew the business in as much depth as your football players do, then yes, they probably wouldn't need as much structure. My experience has been these teams are extremely rare. 2. A football game is physically observable at all times by all stakeholders. Status needs no reporting. The score is known to all. The position of the ball is known to all. This is not true for software projects. Part of project management is providing visibility to stakeholders and leadership so that risk can be managed and informed strategic decisions can be made. This is why "Agile" emphasizes delivering working software as milestones. Different project management schemes use different methods to track and report status, but the end goal is the same. 3. A football game is already time boxed due to the structure of the game. There is a start time and a duration, it's separated into quarters, team activities are structured into downs, which aids the team in making tactical and strategic decisions. How would all these smart players "know precisely what to do" if they didn't know what quarter it was or how much time was left on the clock? Software does not naturally have any of this structure, so various methodologies seek to frame project with structure to aid decision making. 4. You really don't think any football team's leadership ever yells "We gotta get at least 10 more by halftime go make it happen!" You have to have intermediate milestones. Every sport I've ever played has had a coach or lead player barking the current goals at me. Guess what: That's part of the machine's oil.
- TeMPOraL 10y ago
  I'd add two more problems: 5. Football is a zero-sum PvP game, programming is a PvE race-the-clock game. In football, you don't have to be good, you just have to be not worse than other team (+/- luck factor). In programming, you have random obstacles (requirements, management decisions) thrown at you, the effort it takes to scale those obstacles is mostly unpredictable, and you're being pushed to do it before deadline "or else". 6. Timescale. American football match takes an hour (1.5 hour for soccer, + break). That's how much time the team works together until the next deliverable. In programming, it's weeks or months. Sustaining teamwork on such a long scale is a completely different task. If you want to compare something to football, look at hackatons - and then you'll see people who worked together before often excel at getting things done.
pcmaffey 10y ago
Football (and any pro sports) teams run retrospectives after every game. They watch tons of video, seeking to learn what they were doing, what challenges they were struggling with, and how to improve.
warfangle 10y ago
I feel the exact same way. And I've had the same exact experience: only one place in my decade long career has done agile well. The Project Manager was completely on point with gathering information from stakeholders and direction from executives. The scrum master was a perfect neutral voice who really did an amazing job mediating. Our team was full of smart, capable, focused multidisciplinary engineers. It was absolutely beautiful. I've also never ever seen it again. I've been trying to figure out what was different about that org than everywhere else. Because I've always worked with smart, social SWEs. I think the problems arising from cargo cult agile are more fundamental than the methodology. In order for agile to work well for SWEs, the organization's infrastructure and expectations must be a fit. There are key things that I saw at the place where it worked and were missing everywhere else. * Strong product ownership. The PM is the captain of the ship. They must interface with the execs, with the customers, with the technologists, with the customer service. They must synthesize the stories and effectively outline clear exit criteria for them. And they must accept input from engineering to prioritize tasks that must be done but do not necessarily directly provide customer value. But the buck stops with them. Engineering should not be subject to department infighting for prioritization of pet features. The direction must be clear, or you're foundering. * A neutral voice in the planning meetings to keep things on track and ensure everyone who has a question / input is heard. * Demo days. It's so important for the morale of everyone - on the team and off - for the exposition of the completed work for a given sprint. * Respectful retrospection. * Trust and verification. Micro management is toxic. The only time other than sprint planning that the PM should be involved with the daily work of engineers is when a story requirement needs clarification. And modifying the scope of an in progress sprint should be relegated _only_ to emergencies. This cannot happen if there are _always_ emergencies, though. Which is why it's important for a PM to understand and allocate time for maintenance / infrastructure improvement.
lkrubner 10y ago
Strong agree. I have worked at several places where "Agile" meant "Create a lot of tickets in Jira and then knock them out fast" or "Create a lot of points in PivotalTracker and then knock them out fast." I've also been viewed as a trouble maker if I email the development team and ask them to read this: http://agilemanifesto.org/ http://agilemanifesto.org/ and that is because this line so often goes against what the management team believes: "[We favor] Individuals and interactions over processes and tools"
Spooky23 10y ago
Methodology doesn't replace good management. Most often I see the trappings of agile used as tool to conceal a lack of planning and means to micromanage and give the illusion of progress. I'm fixing a project now where the PM is throwing a list of thousands of tasks at me to show me how much work is done, but haven't delivered anything and cannot commit to ever delivering anything.

faitswulff 10y ago

Would you mind elaborating on when it did work?

jgust 10y ago
A colocated, self-contained (read: no dependencies) team that had clear goals and everything they needed to accomplish them.

jerf 10y ago

Agile is properly a meta-methodology, a methodology for helping you build the proper methodology for your team. If you're not trying things out every so often, keeping what works, and discarding what doesn't (even if it's officially part of some named methodology!), you're not doing Agile Manifesto-Agile. Mistaking a meta-methodology for a methodology is a major category error. It pretty much guarantees failure. I'm at least reasonably agile. Looking back over the last five years, someone who thinks Agile is a methodology would think I'm very inconsistent and all over the map, because my methodologies keep changing. But that's because my needs, responsibilities, task types, and indeed even customer type have shifted over that time. What would be weird is if I did the exact same thing the whole time, because "Agile".

yojex 10y ago
>"If you're trying things out every so often, keeping what works, and discarding what doesn't (even if it's officially part of some named methodology!), you're not doing Agile Manifesto-Agile." Are you missing a "not" here?
- jerf 10y ago
  Yes. Thank you. Fixed.
DanielBMarkham 10y ago
What would be weird is if I did the exact same thing the whole time, because "Agile". It wouldn't just be weird; it would be very bad. I like your definition of it as a meta-methodology. I think 90% of the blogs I read about Agile completely miss this -- even those, like this one, that rail against Cargo Cult Agile. I think what people get so messed up about is the mix of discipline and performance. If your team decides that in your situation you need daily standups and burndown charts? Then you got stuff to rigorously do every day. You make your own rules, sure, but whatever they are, they're meaningless unless you have the discipline to stick with them. Some folks naturally want to focus on the "make your own rules" part. Some folks naturally want to focus on the discipline part. But focusing on either is a terrible mistake. They're equally important. (Insert long discussion here a bout Shu Ha Ri)
- st3v3r 10y ago
  I'm willing to wager that 95% of teams don't have a choice when it comes to a lot of this stuff. The burndowns and standups are mandated by management. So a lot of this "If your Agile isn't working for you, just change it!" doesn't really apply.
  - DanielBMarkham 10y ago
    To some degree, yes. I've worked in tons of multi-team environments. Being able to walk into a team room and ask simple questions like "How much work do you guys think you have?" or "About that feature. Have any idea when it might be done", or "Anything I can help you with?" is a reasonable thing to ask if you're burning the kind of money businesses burn. The counter to what you say is that none of this crap should take more than 10-15 minutes a day. I find that if I establish that upfront, SMs and managers don't end up creating Agile Death Marches. Instead they come back and ask how that can possibly work. Because Agile is meta, it really should disappear. Aside from setting up things and tweaking them, it shouldn't be a topic of discussion. If you're talking about it too much, you're probably doing it wrong. But you are correct. It is not like that in most places. Sadly.

brianwawok 10y ago

Do you have personal football team experience? And is this american football or European futball? Because most american people I know in football, know their EXACT role. Mr. Offensive lineman - I smash whoever is in front of me. If the play is to the left, I smash left. If the play is to the right, I smash right. They know nothing about defense. They know nothing about receiver routes. They don't care. They stand up and smash people. The QUARTERBACK knows a bunch. But he also has a headset on, with 3 people feeding him tips for each play. It would be like a PM coming by every 5 minutes and telling you that you should use a Dictionary to store the current data, and then on the next problem you should maybe look into an ArrayList. Basically.. football is a terrible analogy to software development.

the-dude 10y ago
Maybe it is lost in translation and he meant soccer?
- sqeaky 10y ago
  If is about it still works pretty well. Stupid top-down deadlines are different than the effective communication the QB gets. And a dev team does need effective communication.
- ralmeida 10y ago
  Unlikely, since in soccer the sentence "I will run X yards" doesn't fit.
wnevets 10y ago
>Because most american people I know in football, know their EXACT role. Mr. Offensive lineman - I smash whoever is in front of me. If the play is to the left, I smash left. If the play is to the right, I smash right. They know nothing about defense. They know nothing about receiver routes. They don't care. They stand up and smash people. That's a very oversimplification of american football. For a basic example even the "dumb" offensive lineman has to play differently whether it's a run or a pass. A more complicated play like a screen will require a lot of coordination with his other teammates to perform correctly. American football is actually a pretty good analogy for a the typical development team and the different roles an offense has. You have people in the trenches, people doing flashy stuff and a field general trying to tie it all together.

MIKarlsen 10y ago

Interesting. I was actually JUST watching this on Youtube, which says somewhat the same thing: https://www.youtube.com/watch?v=a-BOSpxYJ9M&t https://www.youtube.com/watch?v=a-BOSpxYJ9M&t

wpietri 10y ago

Yeah. I was involved in the movement before the term "Agile" existed, and I'm deeply disappointed with what the word has come to mean. Everybody meant well, and everybody was very smart. In retrospect, though, I think the big mistake we made was thinking that if our hazy principles (as expressed in the manifesto) collided with typical American managerialist business culture, our principles would win out. In practice, we ended up with what I think of as "mini-Waterfall with Agile labels". Release cadence is faster than with traditional Waterfall. But it is still generally a top-down, push-oriented, document-heavy system. Line workers still seem just as miserable and disempowered as before. I personally have used Kent Beck and Mary Poppendieck's work to create some extraordinary teams and some great working environments. So I think the principles and the original insights have deep merit. But I recognize little of that in the typical "Agile" environment.

BurningFrog 10y ago
So how do I find a decent Agile team to join?
- UK-AL 10y ago
  Perhaps in other aspects of how they develop. How do they do releases(Continuous?). Code review? Automated Testing? Do they test individual features as they are completed or do they test releases as big chunk at the end? Do they have big up front planning, or do they have a plan little bit - implement a little bit-> deploy a little bit -> learn loop. How much ownership does developer have over a feature? Does he ability to say "No" if it isn't ready.
- peterwwillis 10y ago
  If the word Agile is in the job description, run screaming?
- jeremiep 10y ago
  Usually, the more a team advertise itself as Agile, the less agility it actually has. I myself have never seen Agile work well, not even close. I saw plenty of make-believe and head-in-the-sand and as mentioned in earlier comments, insane amounts of cargo culting. I really like the way Dave Thomas put it: https://pragdave.me/blog/2014/03/04/time-to-kill-agile/ https://pragdave.me/blog/2014/03/04/time-to-kill-agile/ He also made a talk about it: https://www.youtube.com/watch?v=a-BOSpxYJ9M https://www.youtube.com/watch?v=a-BOSpxYJ9M These days this is the only methodology I follow and it works wonders, anything more I feel is just noise. At the end of the day nothing replaces actual engineering and understanding what you're doing.

Cacti 10y ago

If teams can't consistently implement "Agile", then maybe it's not really that great of a method. Or perhaps it's not much of a method at all, just a bunch of pseudo-philosophical nonsense, measuring things that aren't relevant and using methods whose correlation with actual results is near random. I mean, look. We _know_ there is no single project management method that produces good results across the board. That is a fundamental result of undecidability (and related no free lunch theorems). There is no single method, there never has been, and there never will be. The teams that work well do so because they are good at what they do, they have a specific skillset for what they are working on at that time, they work well together and adapt to the circumstances, and frankly, are a bit lucky. That is a moment in time. Most, if not all, teams cannot reproduce that result consistently year after year, nevermind among different teams. It is a fleeting attribute, not a systemic byproduct of _process_, unless the field is so narrowed so far that optimization is in fact possible (which is exceedingly rare, and certainly doesn't manifest itself in general software development).

AnimalMuppet 10y ago
A big part of the point of "agile" is that process is something that you hack/adjust/tune. If you're trying to do agile by dogmatically following a process, expect to fail. When you can say, "Let's tweak our process in this way for the next two sprints, and see if it works better than what we've been doing", that's agile. But you're right, it's fragile. The reason it's fragile is because, as you go up the management tree, eventually agile runs into big-process management. And big-process management wants their reports so that "they know what is going on". Real agile looks sloppy, out of control, even though it delivers more value to the business faster than big-process development does. So real agile scares big-process management, and eventually gets killed by a layer of management that can't deal with it.
- js8 10y ago
  "When you can say, "Let's tweak our process in this way for the next two sprints, and see if it works better than what we've been doing", that's agile." We did that in our company for about 3 years. Then some guy at the top decided (or maybe that's how he got misunderstood in the middle) what we are doing is not true agile, or whatever, and we are back at square one. So he basically decided to waste all the time we spent in retrospectives and all what we learned. It's like when people say that true Christianity is about forgiveness and other values, which sounds great, until you run into some fundamentalist with the holy book.

acbabis 10y ago

> knows precisely what his/her role is and is capable of fulfilling it I also like Agile when it works, but I'm of the opinion that not following it is a symptom and not a disease. If you're fortunate enough to be on a team of people who know precisely what their role is and how to fulfill it, they'll tend toward Agile by virtue of being able to work quickly and having time to help each other. If you're not that fortunate, then it no longer becomes feasible to divide the work into semi-predictable chunks. The problem is in thinking that Agile is a suitable substitute for skill coverage in a team.

mingyeow 10y ago

I love your description. That said,that is more "well-oiled" than agile. Agile have been taken over by standard and process gurus that want the certainty of a process rather than the ambiguities of people.

aikah 10y ago

IT's just like anything in IT. "serverless", "nosql","cloud", "Agile","REST" . These become buzzwords because everybody sees what he wants to in these words. But I'd also argue that if a concept is hard to implement or every implementations are somehow broken because there is no formal definition, then the problem is the concept at first place.

ryandrake 10y ago

Here are a few problems with your football team analogy: 1. The football team that has the knowledge and judgment you described are all A-players. A-players tend to not need a lot of process. One of the reasons we have project management and software methodologies and all that process is to help the team's B- and C- players perform predictably and consistently, if not close to as good as the A-players. If you actually found that mythical group of software people where each and every one of them knew the business in as much depth as your football players do, then yes, they probably wouldn't need as much structure. My experience has been these teams are extremely rare. 2. A football game is physically observable at all times by all stakeholders. Status needs no reporting. The score is known to all. The position of the ball is known to all. This is not true for software projects. Part of project management is providing visibility to stakeholders and leadership so that risk can be managed and informed strategic decisions can be made. This is why "Agile" emphasizes delivering working software as milestones. Different project management schemes use different methods to track and report status, but the end goal is the same. 3. A football game is already time boxed due to the structure of the game. There is a start time and a duration, it's separated into quarters, team activities are structured into downs, which aids the team in making tactical and strategic decisions. How would all these smart players "know precisely what to do" if they didn't know what quarter it was or how much time was left on the clock? Software does not naturally have any of this structure, so various methodologies seek to frame project with structure to aid decision making. 4. You really don't think any football team's leadership ever yells "We gotta get at least 10 more by halftime go make it happen!" You have to have intermediate milestones. Every sport I've ever played has had a coach or lead player barking the current goals at me. Guess what: That's part of the machine's oil.

TeMPOraL 10y ago
I'd add two more problems: 5. Football is a zero-sum PvP game, programming is a PvE race-the-clock game. In football, you don't have to be good, you just have to be not worse than other team (+/- luck factor). In programming, you have random obstacles (requirements, management decisions) thrown at you, the effort it takes to scale those obstacles is mostly unpredictable, and you're being pushed to do it before deadline "or else". 6. Timescale. American football match takes an hour (1.5 hour for soccer, + break). That's how much time the team works together until the next deliverable. In programming, it's weeks or months. Sustaining teamwork on such a long scale is a completely different task. If you want to compare something to football, look at hackatons - and then you'll see people who worked together before often excel at getting things done.

pcmaffey 10y ago

Football (and any pro sports) teams run retrospectives after every game. They watch tons of video, seeking to learn what they were doing, what challenges they were struggling with, and how to improve.

warfangle 10y ago

I feel the exact same way. And I've had the same exact experience: only one place in my decade long career has done agile well. The Project Manager was completely on point with gathering information from stakeholders and direction from executives. The scrum master was a perfect neutral voice who really did an amazing job mediating. Our team was full of smart, capable, focused multidisciplinary engineers. It was absolutely beautiful. I've also never ever seen it again. I've been trying to figure out what was different about that org than everywhere else. Because I've always worked with smart, social SWEs. I think the problems arising from cargo cult agile are more fundamental than the methodology. In order for agile to work well for SWEs, the organization's infrastructure and expectations must be a fit. There are key things that I saw at the place where it worked and were missing everywhere else. * Strong product ownership. The PM is the captain of the ship. They must interface with the execs, with the customers, with the technologists, with the customer service. They must synthesize the stories and effectively outline clear exit criteria for them. And they must accept input from engineering to prioritize tasks that must be done but do not necessarily directly provide customer value. But the buck stops with them. Engineering should not be subject to department infighting for prioritization of pet features. The direction must be clear, or you're foundering. * A neutral voice in the planning meetings to keep things on track and ensure everyone who has a question / input is heard. * Demo days. It's so important for the morale of everyone - on the team and off - for the exposition of the completed work for a given sprint. * Respectful retrospection. * Trust and verification. Micro management is toxic. The only time other than sprint planning that the PM should be involved with the daily work of engineers is when a story requirement needs clarification. And modifying the scope of an in progress sprint should be relegated _only_ to emergencies. This cannot happen if there are _always_ emergencies, though. Which is why it's important for a PM to understand and allocate time for maintenance / infrastructure improvement.

lkrubner 10y ago

Strong agree. I have worked at several places where "Agile" meant "Create a lot of tickets in Jira and then knock them out fast" or "Create a lot of points in PivotalTracker and then knock them out fast." I've also been viewed as a trouble maker if I email the development team and ask them to read this: http://agilemanifesto.org/ http://agilemanifesto.org/ and that is because this line so often goes against what the management team believes: "[We favor] Individuals and interactions over processes and tools"

Spooky23 10y ago

Methodology doesn't replace good management. Most often I see the trappings of agile used as tool to conceal a lack of planning and means to micromanage and give the illusion of progress. I'm fixing a project now where the PM is throwing a list of thousands of tasks at me to show me how much work is done, but haven't delivered anything and cannot commit to ever delivering anything.