Manifesto for Half-Arsed Agile Software Development

http://www.halfarsedagilemanifesto.org/

by virtualsue • 13 years ago

102 63 13 years ago

allochthon• 13 years 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• 13 years 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.

wpietri11• 13 years 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.

al2o3cr• 13 years ago

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

neosergio• 13 years ago

TRUE. The problem are the people who consider themselves as "agile".

chris_wot• 13 years ago

Finally, someone who spells "arses" correctly!

jhare• 13 years 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• 13 years 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

taoquay• 13 years 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.

wpietri11• 13 years 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... 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• 13 years 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• 13 years ago

"Fake agile" is essentially lying to yourself about what your process is. I can't imagine any situation where that was actually useful.

StudyAnimal4• 13 years ago

I think most teams using agile, or developing software with some agile practices are in fact working within a hybrid process, where the requirements gathering and analysis, the writing of offers and contracts, and sometimes the delivery of the software all happen in waterfall style phases, and only the development itself is conducted in iterations and with agile technical practices. I still think this is a bit better than full on waterfall. Depending on context of course. It may not be as good as full on agile either.

wpietri11• 13 years ago

In a word, no.

There are actually reasonable techniques for doing Agile internally if you have clients who believe they need a traditional requirements-based contract approach. So those people should just do Extreme Programming.

For people with huge legacy projects, I think they really need to do the cost-benefit analysis. People like Michael Feathers make a persuasive case that you can slowly clean up legacy code, and that's much more economical than just suffering through expensive and risky changes.

But if somebody is deciding not to do Agile for considered cost-benefit reasons, they should just say, "Yeah, Agile doesn't make sense for us. We're going to do waterfall." Or they could choose a mini-waterfall process, or any one of the pre-Agile processes that suits them. (If those people exist, they should read McConnell's Rapid Development, which catalogs the options pretty well.)

If that's what they want, godspeed.

The people who make me crazy are the ones who don't actually have the discipline to use a real Agile process and also lack the guts to say, "Yeah, fuck that Agile stuff." I get that people would like to be all hip and Agile, but sending somebody out for a 2-day "certification" and then changing a few labels is not actually making better anything internally, and it's making my life worse.

I don't want people to be fake anything. Be real, everybody! Especially managers. Because it's only admitting where you're at that's going to let you get somewhere better.

analyst74• 13 years ago

I'm not expert in Agile, but from the pieces I used, and ones I read, Agile is not something you can do "perfect".

Agile is not something you can follow to the letter, like you said it's a bunch of processes that help you succeed. Which ones to apply, and more importantly, how to apply each process is highly dependent on the circumstances.

UK-AL6• 13 years ago

Most people call it a framework, rather than a process. You could call it an empirical control process, which means it adjust based on previous history.

dragonwriter3• 13 years ago

Agile is not something you can follow to the letter, like you said it's a bunch of processes that help you succeed.

Agile is not a bunch of processes. Agile is a philosphical orientation that guides how you do work, including selection and evaluation of processes in light of current team and mission.

wpietri11• 13 years ago

In my view it's a family of processes.

The way we got the term Agile is that a bunch of people in the '90s were experimenting with processes that were less insane that the waterfall approach that had come to predominate. DSDM, FDD, Extreme Programming, Scrum, and probably others that I'm forgetting now. All of those people got together and said, "Hey, we all have something in common. What is it?"

The answer to that was the Agile Manifesto: http://agilemanifesto.org/

Agile is to an actual process what a subdivision is to a house. If you say you live in the subdivision but are not in an actual house, then you're just wandering around camping in back yards and parks.

I agree that a given process is a collection of practices, and that one can compose different practices into a process, sort of the same way a talented chef can walk into a farmer's market, see what's on offer, and compose a balanced, nutritious, and tasty menu on the fly.

However, in practice, what "doing Agile" mainly means is what happens when an energetic but unskilled 7-year-old decides to be helpful and make dinner. Maybe you get a dinner composed entirely of candy. Maybe they use the stove and make something that is a mud-pie version of a gourmet meal.

That isn't to say that people can't create a good process out of raw practices. It's just that doing it is an expert-level activity, and it requires an immense amount of dedication, experimentation, and careful thinking. That's not what I see when I ask after shops that are "doing Agile". That phrase seems to be used exclusively by people who don't want to think hard about process, and just want to cargo-cult and half-ass their way through things because they're focused on getting a project out the door and/or pleasing the HiPPOs.

pyre2• 13 years ago

somebody saying their house is in America, but not in DC or any of the states

I live on Midway Atoll, you insensitive clod! ;-)

