9 ms·

Manifesto for Half-Arsed Agile Software Development

102 points by virtualsue 13y ago

BWStearns 13y ago
This post gave me flashbacks. I once had to sit through an 8 hour pre-kickoff meeting detailing in excruciating detail how our team was going to be "agile". It involved at least 400 slides, described a weeks long change request process, and two-month long "sprints". Even as a junior dev I know I am lucky I never had to suffer through the rest of that contract.
allochthon 13y ago
I've been a little disappointed to find out that aspects of this view are sometimes adopted at startups with a lot of VC funding, and not just enterprise companies.
- MartinCron 13y ago
  Yeah, that is the one thing I would remove in this manifesto. References to "enterprise" as all sorts of companies are infected with this half-arsed agile mindset which is an insult to both agile and half-arses.
- wpietri 13y ago
  I worry less about the startups. If they are small, then as long as they are releasing frequently and paying attention to what's happening in the real world, they tend to converge on an Agile-ish approach. And if they aren't, they are likely to quickly crash and burn, limiting their damage. Enterprises worry me more, because there feedback loops are often broken. Nothing is pushing people toward sanity, and organizational dynamics often push the other way. Plus, they have plenty of money to hire consultants to prop them up. Which in turn creates a marketplace of very well-paid and well-marketed consultants who only sell half-assed Agile, because their clients wouldn't even want to think that they aren't getting the good stuff. And if there are enough of those companies and consultants, then the impression is that half-assed Agile is actually the norm.
deleted 13y ago
[deleted]
al2o3cr 13y ago
Disagree with the title; if anything, these practices are correlated with a SURPLUS of arses involved in the project. :)
- neosergio 13y ago
  TRUE. The problem are the people who consider themselves as "agile".
chris_wot 13y ago
Finally, someone who spells "arses" correctly!
jhare 13y ago
In the best of worlds your practices evolve from your principles. Compound the relationship between your principles and _current_ practices with the effects of the real world and you end up somewhere in between. That's life. It's easy to stand from a "higher elevation" like a consultant might, point your finger and say "You are not doing this." It's a harder thing to really make it happen. I see parallels in people bickering about whether some element of a service is or is-not RESTful, when maybe 95% of the functionality of the service is acting/quacking like a duck.
- icebraining 13y ago
  In a recent book, which I learned from a podcast[1], Lant Pritchett argues that much of the increase of education in developing countries is to a great extent fake, being inflated by governments which "have created all the appearances of schools that provide education but without actually doing it " by producing "enrollment statistics, numbers of buildings, numbers of toilets, numbers of textbooks, numbers of everything (...) all of which can project the image that there's a functional system and providing real learning there." I think a similar effect has happened to RESTful architectures; people making them have (inadvertently, I believe) produced very convincing emulations while skipping the parts that effectively distinguish them from RPC systems. [1] http://www.econtalk.org/archives/2013/12/lant_pritchett.html http://www.econtalk.org/archives/2013/12/lant_pritchett.html
taoquay 13y ago
As someone working in enterprise, this manifesto sounds almost exactly like how we use Agile here. The term "Agile philosophy" (instead of methodology) was coined to go with our loose interpretation of what Agile should be.
wpietri 13y ago
Beautiful! The thing that really kills me about this is that 90% of the people who are "doing Agile" (which is not a thing that you can do [1]) really believe that they are an Agile shop. And then I will ask as many as 3 questions to find out what they're doing is waterfall, or mini-waterfall, or code-n-fix. In the old days I could say, "Hey, you should try one of the Agile processes." Now they think they are doing that and doing it well (after all, they have certificates!), so what can I even tell them? Everybody I talk to who was involved in the Agile movement in the 2000-2004 time frame has this experience now. Common reactions are rage, tears, and philosophical resignation. (I favor quiet rage, but I suspect resignation would be healthier.) That there are some shops doing very well is consolation, but the early Agile people were hoping for more. For the whippersnappers who are curious about now-ancient history, my theory on how we went wrong is here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how... A big lesson I learned was that if you don't have a trademark and use it to keep quality high, your popular term will get buzzworded to death. [1] Agile is an umbrella for actual processes, like Extreme Programming. There is no process called Agile to do. Saying you are "doing Agile" is like somebody saying their house is in America, but not in DC or any of the states, just America. If you point out that it's the United States of America and they have to be somewhere; they just shrug.
- shubb 13y ago
  To me, there are a bunch of people who can't do Agile. They have huge legacy software projects, with low test coverage. They have customers that want (or can only cope with) traditional requirements based contracts. In situations where agile doesn't make sense, do you think 'fake agile' can be a better way of working than 1990s waterfall?
  - AnimalMuppet 13y ago
    "Fake agile" is essentially lying to yourself about what your process is. I can't imagine any situation where that was actually useful.
    - 13y ago
