12 ms·

Agile Is Dead (Long Live Agility)

maxehmookau 13y ago
Spot on. The word 'Agile', much like 'Big Data' has been misappropriated by marketers, who don't really understand it, the world over.
- Nursie 13y ago
  'Cloud'
fsloth 13y ago
Personally I find that this line "Responding to Change over Following a Plan" does much more harm than good. It should read "You should have a plan but should rather be prepared to change it constantly than stick with it dogmatically". I would say that when you are within a project team it should emphasize the agile values but once you are on an organizational level where several project teams need to co-operate to deliver a product the constraints given to teams should be formalized over the right hand side, strongly, but in a way that is ready to take immediate feedback from the realities. Preferably, my dream system would be formed of strong spec based contracts between teams, enforced by automatic tools and architects, who work as part of feature teams implementing features and have the ownership of the spec-framework and can swiftly change it to respond to changes. Completely forgoing specs and plans leads to anarchy and headache where the only two-channel communication with developers is facilitated by broken unit tests and system-test or (the horror) customer side regressions. Good software systems are composed through a firmly kept set of as strong constraints as possible, IMO, and someone needs to own the constraints.
- gns24 13y ago
  I think this hits the most interesting point. Personally I agree with the article that the best way to develop efficiently is to continually take small steps in the right direction and reevaluate where you are after each one - you save a lot of time by not planning things you don't need that way and it's much easier to maintain focus. But against that, people need estimates for how long projects will take and how much they will cost, and that demands a plan.
  - fsloth 13y ago
    "you save a lot of time by not planning things you don't need that way" Yes, but on the other hand you will lose time if you do not plan those things ahead of time that you can plan ahead of time. It's much cheaper to catch ill defined requirements while planning on paper than once the constraints reach production and people start implementing features and tests based on them. Although you cannot plan _everything_ there is always _something_ you can plan - and should plan. Unless you have a spec or a plan at day 0, you do not have a documentation platform available when the shit invariably does hit the fan and you need to do the learning-organization-disco and facilitate a change to your product because some real world constraints were not known or acknowledged before hand.
  - collyw 13y ago
    I am not sure I agree with that first point, having been involved in a short project, that just became one monstrous exercise in feature creep. That was essentially taking small steps in the right direction, but it never finished. I think it is beneficial to have a plan in certain situations.
- nardi 13y ago
  I think they worded it correctly. Notice it doesn't say, "Responding to Change over Making a Plan." Your version is horribly ugly. Theirs is succinct and poetic.
  - fsloth 13y ago
    I agree that my version is horribly ugly :). However, if you are not going to Follow a Plan, and while you're at it, you are attempting to Eliminate Waste as per the lean thinking movement, one may quickly follow with the conclusion that plans that are not followed are wasteful, and therefore unnecessary. My experience has shown me that this is the interpretation people very often make. YMMV as always, though.
    - nardi 13y ago
      Preferring to Respond to Change over Follow a Plan doesn't mean you never follow the plan. It means that when changing circumstances conflict with your plan, then you respond to the change rather than blindly follow your plan.
  - ternaryoperator 13y ago
    I think what the Manifesto was targeting was "blindly" following a plan. In those days, reqs were drawn up, a design spec'd, a plan written out and there tended to be considerable resistance to changing the plan. That's what they were aiming at.
- gadders 13y ago
  >> "Under 2.4, can we have more jobs in the jobstore and is the console more optimized?" I agree with this. You create a plan so you have an idea when the project will finish, when resources will become free, when you deliver to other dependent teams etc. That doesn't mean the plan is cast in stone and once the Gantt Chart is finished, it never changes. Obviously, you do what you can with scope, resource moving, etc to keep to original dates but if you can't, then the plan should be updated to reflect reality.
- Angostura 13y ago
  > It should read "You should have a plan but should rather be prepared to change it constantly than stick with it dogmatically". I'm going to steal this. Spot on.
  - dasil003 13y ago
    I believe Eisenhower said it best: "Plans are worthless, but planning is everything"
- mcv 13y ago
  > Personally I find that this line "Responding to Change over Following a Plan" does much more harm than good. It should read "You should have a plan but should rather be prepared to change it constantly than stick with it dogmatically". For all the points in the Agile Manifesto, the right hand term isn't bad at all. It's a good and important thing, but the left hand term is even more important. Plans and processes (in a large organization) are definitely important, but they should never trump change and people. Documentation is also important, just not as important as working code. Contract negotiation is unavoidably important in any business environment, but don't let it get in the way of cooperation.
  - weavie 13y ago
    Yes. I think this is one of the most important and yet misunderstood aspects of agile. You aren't throwing out the right terms, just re-prioritizing them.
lmm 13y ago
The problem is real but changing the word won't solve it - we'll just repeat the same cycle all over again.
- thebenedict 13y ago
  Seriously. I like the focus on practical productivity but was surprised by the conclusion. "Let's all change from saying agile to saying agility" feels like quibbling over semantics. (Fixed spelling, thanks)
  - nardi 13y ago
    semantics* technically that was a syntax quibble though, so the joke doesn't work as well
jayeola 13y ago
It's become another buzzword. Another phrase for people to throw at each other.
bananas 13y ago
I found that no methodology works as well as getting the right people in and let them organise themselves. If you have the wrong people, it doesn't matter what methodology or process you bring in, you're screwed. On that basis, methodology isn't that relevant. I just watched a company apply SCRUM to apparently solve process problems and it just made things worse because the staff aren't disciplined or interested in what they do. That's after five years of agile consultants and perpetual change. If you want a manifesto with real values: 1. Fix shit when it goes wrong right away. 2. Tell people what you are doing. 3. Write everything down somewhere centrally that everyone can get to(tickets) 4. Have a rough vision and make sure people are working towards it. Don't plan the details too much. 5. Be opinionated. Someone's got to win an argument. that's it.
- jpkeisala 13y ago
  Well said.
- mpweiher 13y ago
  "getting the right people in and let them organize themselves" That's a large part of what agility was/is about. The rest also matches up pretty well.
  - bananas 13y ago
    Actually I disagree. The large part (possibly not the intent) was about building a consulting empire around something utterly vague with multiple religious opinions about the best way to perform these manifesto actions. A vehicle for rats.
    - mattmanser 13y ago
      In much nicer terms as he worked with them, that's the gist of what the article is about. Did you read it?
      - bananas 13y ago