(http://en.wikipedia.org/wiki/Territories_of_the_United_State...)

wpietri11• 13 years ago

I almost said "states or territories", but DC is technically not a territory. And covering all the bases threw off the sentence. This being Hacker News, I knew I couldn't win. ;-)

buro9• 13 years ago

I'm in a co-working space and there is a guy who is a consultant who sites nearby and helps his clients "do agile".

His interpretation of this seems to be "Wing it, and if questioned just explain that we're reacting to change which is the agile way.".

wpietri11• 13 years ago

Yeah, that is the code-n-fix flavor of "doing Agile". Sigh. As Dilbert has it: http://fivetechsoftware.com/wp-content/uploads/2013/10/agile...

ItendToDisagree• 13 years ago

More often than not it seems that 'doing' Agile just means that people are supposed to have the false impression that they are working with a team... without being a team outside of meetings.

wpietri11• 13 years ago

Exactly. For me, a lot of the pseudo-Agile failure turns on not having actual teams. Teams are groups of people that win and lose together. But so often, companies are structured so that individuals win and lose separately. Or the design "team" can win while the programming "team" loses. It seems like such a simple thing, but I have a very hard time getting people to notice it.

StudyAnimal4• 13 years ago

Just because there is no process labelled "Agile" doesn't mean it is meaningless to talk about "doing Agile". What if doing 100% XP by the book turns out to not be ideal or doing 100% Scrum by the book turns out to not be ideal, but the team finds they can achieve good results by mixing and matching their own collection of "agile practices" and even made up practices that are in some way inspired by agile values and principles (yeah I know that sounds a bit wishy washy)? I think in this case it may make sense for the team to claim "we are using a process that doesn't have a name but is inspired by the agile manifesto and consists of a bunch of agile practices that work for us" or for short: "we are doing agile".

wpietri11• 13 years ago

As far as I can tell, nobody who has actually taken their process seriously says they are "doing Agile". When you ask them what they do, they give a pretty specific answer. E.g., "Well, we started out with Scrum, but added a number of the XP technical practices and are experimenting with getting rid of iterations for a flow-based approach." Literally every time I have asked follow-up questions of somebody "doing Agile" it has been some variety of horseshit with Agile words thrown in to make it sound trendy.

As an aside, I don't know any serious Agile person who thinks that doing 100% anything by the book is a good idea. I think it was Ron Jeffries, one of XP's inventors, who said something like : "By the book XP is a good place to start, but it probably isn't where you'll end up." Agile processes all have an inspect-and-adapt component. E.g., the weekly retrospectives and continuous tinkering of XP.

herghost• 13 years 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-AL6• 13 years 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• 13 years ago

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

BWStearns• 13 years 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.

gdubs• 13 years ago

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

eitally• 13 years 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-AL6• 13 years 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• 13 years 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• 13 years ago

The buzzword of the day is "reactive".)

coldcode• 13 years ago

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

arethuza• 13 years ago

Probably CMM Level 5

avighnay• 13 years 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

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 :-)

asolove4• 13 years 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-AL6• 13 years ago

Normally a good User Story, with 5 - 20 lines of acceptance criteria are optimal size for change/feature request.

wpietri11• 13 years ago

Personally, I now consider that too long. I have built entire products using index cards with nothing more than 3-8 words on them, plus occasional temporary artifacts (whiteboard sketches, mocks, etc).

In my view, stories are tokens for conversation. Now when I deal with teams who are writing down more than a few words, I look for barriers to conversation. E.g., not all the right people sitting together, or too much work in process.

tieTYT2• 13 years ago

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

I get the "no true Scotsman" sense myself. What book(s) was most helpful in pinning down what scrum is and isn't?

dragonwriter3• 13 years ago

What book(s) was most helpful in pinning down what scrum is and isn't?

By definition, I think that would have to be the Scrum Guide [1].

"Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum."

[1] https://www.scrum.org/Scrum-Guide

asolove4• 13 years ago

I recommend "The Scrum guide" and "Extreme Programming Explained" as ways to learn about the systems themselves.

Thinking about it, the book that actually taught me to understand what the early agile people thought was Christopher Alexander's book "The timeless way of building." The book is about architecture rather than software, but the underlying idea is right on. It starts by addressing what is the point of building? Some people try to optimize speed, or predictability, or how good the building looks. But Alexander says the point of a building is to be lived/worked in, and it should be measured by how it improves the human lives of people around it. This implies doing the design and building in a whole different way, and thinking about the relationships between builders and users in a different way.

The "agile" idea is similar. People who try to "use agile" to accomplish their goal of just making software really fast, or making lots of money, are missing the point. Agile is actually about building software that is good, in a way that is sustainable for users, builders, and a company, and makes everyone involved better. If you use Scrum in the context of those values, you may succeed.

But the vast majority of people who adopt scrum, and perhaps the majority of consultants and explanations trying to "sell" Scrum, just use it to wring every ounce of effort out of your employees, or to ship something crummy fast. That ends up not really working, and in my experience making environments even worse than they were before.

dragonwriter3• 13 years ago

Your post tends to use "agile" and "Scrum" as if they were references to the same thing. Agile is an approach that puts "Individuals and interactions over processes and tools" and Scrum is an extremely rigidly defined set of processes.

Scrum might be a starting set of processes adopted by an agile organization, but an organization that is concerned with "doing Scrum right" is not Agile.

asolove4• 13 years ago

I'm sorry if I seem to be using the terms interchangeably. I do not intend to, but Scrum is the particular tactic I have seen used to accomplish what I understand agile to be.

I agree that anyone who is dogmatic about "doing Scrum" for its own sake is missing the point, as is anyone who is "doing Scrum" in order to just make their team more organized or productive. That said, within the constraints of the current business world, Scrum is the best way that I have seen to resolve the necessary tensions of creating software products and let people and interactions take center stage.

But I'd love to hear your experience and advice.

mbesto2• 13 years 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• 13 years 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.

wpietri11• 13 years 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.

mbesto2• 13 years 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_ting3• 13 years 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• 13 years 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-AL6• 13 years 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_ting3• 13 years 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.

StudyAnimal4• 13 years ago

I bet you hate startups then, and all their pivoting!

badman_ting3• 13 years ago

Sure. I don't think I would ever work at one, although not for this reason.

saosebastiao• 13 years 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-AL6• 13 years 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.

Manifesto for Half-Arsed Agile Software Development

Related Stories