herghost 13y ago
In my experience "agile" isn't really a thing, more an excuse or reason to not follow any rules at all. Devs get to play at building whatever they like, solving the problems that interest them in a haphazard way and leaving behind a trail of half-written, semi-functional code with little or no documentation to allow anyone to work with them. As soon as anyone suggests that there's a plan, or god-forbid, an objective or expected outcome from the invested money, everyone suddenly scream, "AGILE" and that, apparently, is enough to shutdown any and all detractors. But then, try to suggest that there's a requirement that has changed or come to light and suddenly the "agile is open to new requirements" part of the approach is forgotten as the "progress" that's been made so far is too precious to change. /rant
- UK-AL 13y ago
  That's odd because agile methods like scrum have a definition of done, which has to be complete before you can class an issue as done. definition of Done usually includes things like written code, unit tests, code review, documented etc I suspect most people doing a agile, don't actually do agile. And think its a term for little structure. Agile methods, such as XP programming are highly disciplined methods, more so than traditional. The main difference is that they react to customer change, and don't follow plan than stretches 6 months into the future. The priorities of tasks can change from sprint to sprint. Allowing the team to react to the outside world.
Yhippa 13y ago
This reminds me that anything "Agile" and enterprise business is fundamentally incompatible thanks to the quarterly earnings report (for public companies at least).
gdubs 13y ago
This describes a certain kind of corporate agile that I like to call "Agile in a Waterfall".
- eitally 13y ago
  I think this is probably the most common "style" in most large enterprises. The people footing the bill still demand macro level waterfall estimates, but when it comes time to execute the project, it's split into smaller phases (perhaps 4-6mo) which are in turn split into 2-4wk sprints. In my personal experience as an enterprise apps director, this is significantly better than pure waterfall but still causes all sorts of stress on the IT side. I think the single highest impact change for the better would be to take a product-centric rather than a project-centric perspective. At least in my company, business "owners" don't pay for KTLO work, only projects, so there's no incentive for anyone to ensure high quality products.
- UK-AL 13y ago
  Yes, in larger companies the development is Agile but overall its waterfall. It misses important aspects like constantly verifying the product with customer, and adjusting if required.
thenipper 13y ago
This is so on point for any company not just software ones. I work at an NGO and not a tech company, and this just reminds me of every meeting we have about internal processes. We end up creating grandiose plans, but they usually just turn into endless bullet points for strategic road maps rather then actionable items
dschiptsov 13y ago
The buzzword of the day is "reactive".)
coldcode 13y ago
If this is half-arsed, then what is the enterprise definition of full-arsed?
- arethuza 13y ago
  Probably CMM Level 5