Ingon 13y ago
Yeah Agile is used as a way to make money now days. For what other reason there are Agile consultants, Agile agencies and Agile certification. I firmly believe that Agile is about doing what makes sense in this team right now. You let the team to decide on their process, on their way of work and get away. And for good managers this is enough - you are empowering your team to succeed. Recently I had a great success demolishing standups in our team. We clearly weren't getting enough value from them (I though they were plainly hurting us), so it was time for change. I had a great resistance from the management team, but some developers were keen to try a change (some of them were long enough in the industry to remember the pre-agile days, when we were delivering software too). So we tried it for some time, everybody loved it, and we stopped doing it completely. Now days we all agree that iterative development is the way forward. We should also think if we can apply the same on a meta level - the team, the process, the product, the design, the organization. Do small steps, check if you are going into the right direction, repeat. It may work :)
- hox 13y ago
  What was it about your standups that were hurting your team? I'm on the fence with daily standup meetings. they definitely can help a team communicate when there are a large number of external forces at play in a larger organization and if there are no underlying asynchronous communication channels available. on the other hand, in a team that communicates regularly with historical communications available to new team members, they aren't as useful.
  - Ingon 13y ago
    Among the negatives of standups are: - Rarely the right information. Every person in the team have different needs for information. It is even harder to deliver the right amount and on the right level if your team includes designers, quality engineers, project/product managers. - Rarely at the right time. If your company culture includes flexible hours, no matter at what time you put the standup somebody will suffer. Most of the time the team members who come early suffer - they already started work, now you are forcing them to get out of context and attend a meeting. - Sometimes standups are used as a way to force some team members to do what they have promised (the what I'll do today). But if you are using them in this way is really counterproductive - you either trust that your peers are doing their best for the team or you might consider team change (which I understand is beyond our control sometimes). - Failure to communicate (or "the what problems I have/had" part). If your team members are mature enough and they had a problem during the course of the day, they shouldn't wait for the next day's standup to let everybody know about that. The should be proactive and seek resolution as the problem comes up. - Finally the "what I did yesterday" part. This information is commonly used by the managers, but there are better ways to deliver it. Most of us use some way of tracking our work. We only need to flow this information to our managers. It is also a mind shift for them - instead somebody pushing this information to them, they should be proactive and seek it and pull it. If you don't know what somebody is working on, then go and ask him. You don't need to loose the time of the whole team for this. That being said whether you will use standups or not depends largely on your team dynamics. In new teams or teams formed largely by junior developers it makes sense to have standups - its a way to force communication patterns and certainly can be used as a casual form of a team building. But in my opinion as the team matures there is less and less need for standups, so at one point it just becomes a hurdle. And the good thing about being agile (not SCRUM) is that you can evaluate your process and change it as you (and your team) see it fit.
teamfuture17 13y ago
You're right that good ideas like eco and also agile follow that growth curve. After a while the original idea and intention is partly lost on the way to economy and marketing. I observed that in the organic movement around 2000 as well. It is never totally lost, the impulse improved reality, but we need new ideas, new movements to hold spirit, values and ideas high. I don't know what you think about our impulse wholeheartedmanifesto.org which we started this February. Let's focus on the doing and on being authentic.. that's what counts. Thanks for your blog. Christine
planetjones 13y ago
Well said. A friend of mine is another company are supposedly moving to "Agile". Their approach is to have whole day meetings to discuss how it will work! Three months later they're still planning how their Agile, Scrum based thing will work. The conferences, the consultancies, the big companies, etc. really have destroyed the essence of the Agile manifesto in many ways.
- mcv 13y ago
  It's not that they've destroyed the essence of the manifesto, it's that the organization is simply inherently not agile, and incapable of dealing with agility. This is pretty common for large organizations (thought there are also a lot where it kind of works). Their real problem isn't so much the introduction of Scrum, it's changing the very nature and culture of their organization. They should focus on that first, and then Scrum will follow naturally.
- a_c_s 13y ago
  That's why I like to make the distinction between little-a agile (the non-dogmatic vision of the original manifesto) and big-A Agile (rigid, sold as a product methodologies backed by expensive certifications).
- steveklabnik 13y ago
  I once worked at a company that was in their third year of transitioning to Agile.
neverminder 13y ago
I never really understood this whole rage about agile and some people preaching it like a religion. You can't fit everyone in one frame, people are different. As the matter of fact the better the engineer the more quirks he will have. Some people like to jog, some like to sprint and rest, but if they cover the same distance and reach the finish in the same time, who cares what methodology they use? Even though I probably use quite a few agile ideas I don't call it agile or anything else, I call it development.
- mironathetin 13y ago
  Good comment, neverminder! I always understood agile development as a way to organize your team and yourself in a way that works best for everyone. So don't follow a scheme, even if it's called agile, but think yourself. Probably this is, how I WANT to understand it, because I don't like to follow rules that make me unproductive, even if others may become more productive by following the same rules. Who does?
- obitoo 13y ago
  Excellent running analogy, i'm going to remember that!
usea 13y ago
The agile principles are fairly solid, as far as principles go. They're people-first and they downplay process and planning. You can't blindly follow a plan, process, or ideal. Think. Communicate. The right thing to do changes in every situation. You can't follow dogma. But the idea that we should switch to a new word because the old one has been abused makes no sense. Why rally behind a word? Brands and labels only serve to stop people from thinking. They go against the whole idea. Words become dogma. Hell, even principles become dogma. Trying to distill it down to something that's easy to digest robs it of its value. The solution isn't a better dogma. It's people who can think. If you don't have the right people, no principle will save you.
- Spearchucker 13y ago
  You can't blindly follow a plan, process, or ideal You can. The question that you might ask is whether the plan is good or not. You can't follow dogma As above. Dogma actually has its uses. The trick is knowing how, where and when to use it, or someone who is dogmatic. Machiavellian, but its a tool nonetheless. Saying we don't need a plan is to thumb our nose at thousands of years of wisdom. Sun Tzu was not stupid when he suggested choosing a path only once the objective and environment are understood. Stephen Covey puts the same concept into modern terms when he suggests beginning with the end in mind. And that brings us to the disconnect we live in. Developing something using agile practices does not require a plan. A plan is however required at a level above the developer to steer development. As you go, you'll find yourself becoming interested in that plan more and more. It's a natural shift because the plan reflects the strategy, development is purely tactical. Understanding the strategy is motivational - it answers the why. Development is all about the how. Real value as a developer only comes from experience. An experienced developer is successful in spite of any methodology, approach or framework, not because of it. Something else we're really good at blinding ourselves to. Experience has no price. It amuses me to no end that we as an industry place higher value on the 20-something hacker than we do on the 50-something veteran. We're unintentionally letting culture hobble our chances of success.
  - usea 13y ago
    You are right on all counts. I should be more considerate with my thoughts and words. I appreciate your nuance. Thank you. I would not eschew a plan, but I would alter or abandon it when it's favorable to do so. I meant only to advocate pragmatism, not anarchy.
alphadevx 13y ago
I once attended a meeting where a manager said "We won't be doing agile, but we will work with more agility", which basically translated to we won't be changing our existing process. Agile to me is real: it has not been diluted as I know exactly how I will implement an agile process (scrum in my instance). I don't care if others misuse or misunderstand the term. For me it's concrete.
- mcv 13y ago
  > "We won't be doing agile, but we will work with more agility" At a previous client, I was sitting next to a really nice poster that emphasized the difference between "doing agile" and "being agile". You don't "do" agile. That's simply not a thing. You have to be agile. Working with more agility is totally fine. But if you do that, it means you won't be sticking blindly to your existing process, it means you should consider what you actually need from that process.
mcv 13y ago
I understand what he says, but from a grammar perspective, he's wrong. He complains that Agile, which started out as an adjective, has been turned into a noun. He wants it to be an adverb instead, so he introduces agility, which already is a noun. And then he says it's not a noun. (I'm sorry, but I just couldn't not point that out.) But other than that, I agree. What should be making our work easier has been turned into something complex by itself. Though in a sense, maybe that's unavoidable. Not everybody truly groks agility, so they have to be taught, which means training and certification. Although personally I think if you don't innately understand it, you can't learn it in a workshop either. Maybe you need to discover it through experience, and I know people who never will. So where does that leave us? Only the people who grok agility should work this way, and those who don't should stick to something else? What about the companies who want the hip new buzzword, but also want to have some handle on the process they're using? An agile process like Scrum definitely fills a need, but I've also learned that Scrum in one place can be totally different from Scrum in another place. Nobody completely follows all the ideas of Scrum, but maybe that's as it should be: adapt what you do to what you need. And there may be a limit to the amount of agility some companies can deal with.
- NAFV_P 13y ago
  > I understand what he says, but from a grammar perspective, he's wrong. He complains that Agile, which started out as an adjective, has been turned into a noun. He wants it to be an adverb instead, so he introduces agility, which already is a noun. And then he says it's not a noun. (I'm sorry, but I just couldn't not point that out.) Your knowledge of English programming is excellent, it is a rare and underrated skill. I can only recall one article on English coding posted on HN [0]. BTW love the double negative at the end. [0] http://antirez.com/news/61 http://antirez.com/news/61
- vorg 13y ago
  > He complains that Agile, which started out as an adjective, has been turned into a noun. The only programming languages I know of that use adjectives for their names are "Basic" and "Groovy". So this suggests when adjectives are used as nouns is a strong indicator of consultants flogging faulty processes and products for both development methodologies and programming languages alike.
malaporte 13y ago
Funny how this post made me realize I've often been confronted with people wanting to implement 'agile' by imposing us to follow strict processes. I'd never seen it that way, even if the irony is pretty obvious.
burkestar 13y ago
Disagree. Language is not an immutable thing and is always evolving in its use to reflect the concepts of the people using it. I think capitalizing Agile as a noun makes it a "thing" that we can refer to collectively and ultimately helps us communicate about the concepts that it entails. The unfortunate down-side is when a popular term is misused due to ignorance and misunderstanding by a large group of people - which will happen more prevalently as a word becomes popular. As someone who has had the pleasure of receiving Scrum coaching from Jeff Sutherland, I can say that there is a HUGE difference in understanding between people who spend time to learn it (from a book or coach) and those who muddle their way through - never taking the time to learn about it more deeply and put it to practical use (the only way to truly learn is through doing). I work at a small company and teach an internal course on the principles of Scrum to our project managers, so I have first-hand exposure here. It's amazing how really smart people who have heard the terms used for several years and even claim to have been involved in Scrum teams at past jobs still have many misconceptions about the core principles and how to practically apply them when the situation arises. There is definitely a shallow understanding amongst a good majority of developers and it's exacerbated by companies that claim to use "Agile" practices yet have only really scratched the surface. It's immediately clear that many have used "Scrum-but" and really only do standup meetings as if that will be all that is needed. Actually many people think Scrum is "that process where you hold standup meetings". I like Scrum because it brings together not only a way to manage a project, but more importantly a way to lead a team of people! I think being a servant leader to the team and providing them the necessary resources to be at their peak effectiveness is a trait of a good leader. It's actually kind of amazing all the different ways even very smart people can get "stuck" - distracted by a less important task that is shiny and interesting, slog through hours of debugging to resolve an issue that someone else on the team could have helped them with, not communicating with other team members that they can't get their part done unless another has provided them something first. From experience, just helping people identify these blockers and get the team unstuck has been a big win. I think tools absolutely are a big help too. I've used sticky notes on whiteboards and it's good for small teams that are co-located. It breaks down for distributed teams. We just started using JIRA and it is surprisingly good at helping us managing all of our work which would grow unwieldy using more primitive methods. I'm not sure how I feel about the agile manifesto. I guess it has its historic place as a reaction against the poor waterfall practices of the past and paved the way for new methods to emerge. Besides that, it seems a bit dated and hasn't served a useful practical purpose for me.
willvarfar 13y ago
Here's my favourite post about Agile: http://pindancing.blogspot.com.au/2009/09/let-agile-fad-flow-by.html http://pindancing.blogspot.com.au/2009/09/let-agile-fad-flow... Very worth reading entirely.
- McUsr 13y ago
  I liked most of the generalizations in the blog post,I think that if he isn't 100% right, then at least he is really on to something. The place I balked, is where he said that design patterns are almost dead. I find design pattersn to be invaluable, and so does at Apple Computer and with them millions of developers, so the death of design patterns is a bit premature.
- astrange 13y ago
  Although it's a little off topic, I'm fascinated by how much time 2000s bloggers spent namedropping all the other bloggers (see paragraph 2). When someone mentions your name all the time, they're trying to sell you something, but what did it mean to mention other people's names all the time? If they're selling the message that they're Spolsky's close personal friend, it's hardly working. I guess it lets you steal their page views if you summarize their post…
davidgerard 13y ago
tl;dr you still can't Taylorise clue, but that'll never stop the Mgt. trying.
- beat 13y ago
  I think that's the quote of the day. :)
benjaminwootton 13y ago
The author is quite defensive about the commercialisation around agile. I don't think this is warranted. I'm a developer, but I have described myself as an agile consultant in the past. This isn't out of cynically spotting an opportunity to make a buck. Its because I've spent a lot of time working in agile environments, learning the pitfalls and how to do it well, and want to share what I really and genuinely think is a better way to deliver software. When vendors and consultants start to coallesce around an idea, it usually means that the idea is a good one that is gaining traction, coming down from the ivory tower. It's a positive thing and not something to leave the community that you founded over. I've heard this argument many times over the years, and it always sticks in the throat a little. I'm evangelising an idea that I passionately believe in but am seen to be selling out the community ideals somehow. I walk the same line on my current venture in the DevOps space.
- SiVal 13y ago
  All of this is quite predictable if you just ask yourself what kind of people refer to their personal opinion papers as "manifestos".
  - ternaryoperator 13y ago
    I understand your point, but in context it's a bit unfair. The manifesto was issued in 2001, when waterfall was still the default methodology at most businesses. They were indeed trying to break out of that mindset and felt they were doing something revolutionary (which, in fact they were).
    - RogerL 13y ago
      I worked on big government projects using military standards that more or less imposed the dreaded 'waterfall'. What was our mantra? "Design a little, code a little, test a little". Agile re-invented or popularized various ideas that had been around for a long time. As always, you adjust for the problem at hand. Royce, the so-called inventor of waterfall (he presented it as an obviously flawed concept, a straw man), argued for copious documentation. Documentation makes a lot of sense when trying to built a jet-liner, and is often a time and money sink if you are trying to write, say, research code for computer vision. So, "revolutionary"? I dunno? Certainly many places had taken the deliberately flawed Royce model as the way to do things, and so there was a big change as far as that goes. But I can't recall a time where some form of iterative/evolutionary development method was not known about and practiced, or where decision making was favored over process. To make this clearer - the Royce-ers patted themselves on the back, and then got hopelessly entangled with process. Yourdon came along. Wow, was that a great process - which everyone got entangled with. Then there was Booch..... And now, we have Agile. The details vary, to be sure, but the fundamentals remain the same. Some good ideas for approaching engineering a solution gets turned into conferences, endless books and training, independent consultants, certifications, requirements to be certified to win contracts, and on and on. I'm old.
jrochkind1 13y ago
Yes. Thanks for writing this Dave Thomas.
jrochkind1 13y ago
> anyone who comes up with something bigger or more complex is just trying to sell you something. I don't think being misled by snake oil salesmen is the only, or even the primary reason people get misdirected away from true agility toward 'agile'. There are intrinsic motivations and interests in most human organizations which lead against actual agility. A few of these include: * The need for people in many positions to feel and be able to represent themselves as in control of the process and product; * the desire to have someone else to blame when something goes wrong; * the interest in shortcuts and magic bullets, instead of realizing how much work and time things will actually take (including from non-technical stakeholders). There are social/organizational reasons that make true agility hard, especially in large organizations, especially in organizations where software dev/IT is just one component of a larger mission. But that doesn't change that actual agility is the only way to produce high-quality software efficiently. And we probably do need people investigating and suggesting how we overcome these barriers; but indeed, the 'agile' industry has not succeeded in doing so, they mostly take the easier path of figuring out how to cater to these barriers while calling it 'agile', instead of how to change organizational culture and surmount them.
caboteria 13y ago
Be wary of any methodology whose name begins with an upper-case letter.
projectileboy 13y ago
Dave didn't seem to mind cashing the checks he got for all the "agile" books his company published. This piece would have been interesting in, say, 2008, but now he's just riding the wave.
- lucisferre 13y ago
  From what I can see none of his own books are actually about "Agile". In fact "Agile development with Rails" is probably the only one that used that word in the title, and I can't really fault him for taking advantage. Also he wrote some quite good books, 'Pragmatic Thinking and Learning' come to mind. I don't think your comment is particularly fair, nor does it diminish the point he is making in any way even if you're right.
  - projectileboy 13y ago
    His words: "Once the Manifesto became popular, the word agile became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, co-opted to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand." From his company's website: http://pragprog.com/categories/practices http://pragprog.com/categories/practices I think the callout is appropriate.
    - lucisferre 13y ago
      No not really. None of those are books he wrote himself. He runs a book publishing company. It's primary purpose is to publish books people want to buy. Though I'll agree that many of those authors capitalize on the exact things he is railing against in his post.
  - robin2 13y ago
    "Pragmatic Thinking and Learning" was Andy Hunt, but as he and Dave Thomas are kind of a double act I can see why you'd get mixed up. As to your point about whether they wrote any books on 'agile' I think it could be argued either way. More specifically, whether or not "The Pragmatic Programmer" (the book they made their name with) counts as a book about 'agile' is an interesting question, and one that throws some light on the wider debate. Although they sometimes talk about "pragmatic programming" as if it were a thing, in the same way as XP and Scrum, their approach was more one of giving a smorgasbord of potentially useful techniques and practices rather than codifying a tightly defined set of best practices.
rvinay88 13y ago
I like the comments section in this article. The industry really isn't as bad as the writer thinks. Also the other comment that the word is bastardized but the values live on is so true. Changing the name to agility is only going to make everyone follow suit and convert that into a marketing buzzword.
NAFV_P 13y ago
> Of course, this involves a fair amount of thinking, and the basic loop is nested fractally inside itself many times as you focus on everything from variable naming to long-term delivery, but anyone who comes up with something bigger or more complex is just trying to sell you something. Basically, the process is recursive, but my explanation is more agile.
beat 13y ago
And today, I read this oldie-but-goodie over at Martin Fowler's blog... http://martinfowler.com/bliki/SoftwareDevelopmentAttitude.html http://martinfowler.com/bliki/SoftwareDevelopmentAttitude.ht... In Fowler's terms, the intent of the original Agile Manifesto was EnablingAttitude, but the result of the term "Agile" in many environments has been DirectingAttitude. It's a nasty cognitive dissonance - that "Agile" has in many places become a heavy, clumsy, tool-driven process that gets in the way of developers rather than helping them work efficiently. And I'm not saying this in the "just let us hack" mindset either, because I pretty much despise that sloppy, careless mentality. It doesn't work in environments larger than a few people, much less genuinely large projects. But process needs to be scaled to team size, talent, and risk tolerance. A broad-strokes "Agile" process that restricts competent teams is worse than useless.
- michaelochurch 13y ago
  And I'm not saying this in the "just let us hack" mindset either, because I pretty much despise that sloppy, careless mentality. It doesn't work in environments larger than a few people, much less genuinely large projects. There's a surprising low upper limit on the size of a closed-source codebase before which it becomes a lead weight. Why? Because large projects (beyond about 6 devs in 2 years) without modularity generate a lot of maintenance work. (Modular design is to pay that maintenance cost upfront, which most executives don't like.) Maintenance needs to be done well, but the only thing that motivates good people to do it (instead of hopping to another team, changing jobs, or demanding a $500k+ salary) is either (a) caring about the module as a client, which means they typically aren't more than 25%-time maintainers because their main project is whatever uses the module, or (b) the possibility of gaining a national reputation in OSS. The open-source ecosystem can motivate the kind of work that large codebases need. (That doesn't mean they never turn to crap. It means that it's not inexorable.) Corporate codebases don't have that. Twitter hasn't open-sourced, for one example, Storm because they're nice guys (not to rag on them; this is one of a million examples I could use). That may be a factor, but the main reason is that they don't want it to turn to crap, and the open-source ecosystem is more robust against that than anything in the closed-source world. If you rely on something but it's not extremely proprietary, you should probably open source it for its own health. Proprietary stuff should probably be kept as data, not code.
michaelochurch 13y ago
So much of "Agile" is an attempt to "patch" the top-down, closed-allocation organization that is simply incapable of hitting technical high notes no matter how much it spends or how many people it hires. Since organizations are tough to change and all dysfunctions have champions (some deeply hidden) the "Agile" ends up having to make smaller and smaller motions while its desire for control, as the velocity in an irrotational vortex, gets stronger. Then it devolves into micromanagement, as discussed here: http://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging http://www.mountaingoatsoftware.com/blog/ssssh....agile-is-a... The reality is that the future just has no use for closed-allocation tech companies. Every tech company needs to decide either to play for real and try to excel (open allocation, highly selective hiring) or GTFO and do something else. Scrum is a formational hack, but closed allocation is a foundational problem and, if technical excellence is needed, a show-stopper.
- Nursie 13y ago
  I mostly agree, apart from the no future part. There are plenty of companies putting out bad software, slowly but profitably. They occupy various niches where the people doing the selective hiring or being hired selectively just aren't interested in playing. Sure, they could be out-competed by an agile, well-staffed, disruptive new competitor. They could be, but they probably won't be.
beat 13y ago
Meanwhile, I'm watching helplessly from the sidelines as "DevOps" becomes the next "Agile", tasting bile in my mouth and wondering when a brilliant concept for reworking the culture-clash problem between developers and operations got reduced to a "knows how to use Chef/Puppet" for recruiters.
- deleted 13y ago
  [deleted]