avighnay 13y ago
In my language we have an ancient term/story called 'Yaanai Kanda Vaadham' meaning the 'debate on the elephant' (the origin of the story is controversial so lets leave that out). Perhaps you have heard the story, four blind friends come across an elephant, each one holds a part of the elephant and equates it to what he knows and understands. Hey! there is a wikipedia page on it http://en.wikipedia.org/wiki/Blind_men_and_an_elephant http://en.wikipedia.org/wiki/Blind_men_and_an_elephant When merits of processes are discussed devoid of its purpose (delivering quality software in business relevant time), the argument is similar to the story. The process is just the means of reaching the purpose isn't it? It is not like successful software was delivered only in the last decade, we have been to the Moon and back before that. Unfortunately, processes are always made in good intention to achieve a purpose, this when transmitted from one person to another becomes a system, as there is no guarantee or way of enforcing 100% knowledge for all people in the chain. This deviates it pretty quickly from the purpose with focus only on the practice and soon the system becomes a religion. Then surprise! people shed blood over it after that demanding that their book is the only truth :-)
asolove 13y ago
It's interesting because "agile" can fail on both sides. This lampoons the enterprise side, in which you adopt "agile" practices inside rigorous change control and long requirements documents. But there is also the cowboy/ninja failure mode, in which "agile" is used to rule out any strategic thinking, technical design, or requirements gathering. Not only can you fail on both sides, but you can be too far on one side and think that you haven't gone far enough. I've had startups tell me they were doing Scrum, but it had gotten so hard to estimate their work that they had "broken agile" by having "grooming sessions" to talk to stakeholders about upcoming work before it got into sprint. They were shocked to learn this was a required part of Scrum and that many books recommended that being up to 10% of the team's time. Another company I talked with was so concerned about their developers "continuously delivering" code that they were fighting to be "more Scrum" by changing their QA folks to be in a staggered sprint one week after the developers. They were shocked to learn that this was a widely-tried and widely-panned approach that was philosophically opposed to the roots of Scrum. Now, I remember hearing examples like these before I had really dived into Scrum, and assuming it was a "no true Scotsman" where, whatever you did, someone would find a way to say it wasn't Scrum. But after some very good books and talking with experienced people (who were involved in the early stages, not bandwagon consultants), I now feel like I actually understand what Scrum is for and when it works, and can quickly spot people who don't understand the philosophy. Has anyone else experienced this? I wonder whether it is real experience or just an illusion my brain has created to give meaning to many months of painful trial and error. Nowadays I think of scrum as being about holistic product creation, about building a team that can deliver what customers will pay you for over the long-term. That requires breaking down most "process" to get "one-piece flow" on a complete team working as one to deliver new features. But it also includes the team building its own processes to make sure they are building the right thing to a high level of quality. That vision is anathema to cultures that value technical prowess, or pure speed, or meeting corporate objectives, or anything else other than building a team that can deliver value to customers over the long term. It's a challenge and a priority change for both corporate political environments and built-to-flip startups. And it's surprisingly hard to find a company that wants to pay you to build things their customers like, rather than using some other metric.
- UK-AL 13y ago
mbesto 13y ago
One word: budgets. The problem with "enterprise" isn't their reluctance to adapt agile principles, but rather that people need to know "if I pay X, then I should get Y" - agile basically says "we think we know what X is, and we know your version of Y isn't what Y will become"
- klodolph 13y ago
  The enterprises that think that large software projects can be completed with "pay X get Y" are the ones that fail, historically speaking, because software projects are subject to a much higher risk of budget and schedule overrun than other types of projects (such as civil engineering projects). Large IT projects have put more than a few large companies into bankruptcy.
- wpietri 13y ago
  Yes. I think the solution to this is to get rid of budgets, and go for an approach based around iteration, risk reduction, and a flow of delivered value. That sounded insane to me at first, but the Lean folks really turned me around on this. Mary Poppendieck's books are great in this regard. One of her best examples is the Empire State Building: they started construction on the lower floors before the top floors were even designed. Nonetheless, the project was completed on schedule and budget. How? As with Agile projects, scope was treated as variable, and a lot of thought was put into maximizing efficiency of the system. I've also read some great stuff from the Lean Manufacturing community on how shifting the approach to accounting is vital. Rather than having annual plans and budgets and then trying to hit them, you have rolling projections n months out and adjust allocation to achieve real-world effects.
  - mbesto 13y ago
    Yup. The problem is trying to explain to a client: "Ok, so we've got the 4 best back-end developers, 2 best UX/UI guys, and a scrummaster. Now they'll cost you $100k/month, and we think that'll create 3 apps for you, but ummmm we're not sure. But these guys are the best, so on average you'll get more production out of them if you don't do agile" My conclusion is that agile only works with talented people; most of the enterprise clients I've work with (non-SaaS stuff) don't care whether they are Linus Torvalds or Joe Shmoe, they just want to spend their budget and get their "app" within the budget.
badman_ting 13y ago
I dunno, sometimes going back to waterfall sounds kind of nice. I'm tired of the lack of direction, the attention-deficit school of project management where every 3 months there is some new starry-eyed vision we all chase after. I know this means my company is "doing agile wrong" and all that shit, I just would rather be on a slow train wreck than a fast one.
- willismichael 13y ago
  If it's going to be a train wreck either way, I'm not sure which I would prefer. Maybe jump and find another train?