FeloniousHam 13y ago
Agree generally with the article, my particular views on Agile: 1. Communication, communication, communication 2. Short iterations 3. Concrete deliverables 4. Client/customer engagement with deliverables Everything else is details.
xsace 13y ago
There is some truth in this post. However I still thank the Agile "industry and business" as it allowed me to open my eyes as a developer years ago. Because believe it or not, some of the so called master/consultant are genuinely caring about the values behind the manifesto, and putting a lot of efforts into improving everyone practice of software development.
0xdeadbeefbabe 13y ago
Since, agile is dead it's time for the Knights Radiant approach to software: Life before death, strength before weakness, journey before destination.
rip747 13y ago
is it me or when an article is titled: "[something] is dead, long live [something]", you immediately want to flag it out of existence? seriously, comes up with a better title.

Spot on. The word 'Agile', much like 'Big Data' has been misappropriated by marketers, who don't really understand it, the world over.

Nursie 13y ago
'Cloud'

fsloth 13y ago

Personally I find that this line "Responding to Change over Following a Plan" does much more harm than good. It should read "You should have a plan but should rather be prepared to change it constantly than stick with it dogmatically". I would say that when you are within a project team it should emphasize the agile values but once you are on an organizational level where several project teams need to co-operate to deliver a product the constraints given to teams should be formalized over the right hand side, strongly, but in a way that is ready to take immediate feedback from the realities. Preferably, my dream system would be formed of strong spec based contracts between teams, enforced by automatic tools and architects, who work as part of feature teams implementing features and have the ownership of the spec-framework and can swiftly change it to respond to changes. Completely forgoing specs and plans leads to anarchy and headache where the only two-channel communication with developers is facilitated by broken unit tests and system-test or (the horror) customer side regressions. Good software systems are composed through a firmly kept set of as strong constraints as possible, IMO, and someone needs to own the constraints.

gns24 13y ago
I think this hits the most interesting point. Personally I agree with the article that the best way to develop efficiently is to continually take small steps in the right direction and reevaluate where you are after each one - you save a lot of time by not planning things you don't need that way and it's much easier to maintain focus. But against that, people need estimates for how long projects will take and how much they will cost, and that demands a plan.
- fsloth 13y ago
  "you save a lot of time by not planning things you don't need that way" Yes, but on the other hand you will lose time if you do not plan those things ahead of time that you can plan ahead of time. It's much cheaper to catch ill defined requirements while planning on paper than once the constraints reach production and people start implementing features and tests based on them. Although you cannot plan _everything_ there is always _something_ you can plan - and should plan. Unless you have a spec or a plan at day 0, you do not have a documentation platform available when the shit invariably does hit the fan and you need to do the learning-organization-disco and facilitate a change to your product because some real world constraints were not known or acknowledged before hand.
- collyw 13y ago
  I am not sure I agree with that first point, having been involved in a short project, that just became one monstrous exercise in feature creep. That was essentially taking small steps in the right direction, but it never finished. I think it is beneficial to have a plan in certain situations.
nardi 13y ago
I think they worded it correctly. Notice it doesn't say, "Responding to Change over Making a Plan." Your version is horribly ugly. Theirs is succinct and poetic.
- fsloth 13y ago
  I agree that my version is horribly ugly :). However, if you are not going to Follow a Plan, and while you're at it, you are attempting to Eliminate Waste as per the lean thinking movement, one may quickly follow with the conclusion that plans that are not followed are wasteful, and therefore unnecessary. My experience has shown me that this is the interpretation people very often make. YMMV as always, though.
  - nardi 13y ago
    Preferring to Respond to Change over Follow a Plan doesn't mean you never follow the plan. It means that when changing circumstances conflict with your plan, then you respond to the change rather than blindly follow your plan.
- ternaryoperator 13y ago
  I think what the Manifesto was targeting was "blindly" following a plan. In those days, reqs were drawn up, a design spec'd, a plan written out and there tended to be considerable resistance to changing the plan. That's what they were aiming at.
gadders 13y ago
>> "Under 2.4, can we have more jobs in the jobstore and is the console more optimized?" I agree with this. You create a plan so you have an idea when the project will finish, when resources will become free, when you deliver to other dependent teams etc. That doesn't mean the plan is cast in stone and once the Gantt Chart is finished, it never changes. Obviously, you do what you can with scope, resource moving, etc to keep to original dates but if you can't, then the plan should be updated to reflect reality.
Angostura 13y ago
> It should read "You should have a plan but should rather be prepared to change it constantly than stick with it dogmatically". I'm going to steal this. Spot on.
- dasil003 13y ago
  I believe Eisenhower said it best: "Plans are worthless, but planning is everything"
mcv 13y ago
> Personally I find that this line "Responding to Change over Following a Plan" does much more harm than good. It should read "You should have a plan but should rather be prepared to change it constantly than stick with it dogmatically". For all the points in the Agile Manifesto, the right hand term isn't bad at all. It's a good and important thing, but the left hand term is even more important. Plans and processes (in a large organization) are definitely important, but they should never trump change and people. Documentation is also important, just not as important as working code. Contract negotiation is unavoidably important in any business environment, but don't let it get in the way of cooperation.
- weavie 13y ago
  Yes. I think this is one of the most important and yet misunderstood aspects of agile. You aren't throwing out the right terms, just re-prioritizing them.

lmm 13y ago

The problem is real but changing the word won't solve it - we'll just repeat the same cycle all over again.

thebenedict 13y ago
Seriously. I like the focus on practical productivity but was surprised by the conclusion. "Let's all change from saying agile to saying agility" feels like quibbling over semantics. (Fixed spelling, thanks)
- nardi 13y ago
  semantics* technically that was a syntax quibble though, so the joke doesn't work as well

jayeola 13y ago

It's become another buzzword. Another phrase for people to throw at each other.

bananas 13y ago

I found that no methodology works as well as getting the right people in and let them organise themselves. If you have the wrong people, it doesn't matter what methodology or process you bring in, you're screwed. On that basis, methodology isn't that relevant. I just watched a company apply SCRUM to apparently solve process problems and it just made things worse because the staff aren't disciplined or interested in what they do. That's after five years of agile consultants and perpetual change. If you want a manifesto with real values: 1. Fix shit when it goes wrong right away. 2. Tell people what you are doing. 3. Write everything down somewhere centrally that everyone can get to(tickets) 4. Have a rough vision and make sure people are working towards it. Don't plan the details too much. 5. Be opinionated. Someone's got to win an argument. that's it.

jpkeisala 13y ago
Well said.
mpweiher 13y ago
"getting the right people in and let them organize themselves" That's a large part of what agility was/is about. The rest also matches up pretty well.
- bananas 13y ago
  Actually I disagree. The large part (possibly not the intent) was about building a consulting empire around something utterly vague with multiple religious opinions about the best way to perform these manifesto actions. A vehicle for rats.
  - mattmanser 13y ago
    In much nicer terms as he worked with them, that's the gist of what the article is about. Did you read it?
    - bananas 13y ago

Ingon 13y ago

Yeah Agile is used as a way to make money now days. For what other reason there are Agile consultants, Agile agencies and Agile certification. I firmly believe that Agile is about doing what makes sense in this team right now. You let the team to decide on their process, on their way of work and get away. And for good managers this is enough - you are empowering your team to succeed. Recently I had a great success demolishing standups in our team. We clearly weren't getting enough value from them (I though they were plainly hurting us), so it was time for change. I had a great resistance from the management team, but some developers were keen to try a change (some of them were long enough in the industry to remember the pre-agile days, when we were delivering software too). So we tried it for some time, everybody loved it, and we stopped doing it completely. Now days we all agree that iterative development is the way forward. We should also think if we can apply the same on a meta level - the team, the process, the product, the design, the organization. Do small steps, check if you are going into the right direction, repeat. It may work :)