- UK-AL 13y ago
  The problem is that business conditions do change that fast. However for a lot of small companies it is better than what they had before, regarding consistent direction. Lots of startups change scope or features daily and are in a constant state of panic. Having a fixed two/one week sprint provides same restspite for developers. But still allowing feature and priorities to be changed after each sprint.
  - badman_ting 13y ago
    That's what I thought for a while too, but most everything I have made in the last 2-3 years got shoved in a ditch. We're not responding to the market, we're just flailing around trying different dumb stuff.
- StudyAnimal 13y ago
  I bet you hate startups then, and all their pivoting!
  - badman_ting 13y ago
    Sure. I don't think I would ever work at one, although not for this reason.
saosebastiao 13y ago
It is a plain fact that people rarely distinguish between philosophy, religion, and culture. As a former mormon who served a mission in a foreign country, I witnessed this first hand: American missionaries (mostly from Utah) trying to superimpose their culture on foreigners and calling it religion, while foreign members pushed back (appropriately IMO) when they felt that the religion didn't really clash with their culture which was being stripped from them. Now I am seeing this from an outside perspective; I'm not a programmer or software engineer but I work directly with them in a weird sort of non-supervisory product manager role. In my opinion, this is no different...in fact, "Agile", which as far as I can tell is nothing more than a hand-wavy underspecified form of Extreme Programming, has so much ambiguity in its definition that you can't ask any two advocates and get the same response as to what it is. And as such, whenever there is a problem with the outcomes of the process, the only apt response is the No-True-Scotsman fallacy...which makes development descend into the phenomenal failure of productivity that all holy wars are. This isn't unique to Agile. Lean and Six Sigma are also mixed bags of philosophy and process, and they have been mixed bags of occasional success and phenomenal failure.
- UK-AL 13y ago
  Agile is underspecified because it is a general philosophy. I.E React to change, rather than following a 12 months rigid plan. There are different concrete ways to implement Agile, such as using Scrum, DSDM, or various other methods.

102 points by virtualsue 13y ago

This post gave me flashbacks. I once had to sit through an 8 hour pre-kickoff meeting detailing in excruciating detail how our team was going to be "agile". It involved at least 400 slides, described a weeks long change request process, and two-month long "sprints". Even as a junior dev I know I am lucky I never had to suffer through the rest of that contract.

allochthon 13y ago

I've been a little disappointed to find out that aspects of this view are sometimes adopted at startups with a lot of VC funding, and not just enterprise companies.

MartinCron 13y ago
Yeah, that is the one thing I would remove in this manifesto. References to "enterprise" as all sorts of companies are infected with this half-arsed agile mindset which is an insult to both agile and half-arses.
wpietri 13y ago
I worry less about the startups. If they are small, then as long as they are releasing frequently and paying attention to what's happening in the real world, they tend to converge on an Agile-ish approach. And if they aren't, they are likely to quickly crash and burn, limiting their damage. Enterprises worry me more, because there feedback loops are often broken. Nothing is pushing people toward sanity, and organizational dynamics often push the other way. Plus, they have plenty of money to hire consultants to prop them up. Which in turn creates a marketplace of very well-paid and well-marketed consultants who only sell half-assed Agile, because their clients wouldn't even want to think that they aren't getting the good stuff. And if there are enough of those companies and consultants, then the impression is that half-assed Agile is actually the norm.

deleted 13y ago

[deleted]

al2o3cr 13y ago

Disagree with the title; if anything, these practices are correlated with a SURPLUS of arses involved in the project. :)

neosergio 13y ago
TRUE. The problem are the people who consider themselves as "agile".

chris_wot 13y ago

Finally, someone who spells "arses" correctly!

jhare 13y ago

In the best of worlds your practices evolve from your principles. Compound the relationship between your principles and _current_ practices with the effects of the real world and you end up somewhere in between. That's life. It's easy to stand from a "higher elevation" like a consultant might, point your finger and say "You are not doing this." It's a harder thing to really make it happen. I see parallels in people bickering about whether some element of a service is or is-not RESTful, when maybe 95% of the functionality of the service is acting/quacking like a duck.