hox 13y ago
What was it about your standups that were hurting your team? I'm on the fence with daily standup meetings. they definitely can help a team communicate when there are a large number of external forces at play in a larger organization and if there are no underlying asynchronous communication channels available. on the other hand, in a team that communicates regularly with historical communications available to new team members, they aren't as useful.
- Ingon 13y ago
  Among the negatives of standups are: - Rarely the right information. Every person in the team have different needs for information. It is even harder to deliver the right amount and on the right level if your team includes designers, quality engineers, project/product managers. - Rarely at the right time. If your company culture includes flexible hours, no matter at what time you put the standup somebody will suffer. Most of the time the team members who come early suffer - they already started work, now you are forcing them to get out of context and attend a meeting. - Sometimes standups are used as a way to force some team members to do what they have promised (the what I'll do today). But if you are using them in this way is really counterproductive - you either trust that your peers are doing their best for the team or you might consider team change (which I understand is beyond our control sometimes). - Failure to communicate (or "the what problems I have/had" part). If your team members are mature enough and they had a problem during the course of the day, they shouldn't wait for the next day's standup to let everybody know about that. The should be proactive and seek resolution as the problem comes up. - Finally the "what I did yesterday" part. This information is commonly used by the managers, but there are better ways to deliver it. Most of us use some way of tracking our work. We only need to flow this information to our managers. It is also a mind shift for them - instead somebody pushing this information to them, they should be proactive and seek it and pull it. If you don't know what somebody is working on, then go and ask him. You don't need to loose the time of the whole team for this. That being said whether you will use standups or not depends largely on your team dynamics. In new teams or teams formed largely by junior developers it makes sense to have standups - its a way to force communication patterns and certainly can be used as a casual form of a team building. But in my opinion as the team matures there is less and less need for standups, so at one point it just becomes a hurdle. And the good thing about being agile (not SCRUM) is that you can evaluate your process and change it as you (and your team) see it fit.

teamfuture17 13y ago

You're right that good ideas like eco and also agile follow that growth curve. After a while the original idea and intention is partly lost on the way to economy and marketing. I observed that in the organic movement around 2000 as well. It is never totally lost, the impulse improved reality, but we need new ideas, new movements to hold spirit, values and ideas high. I don't know what you think about our impulse wholeheartedmanifesto.org which we started this February. Let's focus on the doing and on being authentic.. that's what counts. Thanks for your blog. Christine

planetjones 13y ago

Well said. A friend of mine is another company are supposedly moving to "Agile". Their approach is to have whole day meetings to discuss how it will work! Three months later they're still planning how their Agile, Scrum based thing will work. The conferences, the consultancies, the big companies, etc. really have destroyed the essence of the Agile manifesto in many ways.

mcv 13y ago
It's not that they've destroyed the essence of the manifesto, it's that the organization is simply inherently not agile, and incapable of dealing with agility. This is pretty common for large organizations (thought there are also a lot where it kind of works). Their real problem isn't so much the introduction of Scrum, it's changing the very nature and culture of their organization. They should focus on that first, and then Scrum will follow naturally.
a_c_s 13y ago
That's why I like to make the distinction between little-a agile (the non-dogmatic vision of the original manifesto) and big-A Agile (rigid, sold as a product methodologies backed by expensive certifications).
steveklabnik 13y ago
I once worked at a company that was in their third year of transitioning to Agile.

neverminder 13y ago

I never really understood this whole rage about agile and some people preaching it like a religion. You can't fit everyone in one frame, people are different. As the matter of fact the better the engineer the more quirks he will have. Some people like to jog, some like to sprint and rest, but if they cover the same distance and reach the finish in the same time, who cares what methodology they use? Even though I probably use quite a few agile ideas I don't call it agile or anything else, I call it development.

mironathetin 13y ago
Good comment, neverminder! I always understood agile development as a way to organize your team and yourself in a way that works best for everyone. So don't follow a scheme, even if it's called agile, but think yourself. Probably this is, how I WANT to understand it, because I don't like to follow rules that make me unproductive, even if others may become more productive by following the same rules. Who does?
obitoo 13y ago
Excellent running analogy, i'm going to remember that!

usea 13y ago

The agile principles are fairly solid, as far as principles go. They're people-first and they downplay process and planning. You can't blindly follow a plan, process, or ideal. Think. Communicate. The right thing to do changes in every situation. You can't follow dogma. But the idea that we should switch to a new word because the old one has been abused makes no sense. Why rally behind a word? Brands and labels only serve to stop people from thinking. They go against the whole idea. Words become dogma. Hell, even principles become dogma. Trying to distill it down to something that's easy to digest robs it of its value. The solution isn't a better dogma. It's people who can think. If you don't have the right people, no principle will save you.

Spearchucker 13y ago
You can't blindly follow a plan, process, or ideal You can. The question that you might ask is whether the plan is good or not. You can't follow dogma As above. Dogma actually has its uses. The trick is knowing how, where and when to use it, or someone who is dogmatic. Machiavellian, but its a tool nonetheless. Saying we don't need a plan is to thumb our nose at thousands of years of wisdom. Sun Tzu was not stupid when he suggested choosing a path only once the objective and environment are understood. Stephen Covey puts the same concept into modern terms when he suggests beginning with the end in mind. And that brings us to the disconnect we live in. Developing something using agile practices does not require a plan. A plan is however required at a level above the developer to steer development. As you go, you'll find yourself becoming interested in that plan more and more. It's a natural shift because the plan reflects the strategy, development is purely tactical. Understanding the strategy is motivational - it answers the why. Development is all about the how. Real value as a developer only comes from experience. An experienced developer is successful in spite of any methodology, approach or framework, not because of it. Something else we're really good at blinding ourselves to. Experience has no price. It amuses me to no end that we as an industry place higher value on the 20-something hacker than we do on the 50-something veteran. We're unintentionally letting culture hobble our chances of success.
- usea 13y ago
  You are right on all counts. I should be more considerate with my thoughts and words. I appreciate your nuance. Thank you. I would not eschew a plan, but I would alter or abandon it when it's favorable to do so. I meant only to advocate pragmatism, not anarchy.

alphadevx 13y ago

I once attended a meeting where a manager said "We won't be doing agile, but we will work with more agility", which basically translated to we won't be changing our existing process. Agile to me is real: it has not been diluted as I know exactly how I will implement an agile process (scrum in my instance). I don't care if others misuse or misunderstand the term. For me it's concrete.

mcv 13y ago
> "We won't be doing agile, but we will work with more agility" At a previous client, I was sitting next to a really nice poster that emphasized the difference between "doing agile" and "being agile". You don't "do" agile. That's simply not a thing. You have to be agile. Working with more agility is totally fine. But if you do that, it means you won't be sticking blindly to your existing process, it means you should consider what you actually need from that process.

mcv 13y ago

I understand what he says, but from a grammar perspective, he's wrong. He complains that Agile, which started out as an adjective, has been turned into a noun. He wants it to be an adverb instead, so he introduces agility, which already is a noun. And then he says it's not a noun. (I'm sorry, but I just couldn't not point that out.) But other than that, I agree. What should be making our work easier has been turned into something complex by itself. Though in a sense, maybe that's unavoidable. Not everybody truly groks agility, so they have to be taught, which means training and certification. Although personally I think if you don't innately understand it, you can't learn it in a workshop either. Maybe you need to discover it through experience, and I know people who never will. So where does that leave us? Only the people who grok agility should work this way, and those who don't should stick to something else? What about the companies who want the hip new buzzword, but also want to have some handle on the process they're using? An agile process like Scrum definitely fills a need, but I've also learned that Scrum in one place can be totally different from Scrum in another place. Nobody completely follows all the ideas of Scrum, but maybe that's as it should be: adapt what you do to what you need. And there may be a limit to the amount of agility some companies can deal with.

NAFV_P 13y ago
> I understand what he says, but from a grammar perspective, he's wrong. He complains that Agile, which started out as an adjective, has been turned into a noun. He wants it to be an adverb instead, so he introduces agility, which already is a noun. And then he says it's not a noun. (I'm sorry, but I just couldn't not point that out.) Your knowledge of English programming is excellent, it is a rare and underrated skill. I can only recall one article on English coding posted on HN [0]. BTW love the double negative at the end. [0] http://antirez.com/news/61 http://antirez.com/news/61
vorg 13y ago
> He complains that Agile, which started out as an adjective, has been turned into a noun. The only programming languages I know of that use adjectives for their names are "Basic" and "Groovy". So this suggests when adjectives are used as nouns is a strong indicator of consultants flogging faulty processes and products for both development methodologies and programming languages alike.

malaporte 13y ago

Funny how this post made me realize I've often been confronted with people wanting to implement 'agile' by imposing us to follow strict processes. I'd never seen it that way, even if the irony is pretty obvious.

burkestar 13y ago

Disagree. Language is not an immutable thing and is always evolving in its use to reflect the concepts of the people using it. I think capitalizing Agile as a noun makes it a "thing" that we can refer to collectively and ultimately helps us communicate about the concepts that it entails. The unfortunate down-side is when a popular term is misused due to ignorance and misunderstanding by a large group of people - which will happen more prevalently as a word becomes popular. As someone who has had the pleasure of receiving Scrum coaching from Jeff Sutherland, I can say that there is a HUGE difference in understanding between people who spend time to learn it (from a book or coach) and those who muddle their way through - never taking the time to learn about it more deeply and put it to practical use (the only way to truly learn is through doing). I work at a small company and teach an internal course on the principles of Scrum to our project managers, so I have first-hand exposure here. It's amazing how really smart people who have heard the terms used for several years and even claim to have been involved in Scrum teams at past jobs still have many misconceptions about the core principles and how to practically apply them when the situation arises. There is definitely a shallow understanding amongst a good majority of developers and it's exacerbated by companies that claim to use "Agile" practices yet have only really scratched the surface. It's immediately clear that many have used "Scrum-but" and really only do standup meetings as if that will be all that is needed. Actually many people think Scrum is "that process where you hold standup meetings". I like Scrum because it brings together not only a way to manage a project, but more importantly a way to lead a team of people! I think being a servant leader to the team and providing them the necessary resources to be at their peak effectiveness is a trait of a good leader. It's actually kind of amazing all the different ways even very smart people can get "stuck" - distracted by a less important task that is shiny and interesting, slog through hours of debugging to resolve an issue that someone else on the team could have helped them with, not communicating with other team members that they can't get their part done unless another has provided them something first. From experience, just helping people identify these blockers and get the team unstuck has been a big win. I think tools absolutely are a big help too. I've used sticky notes on whiteboards and it's good for small teams that are co-located. It breaks down for distributed teams. We just started using JIRA and it is surprisingly good at helping us managing all of our work which would grow unwieldy using more primitive methods. I'm not sure how I feel about the agile manifesto. I guess it has its historic place as a reaction against the poor waterfall practices of the past and paved the way for new methods to emerge. Besides that, it seems a bit dated and hasn't served a useful practical purpose for me.

willvarfar 13y ago

Here's my favourite post about Agile: http://pindancing.blogspot.com.au/2009/09/let-agile-fad-flow-by.html http://pindancing.blogspot.com.au/2009/09/let-agile-fad-flow... Very worth reading entirely.

McUsr 13y ago
I liked most of the generalizations in the blog post,I think that if he isn't 100% right, then at least he is really on to something. The place I balked, is where he said that design patterns are almost dead. I find design pattersn to be invaluable, and so does at Apple Computer and with them millions of developers, so the death of design patterns is a bit premature.
astrange 13y ago
Although it's a little off topic, I'm fascinated by how much time 2000s bloggers spent namedropping all the other bloggers (see paragraph 2). When someone mentions your name all the time, they're trying to sell you something, but what did it mean to mention other people's names all the time? If they're selling the message that they're Spolsky's close personal friend, it's hardly working. I guess it lets you steal their page views if you summarize their post…

davidgerard 13y ago

tl;dr you still can't Taylorise clue, but that'll never stop the Mgt. trying.

beat 13y ago
I think that's the quote of the day. :)

benjaminwootton 13y ago

The author is quite defensive about the commercialisation around agile. I don't think this is warranted. I'm a developer, but I have described myself as an agile consultant in the past. This isn't out of cynically spotting an opportunity to make a buck. Its because I've spent a lot of time working in agile environments, learning the pitfalls and how to do it well, and want to share what I really and genuinely think is a better way to deliver software. When vendors and consultants start to coallesce around an idea, it usually means that the idea is a good one that is gaining traction, coming down from the ivory tower. It's a positive thing and not something to leave the community that you founded over. I've heard this argument many times over the years, and it always sticks in the throat a little. I'm evangelising an idea that I passionately believe in but am seen to be selling out the community ideals somehow. I walk the same line on my current venture in the DevOps space.

SiVal 13y ago
All of this is quite predictable if you just ask yourself what kind of people refer to their personal opinion papers as "manifestos".
- ternaryoperator 13y ago
  I understand your point, but in context it's a bit unfair. The manifesto was issued in 2001, when waterfall was still the default methodology at most businesses. They were indeed trying to break out of that mindset and felt they were doing something revolutionary (which, in fact they were).
  - RogerL 13y ago
    I worked on big government projects using military standards that more or less imposed the dreaded 'waterfall'. What was our mantra? "Design a little, code a little, test a little". Agile re-invented or popularized various ideas that had been around for a long time. As always, you adjust for the problem at hand. Royce, the so-called inventor of waterfall (he presented it as an obviously flawed concept, a straw man), argued for copious documentation. Documentation makes a lot of sense when trying to built a jet-liner, and is often a time and money sink if you are trying to write, say, research code for computer vision. So, "revolutionary"? I dunno? Certainly many places had taken the deliberately flawed Royce model as the way to do things, and so there was a big change as far as that goes. But I can't recall a time where some form of iterative/evolutionary development method was not known about and practiced, or where decision making was favored over process. To make this clearer - the Royce-ers patted themselves on the back, and then got hopelessly entangled with process. Yourdon came along. Wow, was that a great process - which everyone got entangled with. Then there was Booch..... And now, we have Agile. The details vary, to be sure, but the fundamentals remain the same. Some good ideas for approaching engineering a solution gets turned into conferences, endless books and training, independent consultants, certifications, requirements to be certified to win contracts, and on and on. I'm old.

jrochkind1 13y ago

Yes. Thanks for writing this Dave Thomas.

jrochkind1 13y ago

> anyone who comes up with something bigger or more complex is just trying to sell you something. I don't think being misled by snake oil salesmen is the only, or even the primary reason people get misdirected away from true agility toward 'agile'. There are intrinsic motivations and interests in most human organizations which lead against actual agility. A few of these include: * The need for people in many positions to feel and be able to represent themselves as in control of the process and product; * the desire to have someone else to blame when something goes wrong; * the interest in shortcuts and magic bullets, instead of realizing how much work and time things will actually take (including from non-technical stakeholders). There are social/organizational reasons that make true agility hard, especially in large organizations, especially in organizations where software dev/IT is just one component of a larger mission. But that doesn't change that actual agility is the only way to produce high-quality software efficiently. And we probably do need people investigating and suggesting how we overcome these barriers; but indeed, the 'agile' industry has not succeeded in doing so, they mostly take the easier path of figuring out how to cater to these barriers while calling it 'agile', instead of how to change organizational culture and surmount them.

caboteria 13y ago

Be wary of any methodology whose name begins with an upper-case letter.

projectileboy 13y ago

Dave didn't seem to mind cashing the checks he got for all the "agile" books his company published. This piece would have been interesting in, say, 2008, but now he's just riding the wave.

lucisferre 13y ago
From what I can see none of his own books are actually about "Agile". In fact "Agile development with Rails" is probably the only one that used that word in the title, and I can't really fault him for taking advantage. Also he wrote some quite good books, 'Pragmatic Thinking and Learning' come to mind. I don't think your comment is particularly fair, nor does it diminish the point he is making in any way even if you're right.
- projectileboy 13y ago
  His words: "Once the Manifesto became popular, the word agile became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, co-opted to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand." From his company's website: http://pragprog.com/categories/practices http://pragprog.com/categories/practices I think the callout is appropriate.
  - lucisferre 13y ago
    No not really. None of those are books he wrote himself. He runs a book publishing company. It's primary purpose is to publish books people want to buy. Though I'll agree that many of those authors capitalize on the exact things he is railing against in his post.
- robin2 13y ago
  "Pragmatic Thinking and Learning" was Andy Hunt, but as he and Dave Thomas are kind of a double act I can see why you'd get mixed up. As to your point about whether they wrote any books on 'agile' I think it could be argued either way. More specifically, whether or not "The Pragmatic Programmer" (the book they made their name with) counts as a book about 'agile' is an interesting question, and one that throws some light on the wider debate. Although they sometimes talk about "pragmatic programming" as if it were a thing, in the same way as XP and Scrum, their approach was more one of giving a smorgasbord of potentially useful techniques and practices rather than codifying a tightly defined set of best practices.

rvinay88 13y ago

I like the comments section in this article. The industry really isn't as bad as the writer thinks. Also the other comment that the word is bastardized but the values live on is so true. Changing the name to agility is only going to make everyone follow suit and convert that into a marketing buzzword.

NAFV_P 13y ago

> Of course, this involves a fair amount of thinking, and the basic loop is nested fractally inside itself many times as you focus on everything from variable naming to long-term delivery, but anyone who comes up with something bigger or more complex is just trying to sell you something. Basically, the process is recursive, but my explanation is more agile.

beat 13y ago

And today, I read this oldie-but-goodie over at Martin Fowler's blog... http://martinfowler.com/bliki/SoftwareDevelopmentAttitude.html http://martinfowler.com/bliki/SoftwareDevelopmentAttitude.ht... In Fowler's terms, the intent of the original Agile Manifesto was EnablingAttitude, but the result of the term "Agile" in many environments has been DirectingAttitude. It's a nasty cognitive dissonance - that "Agile" has in many places become a heavy, clumsy, tool-driven process that gets in the way of developers rather than helping them work efficiently. And I'm not saying this in the "just let us hack" mindset either, because I pretty much despise that sloppy, careless mentality. It doesn't work in environments larger than a few people, much less genuinely large projects. But process needs to be scaled to team size, talent, and risk tolerance. A broad-strokes "Agile" process that restricts competent teams is worse than useless.

michaelochurch 13y ago
And I'm not saying this in the "just let us hack" mindset either, because I pretty much despise that sloppy, careless mentality. It doesn't work in environments larger than a few people, much less genuinely large projects. There's a surprising low upper limit on the size of a closed-source codebase before which it becomes a lead weight. Why? Because large projects (beyond about 6 devs in 2 years) without modularity generate a lot of maintenance work. (Modular design is to pay that maintenance cost upfront, which most executives don't like.) Maintenance needs to be done well, but the only thing that motivates good people to do it (instead of hopping to another team, changing jobs, or demanding a $500k+ salary) is either (a) caring about the module as a client, which means they typically aren't more than 25%-time maintainers because their main project is whatever uses the module, or (b) the possibility of gaining a national reputation in OSS. The open-source ecosystem can motivate the kind of work that large codebases need. (That doesn't mean they never turn to crap. It means that it's not inexorable.) Corporate codebases don't have that. Twitter hasn't open-sourced, for one example, Storm because they're nice guys (not to rag on them; this is one of a million examples I could use). That may be a factor, but the main reason is that they don't want it to turn to crap, and the open-source ecosystem is more robust against that than anything in the closed-source world. If you rely on something but it's not extremely proprietary, you should probably open source it for its own health. Proprietary stuff should probably be kept as data, not code.