icebraining 13y ago
In a recent book, which I learned from a podcast[1], Lant Pritchett argues that much of the increase of education in developing countries is to a great extent fake, being inflated by governments which "have created all the appearances of schools that provide education but without actually doing it " by producing "enrollment statistics, numbers of buildings, numbers of toilets, numbers of textbooks, numbers of everything (...) all of which can project the image that there's a functional system and providing real learning there." I think a similar effect has happened to RESTful architectures; people making them have (inadvertently, I believe) produced very convincing emulations while skipping the parts that effectively distinguish them from RPC systems. [1] http://www.econtalk.org/archives/2013/12/lant_pritchett.html http://www.econtalk.org/archives/2013/12/lant_pritchett.html

taoquay 13y ago

As someone working in enterprise, this manifesto sounds almost exactly like how we use Agile here. The term "Agile philosophy" (instead of methodology) was coined to go with our loose interpretation of what Agile should be.

wpietri 13y ago

Beautiful! The thing that really kills me about this is that 90% of the people who are "doing Agile" (which is not a thing that you can do [1]) really believe that they are an Agile shop. And then I will ask as many as 3 questions to find out what they're doing is waterfall, or mini-waterfall, or code-n-fix. In the old days I could say, "Hey, you should try one of the Agile processes." Now they think they are doing that and doing it well (after all, they have certificates!), so what can I even tell them? Everybody I talk to who was involved in the Agile movement in the 2000-2004 time frame has this experience now. Common reactions are rage, tears, and philosophical resignation. (I favor quiet rage, but I suspect resignation would be healthier.) That there are some shops doing very well is consolation, but the early Agile people were hoping for more. For the whippersnappers who are curious about now-ancient history, my theory on how we went wrong is here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how... A big lesson I learned was that if you don't have a trademark and use it to keep quality high, your popular term will get buzzworded to death. [1] Agile is an umbrella for actual processes, like Extreme Programming. There is no process called Agile to do. Saying you are "doing Agile" is like somebody saying their house is in America, but not in DC or any of the states, just America. If you point out that it's the United States of America and they have to be somewhere; they just shrug.

shubb 13y ago
To me, there are a bunch of people who can't do Agile. They have huge legacy software projects, with low test coverage. They have customers that want (or can only cope with) traditional requirements based contracts. In situations where agile doesn't make sense, do you think 'fake agile' can be a better way of working than 1990s waterfall?
- AnimalMuppet 13y ago
  "Fake agile" is essentially lying to yourself about what your process is. I can't imagine any situation where that was actually useful.
  - 13y ago

herghost 13y ago

In my experience "agile" isn't really a thing, more an excuse or reason to not follow any rules at all. Devs get to play at building whatever they like, solving the problems that interest them in a haphazard way and leaving behind a trail of half-written, semi-functional code with little or no documentation to allow anyone to work with them. As soon as anyone suggests that there's a plan, or god-forbid, an objective or expected outcome from the invested money, everyone suddenly scream, "AGILE" and that, apparently, is enough to shutdown any and all detractors. But then, try to suggest that there's a requirement that has changed or come to light and suddenly the "agile is open to new requirements" part of the approach is forgotten as the "progress" that's been made so far is too precious to change. /rant

UK-AL 13y ago
That's odd because agile methods like scrum have a definition of done, which has to be complete before you can class an issue as done. definition of Done usually includes things like written code, unit tests, code review, documented etc I suspect most people doing a agile, don't actually do agile. And think its a term for little structure. Agile methods, such as XP programming are highly disciplined methods, more so than traditional. The main difference is that they react to customer change, and don't follow plan than stretches 6 months into the future. The priorities of tasks can change from sprint to sprint. Allowing the team to react to the outside world.

Yhippa 13y ago

This reminds me that anything "Agile" and enterprise business is fundamentally incompatible thanks to the quarterly earnings report (for public companies at least).

gdubs 13y ago

This describes a certain kind of corporate agile that I like to call "Agile in a Waterfall".

eitally 13y ago
I think this is probably the most common "style" in most large enterprises. The people footing the bill still demand macro level waterfall estimates, but when it comes time to execute the project, it's split into smaller phases (perhaps 4-6mo) which are in turn split into 2-4wk sprints. In my personal experience as an enterprise apps director, this is significantly better than pure waterfall but still causes all sorts of stress on the IT side. I think the single highest impact change for the better would be to take a product-centric rather than a project-centric perspective. At least in my company, business "owners" don't pay for KTLO work, only projects, so there's no incentive for anyone to ensure high quality products.
UK-AL 13y ago
Yes, in larger companies the development is Agile but overall its waterfall. It misses important aspects like constantly verifying the product with customer, and adjusting if required.

thenipper 13y ago

This is so on point for any company not just software ones. I work at an NGO and not a tech company, and this just reminds me of every meeting we have about internal processes. We end up creating grandiose plans, but they usually just turn into endless bullet points for strategic road maps rather then actionable items

dschiptsov 13y ago

The buzzword of the day is "reactive".)

coldcode 13y ago

If this is half-arsed, then what is the enterprise definition of full-arsed?

arethuza 13y ago
Probably CMM Level 5

avighnay 13y ago

In my language we have an ancient term/story called 'Yaanai Kanda Vaadham' meaning the 'debate on the elephant' (the origin of the story is controversial so lets leave that out). Perhaps you have heard the story, four blind friends come across an elephant, each one holds a part of the elephant and equates it to what he knows and understands. Hey! there is a wikipedia page on it http://en.wikipedia.org/wiki/Blind_men_and_an_elephant http://en.wikipedia.org/wiki/Blind_men_and_an_elephant When merits of processes are discussed devoid of its purpose (delivering quality software in business relevant time), the argument is similar to the story. The process is just the means of reaching the purpose isn't it? It is not like successful software was delivered only in the last decade, we have been to the Moon and back before that. Unfortunately, processes are always made in good intention to achieve a purpose, this when transmitted from one person to another becomes a system, as there is no guarantee or way of enforcing 100% knowledge for all people in the chain. This deviates it pretty quickly from the purpose with focus only on the practice and soon the system becomes a religion. Then surprise! people shed blood over it after that demanding that their book is the only truth :-)

asolove 13y ago

It's interesting because "agile" can fail on both sides. This lampoons the enterprise side, in which you adopt "agile" practices inside rigorous change control and long requirements documents. But there is also the cowboy/ninja failure mode, in which "agile" is used to rule out any strategic thinking, technical design, or requirements gathering. Not only can you fail on both sides, but you can be too far on one side and think that you haven't gone far enough. I've had startups tell me they were doing Scrum, but it had gotten so hard to estimate their work that they had "broken agile" by having "grooming sessions" to talk to stakeholders about upcoming work before it got into sprint. They were shocked to learn this was a required part of Scrum and that many books recommended that being up to 10% of the team's time. Another company I talked with was so concerned about their developers "continuously delivering" code that they were fighting to be "more Scrum" by changing their QA folks to be in a staggered sprint one week after the developers. They were shocked to learn that this was a widely-tried and widely-panned approach that was philosophically opposed to the roots of Scrum. Now, I remember hearing examples like these before I had really dived into Scrum, and assuming it was a "no true Scotsman" where, whatever you did, someone would find a way to say it wasn't Scrum. But after some very good books and talking with experienced people (who were involved in the early stages, not bandwagon consultants), I now feel like I actually understand what Scrum is for and when it works, and can quickly spot people who don't understand the philosophy. Has anyone else experienced this? I wonder whether it is real experience or just an illusion my brain has created to give meaning to many months of painful trial and error. Nowadays I think of scrum as being about holistic product creation, about building a team that can deliver what customers will pay you for over the long-term. That requires breaking down most "process" to get "one-piece flow" on a complete team working as one to deliver new features. But it also includes the team building its own processes to make sure they are building the right thing to a high level of quality. That vision is anathema to cultures that value technical prowess, or pure speed, or meeting corporate objectives, or anything else other than building a team that can deliver value to customers over the long term. It's a challenge and a priority change for both corporate political environments and built-to-flip startups. And it's surprisingly hard to find a company that wants to pay you to build things their customers like, rather than using some other metric.

UK-AL 13y ago