michaelochurch 13y ago

So much of "Agile" is an attempt to "patch" the top-down, closed-allocation organization that is simply incapable of hitting technical high notes no matter how much it spends or how many people it hires. Since organizations are tough to change and all dysfunctions have champions (some deeply hidden) the "Agile" ends up having to make smaller and smaller motions while its desire for control, as the velocity in an irrotational vortex, gets stronger. Then it devolves into micromanagement, as discussed here: http://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging http://www.mountaingoatsoftware.com/blog/ssssh....agile-is-a... The reality is that the future just has no use for closed-allocation tech companies. Every tech company needs to decide either to play for real and try to excel (open allocation, highly selective hiring) or GTFO and do something else. Scrum is a formational hack, but closed allocation is a foundational problem and, if technical excellence is needed, a show-stopper.

Nursie 13y ago
I mostly agree, apart from the no future part. There are plenty of companies putting out bad software, slowly but profitably. They occupy various niches where the people doing the selective hiring or being hired selectively just aren't interested in playing. Sure, they could be out-competed by an agile, well-staffed, disruptive new competitor. They could be, but they probably won't be.

beat 13y ago

Meanwhile, I'm watching helplessly from the sidelines as "DevOps" becomes the next "Agile", tasting bile in my mouth and wondering when a brilliant concept for reworking the culture-clash problem between developers and operations got reduced to a "knows how to use Chef/Puppet" for recruiters.

deleted 13y ago
[deleted]

FeloniousHam 13y ago

Agree generally with the article, my particular views on Agile: 1. Communication, communication, communication 2. Short iterations 3. Concrete deliverables 4. Client/customer engagement with deliverables Everything else is details.

xsace 13y ago

There is some truth in this post. However I still thank the Agile "industry and business" as it allowed me to open my eyes as a developer years ago. Because believe it or not, some of the so called master/consultant are genuinely caring about the values behind the manifesto, and putting a lot of efforts into improving everyone practice of software development.

0xdeadbeefbabe 13y ago

Since, agile is dead it's time for the Knights Radiant approach to software: Life before death, strength before weakness, journey before destination.

rip747 13y ago

is it me or when an article is titled: "[something] is dead, long live [something]", you immediately want to flag it out of existence? seriously, comes up with a better title.