mbesto 13y ago

One word: budgets. The problem with "enterprise" isn't their reluctance to adapt agile principles, but rather that people need to know "if I pay X, then I should get Y" - agile basically says "we think we know what X is, and we know your version of Y isn't what Y will become"

klodolph 13y ago
The enterprises that think that large software projects can be completed with "pay X get Y" are the ones that fail, historically speaking, because software projects are subject to a much higher risk of budget and schedule overrun than other types of projects (such as civil engineering projects). Large IT projects have put more than a few large companies into bankruptcy.
wpietri 13y ago
Yes. I think the solution to this is to get rid of budgets, and go for an approach based around iteration, risk reduction, and a flow of delivered value. That sounded insane to me at first, but the Lean folks really turned me around on this. Mary Poppendieck's books are great in this regard. One of her best examples is the Empire State Building: they started construction on the lower floors before the top floors were even designed. Nonetheless, the project was completed on schedule and budget. How? As with Agile projects, scope was treated as variable, and a lot of thought was put into maximizing efficiency of the system. I've also read some great stuff from the Lean Manufacturing community on how shifting the approach to accounting is vital. Rather than having annual plans and budgets and then trying to hit them, you have rolling projections n months out and adjust allocation to achieve real-world effects.
- mbesto 13y ago
  Yup. The problem is trying to explain to a client: "Ok, so we've got the 4 best back-end developers, 2 best UX/UI guys, and a scrummaster. Now they'll cost you $100k/month, and we think that'll create 3 apps for you, but ummmm we're not sure. But these guys are the best, so on average you'll get more production out of them if you don't do agile" My conclusion is that agile only works with talented people; most of the enterprise clients I've work with (non-SaaS stuff) don't care whether they are Linus Torvalds or Joe Shmoe, they just want to spend their budget and get their "app" within the budget.

badman_ting 13y ago

I dunno, sometimes going back to waterfall sounds kind of nice. I'm tired of the lack of direction, the attention-deficit school of project management where every 3 months there is some new starry-eyed vision we all chase after. I know this means my company is "doing agile wrong" and all that shit, I just would rather be on a slow train wreck than a fast one.

willismichael 13y ago
If it's going to be a train wreck either way, I'm not sure which I would prefer. Maybe jump and find another train?
UK-AL 13y ago
The problem is that business conditions do change that fast. However for a lot of small companies it is better than what they had before, regarding consistent direction. Lots of startups change scope or features daily and are in a constant state of panic. Having a fixed two/one week sprint provides same restspite for developers. But still allowing feature and priorities to be changed after each sprint.
- badman_ting 13y ago
  That's what I thought for a while too, but most everything I have made in the last 2-3 years got shoved in a ditch. We're not responding to the market, we're just flailing around trying different dumb stuff.
StudyAnimal 13y ago
I bet you hate startups then, and all their pivoting!
- badman_ting 13y ago
  Sure. I don't think I would ever work at one, although not for this reason.

saosebastiao 13y ago

It is a plain fact that people rarely distinguish between philosophy, religion, and culture. As a former mormon who served a mission in a foreign country, I witnessed this first hand: American missionaries (mostly from Utah) trying to superimpose their culture on foreigners and calling it religion, while foreign members pushed back (appropriately IMO) when they felt that the religion didn't really clash with their culture which was being stripped from them. Now I am seeing this from an outside perspective; I'm not a programmer or software engineer but I work directly with them in a weird sort of non-supervisory product manager role. In my opinion, this is no different...in fact, "Agile", which as far as I can tell is nothing more than a hand-wavy underspecified form of Extreme Programming, has so much ambiguity in its definition that you can't ask any two advocates and get the same response as to what it is. And as such, whenever there is a problem with the outcomes of the process, the only apt response is the No-True-Scotsman fallacy...which makes development descend into the phenomenal failure of productivity that all holy wars are. This isn't unique to Agile. Lean and Six Sigma are also mixed bags of philosophy and process, and they have been mixed bags of occasional success and phenomenal failure.

UK-AL 13y ago
Agile is underspecified because it is a general philosophy. I.E React to change, rather than following a 12 months rigid plan. There are different concrete ways to implement Agile, such as using Scrum, DSDM, or various other methods.