11 ms·

Coconut Headphones: Why Agile Has Failed

180 points by jackhammer2022 13y ago

jayvanguard 13y ago
Has it really failed? It seems like at least some of the principles of agile are just a given now. 10-15 years ago that wasn't the case. People actually believed in waterfall. Of course many individual teams fail at agile but those teams would probably fail no matter what approach they were using.
- wpietri 13y ago
  It's a good question. But personally, I think that people would have stopped believing in waterfall approaches anyhow. Anybody sticking with 18-month release cycles today would seem like an idiot whether or not anybody had heard of Agile. And really, what a lot of supposed Agile teams are doing is really mini-waterfall: all the ceremony, shorter cycles, but just as much horseshit and self-delusion.
  - collyw 13y ago
    I got taught waterfall at university. Nowhere did it specify 18 month release cycles, just iterations, and going "back up the waterfall" if need be (critics of waterfall never seem to acknowledge that you can go back the way). To be honest I don't see how it actually differs from agile that much. Just less emphasis on documents up front.
    - kasey_junk 13y ago
      As someone old enough to have been working with waterfall when it was considered the way to write code, this comment sums up for me why Agile has not failed, despite the idiotic cottage industry sprung up in it's name. That an emphasis on delivering software, on interactions instead of process, etc. seems normal and no different permeates the industry such that people see it as the status quo. I assure you, that is not how it used to be, and there is a huge difference other than less emphasis on documents.
    - zb 13y ago
      The process you're describing is the Spiral Model, not the Waterfall. The major innovation of the Spiral Model was that you acknowledged that you would need to iterate - in the Waterfall days that was considered something to be embarrassed about. The major innovation of Agile was that you acknowledged that the various steps of the Waterfall/Spiral happen at the same time - in the Spiral days, that was considered something to be embarrassed about. I don't doubt, by the way, that you were taught that the Spiral Model was called Waterfall. But you should be aware that this was a case of historical revisionism on the part of whomever taught you.
      - collyw 13y ago
        It was a while ago, but I remember spiral being taught with a big spiral diagram - looked kind of like a snail shell. And waterfall had arrows that could go back up the way if needed. I also remember being taught that errors caught after the software had been implemented was 100% more costly to fix than errors at the design stage - I think that was the idea behind big(ger) design up front. https://sites.google.com/site/ucscsadg12/system-domain https://sites.google.com/site/ucscsadg12/system-domain
        wpietri 13y ago
        That "errors are more costly later" notion is true for waterfall, but not for, say, Extreme Programming. It is basically true for waterfall because the feedback loops are broken. Think cooking, for example: if I cook all my meals for a year at once and put them in the freezer, I'll have to do a lot of research and planning. Otherwise, a single mistake could lead to me throwing out up to 1000 meals. But if I just cook every meal as I go, I can tinker quite a bit, because the cost of failure is limited to one meal. Which is no problem; if I really screw up, I just pull the frozen pizza out of the fridge. Extreme Programming in particular can be looked at as a set of methods to flatten the cost of change curve. Then if you add the Lean Startup approach on top of that, you end up testing your core hypotheses early on, so even major shifts in business direction end up being pretty inexpensive.
- EdwardDiego 13y ago
  > Has it really failed? It works fine for us, but we have the ideal conditions for it to - business product owners who understand that their role is to provide a prioritised backlog and clarify stories in a timely manner - and nothing else. We have an organisation that accepts that the developers will drop features from a sprint to safeguard reliability and quality. We have teams that have stable core domains so that our estimations are, for the great majority, sufficiently accurate within that core domain. Every time I see a "Agile is a scam / it's dead Jim / it's a myth" post, it usually involves into someone doing something dysfunctional and then trying to justify it with "But Agile!" in a game of Buzzword Bingo. I went to help a local government IT department that was trying to implement Scrum to get some clarity on what the hell was going on in their dev teams, and I sat in on sprint retrospectives where all the talking was done by the 'product owner' - who was actually a rebranded business analyst who had no authority to prioritise backlogs. He wouldn't stop talking either, even when I explained to him that the retro was for the team, not him. To that team, Scrum was a bunch of bullshit. To me, how they were doing it was obviously flawed. That said though, ultimately, that organisation has derived value from their half-assed implementation of it. It's shown them precisely who contributes in their IT team and who is cruising. They've got a few people who claim a monopoly on certain areas and jealously defend them because it makes them feel necessary and as such, safe from being laid off. Hence I had a GIS guy telling me that "You can't expect .NET developers to learn GIS!!" and an ABAP developer saying the exact same thing. Now that organisation faces the challenge of managing the coasters out - unlike the US of A we don't have at-will employment.
pinkpussycat 13y ago
Heh... Totally love the "We'll ask for estimates and treat them as deadlines" meme. I think that captures the essence of the article. The problem is usually caused by management - the technical team has to hold strong and push back on forces from above. Since the person above them is usually trying to cover their own rear-end, the tech team needs to learn how to give sounds bites to their manager. That manager takes the sound bite and replays it higher up. Win-win.
asdkl234890 13y ago
I worked for a large corporation which used a hard core water fall method to produce software. And yet it called it Agile. Why? Because why not.
- donretag 13y ago
  I worked in a similar environment. Sprint 1 is requirements gathering. Sprint 2 is coding. Sprint 3 is testing. Water fall really is agile!
- collyw 13y ago
  I have noticed this. Every one claims to be doing agile, even though they pick and choose the parts they decide are "agile". I just continue to write software the way I always have. Kind of disciplined version of cowboy coding I would say. Sometimes I have design documents - when I feel it helps. Other times the problem might be less clear, built a prototype, and iterate from there. It really depends on the problem you are trying to solve and the time frame you need to do it in. I get software working, usually in a decent time frame. Is that not what agile is supposed to be about?
eliasdelatorre 13y ago
I'm stuck trying to finish a project as a vendor. The original team in charge of selling the project has put a guy as Project Manager that takes pride everytime he says: "As you know, I'm not a technical guy" just before explaining something completely wrong from the technical standpoint, or agreeing into something that can't be delivered as explained. I can't agree more on the quote that says "Please don’t put non-technical managers in charge of software developers." I just hope finishing this without a lose, and getting a better position for the following projects.
- wpietri 13y ago
  I think the problem isn't with who you put in charge. I think the problem is the notion of "in charge". One of the best things for me about teams that were working well is that everybody was in charge. Everybody felt responsible for the outcome. Everybody cared. Everybody knew they could make things happen, and that differences of view were resolved through collaboration and experimentation, not power. You can see that explicitly in the structure of Extreme Programming, a major Agile process. There were developers and there was a product manager (called "customer"), and neither controlled the other. Indeed, people created an XP bill of rights that described the balance of powers: http://agile.dzone.com/articles/worth-repeating-xp-bills http://agile.dzone.com/articles/worth-repeating-xp-bills You can see that working in the large at places like Spotify, where teams are cross-functional. People do have managers, but they aren't on the same team, and technical people report to technical managers, not generic businesspeople. Those managers aren't "in charge" in the typical sense. They mentor and support the people working directly on teams. They only really manage when things go wrong. And I think that's what the Agile community was going for early on. It's a shame that fell by the wayside.
  - watwut 13y ago
    I had very bad experience with "everybody in charge". We oscillated between nobody makes decisions and war for power and decision making. The project was simultaneously pulled in multiple directions and there was no such thing as shared priorities. Every team member had his own. It got hell when the company hired very smart and capable guy who turned out to be very lazy. Nobody is in charge in that case means also that it takes too long time until someone in charge finds out about the situation.
datawander 13y ago
The demotivation poster (we'll ask for estimates, but then treat them as deadlines) really strikes a chord because that is one of my major 'gripes' with the agile planning process. Particularly when a manager is heavily involved in that process. It may be no coincidence that the best projects I have been on are the ones where the manager deliberately stepped out of the room or was not a part of those phases of the planning process. Agile is part of a more disturbing trend I've noticed [0] of companies striving very hard to turn software into a literal sausage-making factory [1] and to make software engineers just another cog in the machine or a replaceable part to fatten the bottom line with a lower salary. This is provably the aim of some of the top companies given news on no-hire agreements. [10]. [0] with Java being the favored "currency" of programming languages being the other disturbing trend-- it's much easier to replace a Java programmer than any other for a reason [1] you know what they say about how sausages are made [10] http://gizmodo.com/apple-guilty-of-price-fixing-730018979 http://gizmodo.com/apple-guilty-of-price-fixing-730018979
- wpietri 13y ago
  Yeah. 100% agreed. In some ways I don't blame people. Industrial approaches to organizing people provided a major leap forward for humankind. And they work well with primate power dynamics; modern corporate structures are basically feudalism in suits. It's natural that people would just want to take the top-down, command-and-control structures and replicate them in the new thing they're doing. But they just don't work well. They don't even work well for industry anymore; there's a reason that Toyota, which has a very different management philosophy, wiped the floor with the US auto companies, which stayed stuck in the early 20th century. To be fair, Agile started out to be 100% the opposite of that sausage-factory approach. I know a lot of the early players, and they sincerely had a very different vision. It makes me sad to see their work used as just another stick to beat developers. Meet the new boss, same as the old boss.
- jaggederest 13y ago
  I think the correct way to do it is to do the old 'pick two' method - quality, features, timeline, pick two. (I'd say you never want low quality but... situationally.)
- 13y ago
wpietri 13y ago
As somebody who has been involved in the Agile movement since before the term existed (I was using Extreme Programming in 2000 or 2001), I agree 100% with this. I definitely think the consultants get a good chunk of the blame. But as I explain in detail elsewhere [1], I think that happened because executives, the consultants' customers, were mainly interested in buying BS. Not consciously, but when they were offered a choice between hard Agile and easy Agile, they bought easy Agile. It's sad, because in the 2001-2005 timeframe, there were a lot of great people doing a lot of great stuff. There are still some doing great stuff today. But yeah, among most of the people I talk to that are "doing Agile" (as if there were such a thing), Agile is just putting new labels on the same old power dynamics. And it's those power dynamics that are the problem, and no matter what methods you supposedly adopt, unless you change those, the system will return to making powerful executives and managers feel safe and in control. At the expense of productivity, quality, value delivery, and a whole lot else. [1] http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
- sdrothrock 13y ago
  > But as I explain in detail elsewhere [1] > [1] http://mikehadlow.blogspot.co.uk/2014/03/coconut-headphones-why-agile-has-failed.html http://mikehadlow.blogspot.co.uk/2014/03/coconut-headphones-... Did you mean to link something else?
  - wpietri 13y ago
    Fixed. Thanks!
- amputect 13y ago
  > when they were offered a choice between hard Agile and easy Agile, they bought easy Agile. This touches on what I believe to be the real, underlying issue: you (as a company) can't manage yourself out of a hole you've managed yourself in to. If management is defective, it will taint any process no matter how well conceived, because the underlying problem is not that the process is flawed, but that the people enforcing it are. Edited to add: your (fixed) link is right on the money
bitwize 13y ago
Those who can, do. Those who can't, become methodology consultants. It's as true of agile as it was of six sigma...
MRSallee 13y ago
I'm only superficially familiar with Agile. I feel this piece isn't very specific -- specifically, what benefits of Agile are being missed and why? I like the Cargo Cult analogy, and the author paints a fairly clear picture of what misapplied Agile tends to look like. Just not clear on what it should look like.
crag 13y ago
No... agile has failed cause most of the "enterprise" apps written in the "agile way" (and many claim to be) are crap. This isn't the fault of the agile manifesto. It's the fault of consultants who used Agile as a buzzword. The same consultants who never understood agile or cared to; producing apps riddled with bugs. Agile was heading to the abyss the day it was co-opted into a marketing buzzword.
carsongross 13y ago
To the extent that I've seen development methodologies work, they appear to mostly fix organizational barriers that get in the way of The One Thing That Actually Works[1]: hire a small group of extremely talented developers and product designers and then let them work. [1] Assuming your codebase isn't already a monstrosity. If it is... well, then nothing works.
- brightsize 13y ago
  > hire a small group of extremely talented developers and product designers and then let them work. Spot on. Whenever I go into one of my own anti-"Agile" rants, among my main points is that formal organizational process is simply unnecessary with talented, motivated development teams. In my long experience across many start-ups (which tend to get the aforementioned sorts of teams), if you just put a bunch of really smart people (devs) in a room with a project to do, Good Things happen. They know what needs to be done. They know how to do it. Any kind of formal development methodology just gets in the way. Management in those environments (and I've done that) is about care and feeding and listening and gaining consensus. It's not about religion or process. When I first read the Manifesto, not long after it came out, my reaction was YES! But in no time the Formal Methodologists came out of the woodwork and hijacked the whole thing, turning an attractive philosophy into just another management fad, one with nearly as much religious orthodoxy as what it replaced. Agile, with a capital "A", can't die quickly enough.
- joshyeager 13y ago
  How big is a "small group", in your opinion?
  - carsongross 13y ago
    10 or fewer people.
adorton 13y ago
A "people manager" should never be put in charge of project or schedule management. It creates a conflict of interest between the realities of the project, and the outside pressure the manager may receive from other teams. That's why, at least with Scrum, the agile manager, if he or she is part of the same team, reports to the same manager as the development team. The agile manager's job is to keep the agile process running smoothly, removing impediments, etc.
allochthon 13y ago
> Because creating good software is so much about technical decisions and so little about management process, I believe that there is very little place for non-technical managers in any software development organisation. Well said.
- nnq 13y ago
  Yep. Good software companies tend to get this. But the zillions on creative digital-media agencies that popped up recently, and realized that yes, what they are doing is software development and nothing else, and that their "creative secret sauce" only contributes 10% max to the business fail to get his big time!
deleted 13y ago
[deleted]
hpaavola 13y ago
All these late "agile has failed" posts are out of touch with reality. They assume that it is always possible to get the best developers and best managers to work with the problem on hand. I'm a consultant. Officially my title is Senior Test Engineer and usually my job is to go to a company where shit has already hit the fan or will hit in a short time. The reality is that the company has a bunch of developers who are mediocre at best (and maybe one or two good ones) and managers who do not understand the situation. And of course the budget is already been eaten. They want to ship their product and make some money with that so they can continue to live their life. If I go there and say hey, you need better developers, more rapid prototyping and managers who are technical enough, nothing will change. Nothing will change because there aren't "rock star" developers avaialble, there isn't time to find new managers and definetly no motivation to change everything right now. Sure in some sense I might be correct to say so, but my goal is not to show my superiority, but to improve the situation. But if I teach them a little Scrum, help them setup some CI and so on, they almost always perform better. And then this statement "Because creating good software is so much about technical decisions and so little about management process, I believe that there is very little place for non-technical managers in any software development organisation." No. Good software comes from understanding the needs of your customers and meetings those needs. Shitty developers have and will create awesome products just because they know what the users want and need. "Agile" helps even the shitties companies to meet the needs of their customers.
- briantakita 13y ago
  Agile is the new RUP. The main audience is shifting toward the shitties. It's the circle of life for cultural movements. Nothing wrong with Agile. It's just not my thing anymore.
  - hpaavola 13y ago
    By definition most companies, most teams and most individuals are average. There are very few really good developers and managers. What suits those few does not really matter. They will do great things not matter what. Agile works for most better than the alternatives.
briantakita 13y ago
IMO, the worst meeting you can have is the "agile inception". Do not allow a consultant who has no skin in the game to lead an inception. Do not allow them to have a louder voice than the engineers in the project. They can set a tone which is not coherent with the engineering team, which is bad, bad, bad. I've been involved with a few inception meetings. Two of them had terrible consequences for the life of the project. I got into a disagreement with a high level company executive in one and an "inception master" consultant in the other. They had no accountability for their "guidance" and they nearly killed the projects from the start.
oinksoft 13y ago
I had a comment I made into a post: http://www.oinksoft.com/blog/view/7/ http://www.oinksoft.com/blog/view/7/
abalone 13y ago
He just vaguely blames everything on "non-technical management" without really offering a cogent argument why. When he does get to concrete points, one of them is "Short feedback loops to measurable outcomes create good software." And yet "two week iterations" he calls "agile nonsense". The overal tone is kind of "technical macho" to me.. like, Real Developers don't need management and if you slipped then it's because your programmers suck and you should just hire better ones.
- briantakita 13y ago
  Non-technical agile management usually gets in the way. They get in the way with rigid prioritization. Prioritization means less gets done because you are optimizing sequential outcomes instead of a solid development process. Good engineers will evolve the architecture toward where the product is heading. Non-technical agile management uses points to measure the work that gets done because they don't know any better and they "need" to measure something. The technical architecture starts to go downhill over this never ending treadmill of the prioritized backlog with the non-technical task masters whipping their developers to get more points done. Sure, we can educate the non-technical management over keeping a low standard deviation of points. We can bargain to get technical cleanup time (marked as chores). We may even have a debt cleanup week out of the month. However, the spirit of the engineering endeavor is lost to the marketers, or their henchmen, running the project. It's too bad because subpar products and subpar code are the result.
- SixSigma 13y ago
  It would also suggest that someone who isn't a qualified doctor couldn't run a hospital. I continually run up against this attitude that programmers are somehow special and the rules of management somehow don't work with them. The sentence should read "The core problem is that bad managers will usually fail, or at best be counter productive, whatever the methodology".
keeptrying 13y ago
Has anyone actually seen a product manager cut features to make product better and to make sure the product gets shipped asap? Well now you know why agile was just iterated waterfall in most organisations...
alien3d 13y ago
I don't believe in agile. Agile come from inexperience project manager who tough programmer is cheap .The most problem this type of manager is,wanted to prove,if not from him company will gain zero income and income come from his negotiation and paperwork . Security,quality code all is abandon.It's about if the customer love it do it by hook or crook and wanted 110% quality .. In the end,customer is tired because changing of idea and implementation delay because didn't take counter measurement analysis on each request agile and time. both loose.
wavefunction 13y ago
Scrum Agile works great. Keep it light and loose and watch the code fly. I don't know much about the other flavors or taking it too far into process but I've seen the amazing things Agile as a philosophy can do.
- mcv 13y ago
  Different teams handle Scrum in totally different ways. On my previous project, it actually felt quick and light and agile. From one sprint to the next, we could switch to an entirely different sub-project, planning poker was quick, we never got around to backlog grooming, but somehow that wasn't a problem. We got lots of stuff done. My current project feels more sluggish. Long planning meetings where just one or two people decide on the story points. Somehow we never really get all our stories done in our sprints. This isn't a big problem, but it makes you wonder how we plan this, and why we plan this. The main differences I can tell between the two: this project we have a lot more documentation. All on wiki, but on the previous project, be barely had anything, and just asked people what the idea was and then did it. But my current project is at a bank, so it makes sense they want more planning and documentation, and less just figuring it out as we go. At another job, our Scrum wasn't really Scrum. We had standups, but that was it. No sprints, no poker, no scrum board, no burn down charts. But what this article makes me realize is that that project may actually have been more agile. Very few formal planning meetings, lots of informal communication and programmers just doing what they're good at and calling the shots.
  - EdwardDiego 13y ago
    > My current project feels more sluggish. Long planning meetings where just one or two people decide on the story points. Somehow we never really get all our stories done in our sprints. This isn't a big problem, but it makes you wonder how we plan this, and why we plan this. When you raise this at retros, what sort of response do you get? I believe you can measure the health of a Scrum team by a) what issues get raised in a retro and b) do they get addressed? The iterative aspect of Scrum is also very much about iteratively improving process.
    - 13y ago
Toenex 13y ago
This comment on the OP site pretty much sums up a lot of these kinds of posts: Learn about all good and important methodologies, and take what fits your character and team. Any religious treatment of any method is not natural.
programminggeek 13y ago
This recent meme about agile is so dumb that I feel like I shouldn't say anything at all, but here goes anyway. I'll keep this as short as possible... Agile works fine for teams that embrace it. It's going to work totally different from team to team. The real point is to find the process that works best for your team to deliver software that meets the customer requirements and budget. Agile for a team of 1 or 3 is not the same as agile for a team of 10 or 100. Agile tends to fail in two places and they are both communication related. First, developers give terrible estimates because of pride. They don't think through the problem, they don't consider complexity, and they want to look awesome so they ALWAYS over promise and under deliver. That makes them look bad and destroys confidence in the project because it's dishonest. Second, managers will take estimates and turn them into deadlines because that is kind of their job and they are doing the best they can with the bad information that developers give them (see bad estimates above). A good PM needs to really push their team for real esteems. Poor estimates lead to poor communication because when things go badly, nobody wants to send up the signal flare for help or tell the boss that the project is not going to hit the deadline. This is often compounded when the client decides to firedrill a feature or bug fix mid sprint, and the manager doesn't push back and say that it is going to push everything else back. The best estimates are the ones that are the most honest, not the shortest. Between the bad estimates and the poor communication that comes out of it, there are plenty of times that "Agile" goes wrong, but it's not agile's fault. It's your fault. It's your team's fault. It doesn't work if you aren't willing to continuously tweak and reevaluate the process until it fits your situation. That means doing retrospectives and making improvements based on them. Continuous improvement makes agile work. A stagnant process is doomed to failure as requirements and resources change over time.
- romaniv 13y ago
  First, developers give terrible estimates because of pride. They don't think through the problem, they don't consider complexity, and they want to look awesome so they ALWAYS over promise and under deliver. This sounds like bullshit. More often than not, bad estimates are a result of built-in bias in the overall estimation system that gets blamed on the people. For example, I routinely see people underestimating larger tasks when the cost of splitting them is prohibitively high, while the cost of being late with a task is largely imaginary.
seivan 13y ago
Agile become this another layer of unecessary job creation for non-engineers
seivan 13y ago
The problem with agile was never engineering, it was non-engineerial management bs.
bowlofpetunias 13y ago
Once again, this is about mismanagement rather than Agile or software development. Besides the objections concerning throwing out the baby with the bathwater when it comes to Agile, I also object to the notion that non-technical managers cannot manage a software project. True, 90% of all non-technical managers do not have the knowledge necessary to manage software development, but very little of that actually includes hard technical knowledge. As a tech manager with 25+ years of development experience, most of my work involves management skills, not technical skills. The technical insight needed can be taught to any smart non-technical manager. Also, managing a software project is not about being "in charge" and micromanaging, but mostly about serving, protecting and coaching a team. People in the "no management" camp mistake management for hierarchy. Being the manager is a team role, just like being a back-end developer, and interaction designer etcetera. None of this is about Agile or management, it's about two sides, old school hierarchical "programmers-are-codemonkeys" management and tunnel vision "we-don't-need-no-stinking-suits" developers, trying very hard not to understand each other. And using Agile as a stick to beat each other with. If Agile is dead, it's because it's been brutally murdered by two factions unwilling to face their own shortcomings.
McP 13y ago
I found that in my team that agile worked brilliantly for us at first - we were working together to create features that customers loved. Then support queries came in for the features we developed previously. At first a couple of team members would split off and work on the existing features while the rest of us carried on working on the new hotness. As we increased the number of (quite diverse) features, the more diverse the support queries got. Now we're basically no longer a team, but a group of individuals working in different areas, who happen to be in the same stand-up each morning. I am actively looking to fix this problem. I'm sure this must have been discussed already but I can't find it! Any suggestions?
- joshyeager 13y ago
  We have a similar support load, but have been able to avoid that problem. I attribute this to two things: - We have a highly skilled support team that can handle pretty much everything except actually writing bug fixes - Every iteration we pull the whole team back to swarm on feature development together. They may get pulled into different historical features for support, but new development is always done as a team. Support is still very costly for us, because the distraction of working on old features slows down new development. To combat that we're putting a lot of effort into fixing the root causes of our support issues and training our support team to handle more and more technical problems.
- mhw 13y ago
  It depends what you mean when you say 'support queries' - I'm guessing it's more than just someone not understanding how a new feature works. Here are some possibilities for what you're experiencing: * 'support queries' are actually bug reports: you're getting something wrong with your automated testing that's letting bugs get out into released code. Ideally you should have acceptance tests that make sure the code is doing what it should before you release it. Check what your team's criteria for 'Done' is - are they cutting corners to get things out the door? * 'support queries' are actually missing functionality in new features: you're not getting all the requirements for the feature in the sprint where you implement it. You need to make sure the conversation with the product owner covers everything that the feature (user story) should do. * 'support queries' are actually new feature requests: they should go in to the backlog and be prioritised along with everything else. You shouldn't let people push work into a sprint that hasn't been prioritised by the product owner.
hibikir 13y ago
The issue is not really having a manager that is technical or not: I have met great managers that were not technical, and terrible ones that were technical. Success comes from trusting your people, having a clear goal the team believes in, and a team of the right size to accomplish said goal. Every successful team I've been a part of had all three. When even one is missing, there is much dysfunction. The agile rituals are there to try to make those things easier, but they are just a way in: If you meet the important principles, you do not need them. Just look at the Valve method: No management, no ritual, but a hiring process that attempts to just get the kind of people that focus on those principles like a laser.
mankypro 13y ago
...
MartinCron 13y ago
The article closes with this idea: @sbellware we should bury agile, mourn the dead, and get on with establishing something that is designed to be resistant to being so easily undermined https://twitter.com/sbellware/status/443397344436817920 https://twitter.com/sbellware/status/443397344436817920 Which makes me wonder, is it even possible to create a "thing" (idea, movement, methodology, system, whatever) that is resistant to being undermined? I don't think so. It seems like a natural cost to attaching a name to something. This is why I try not to talk about "Agile" these days, but rather just to try to discuss the specific principles that have proven valuable for me.
- wpietri 13y ago
  The one big mistake I think the Agile people made is not trademarking the term Agile and then enforcing some standards. There was discussion early on, but for some reason it never happened. For Agile it would have been hard, because Agile isn't a methodology on its own; it's an umbrella for a bunch. Enforcing standards doesn't make it proof against being undermined, but it does make it harder. There's still a tradeoff between being popular and being great that's hard to resolve. Especially since a popular, non-great thing is more likely to get lots of money and attention.
  - MartinCron 13y ago
    That's an interesting idea, but my first instinct is that the cynical developer response to "Agile(tm)" would be even more harsh than to just "Agile".
davidgerard 13y ago
tl;dr you still can't Taylorise clue, but that'll never stop the Mgt. from trying.

180 points by jackhammer2022 13y ago

Has it really failed? It seems like at least some of the principles of agile are just a given now. 10-15 years ago that wasn't the case. People actually believed in waterfall. Of course many individual teams fail at agile but those teams would probably fail no matter what approach they were using.

wpietri 13y ago
It's a good question. But personally, I think that people would have stopped believing in waterfall approaches anyhow. Anybody sticking with 18-month release cycles today would seem like an idiot whether or not anybody had heard of Agile. And really, what a lot of supposed Agile teams are doing is really mini-waterfall: all the ceremony, shorter cycles, but just as much horseshit and self-delusion.
- collyw 13y ago
  I got taught waterfall at university. Nowhere did it specify 18 month release cycles, just iterations, and going "back up the waterfall" if need be (critics of waterfall never seem to acknowledge that you can go back the way). To be honest I don't see how it actually differs from agile that much. Just less emphasis on documents up front.
  - kasey_junk 13y ago
    As someone old enough to have been working with waterfall when it was considered the way to write code, this comment sums up for me why Agile has not failed, despite the idiotic cottage industry sprung up in it's name. That an emphasis on delivering software, on interactions instead of process, etc. seems normal and no different permeates the industry such that people see it as the status quo. I assure you, that is not how it used to be, and there is a huge difference other than less emphasis on documents.
  - zb 13y ago
    The process you're describing is the Spiral Model, not the Waterfall. The major innovation of the Spiral Model was that you acknowledged that you would need to iterate - in the Waterfall days that was considered something to be embarrassed about. The major innovation of Agile was that you acknowledged that the various steps of the Waterfall/Spiral happen at the same time - in the Spiral days, that was considered something to be embarrassed about. I don't doubt, by the way, that you were taught that the Spiral Model was called Waterfall. But you should be aware that this was a case of historical revisionism on the part of whomever taught you.
    - collyw 13y ago
      It was a while ago, but I remember spiral being taught with a big spiral diagram - looked kind of like a snail shell. And waterfall had arrows that could go back up the way if needed. I also remember being taught that errors caught after the software had been implemented was 100% more costly to fix than errors at the design stage - I think that was the idea behind big(ger) design up front. https://sites.google.com/site/ucscsadg12/system-domain https://sites.google.com/site/ucscsadg12/system-domain
      - wpietri 13y ago
        That "errors are more costly later" notion is true for waterfall, but not for, say, Extreme Programming. It is basically true for waterfall because the feedback loops are broken. Think cooking, for example: if I cook all my meals for a year at once and put them in the freezer, I'll have to do a lot of research and planning. Otherwise, a single mistake could lead to me throwing out up to 1000 meals. But if I just cook every meal as I go, I can tinker quite a bit, because the cost of failure is limited to one meal. Which is no problem; if I really screw up, I just pull the frozen pizza out of the fridge. Extreme Programming in particular can be looked at as a set of methods to flatten the cost of change curve. Then if you add the Lean Startup approach on top of that, you end up testing your core hypotheses early on, so even major shifts in business direction end up being pretty inexpensive.
EdwardDiego 13y ago
> Has it really failed? It works fine for us, but we have the ideal conditions for it to - business product owners who understand that their role is to provide a prioritised backlog and clarify stories in a timely manner - and nothing else. We have an organisation that accepts that the developers will drop features from a sprint to safeguard reliability and quality. We have teams that have stable core domains so that our estimations are, for the great majority, sufficiently accurate within that core domain. Every time I see a "Agile is a scam / it's dead Jim / it's a myth" post, it usually involves into someone doing something dysfunctional and then trying to justify it with "But Agile!" in a game of Buzzword Bingo. I went to help a local government IT department that was trying to implement Scrum to get some clarity on what the hell was going on in their dev teams, and I sat in on sprint retrospectives where all the talking was done by the 'product owner' - who was actually a rebranded business analyst who had no authority to prioritise backlogs. He wouldn't stop talking either, even when I explained to him that the retro was for the team, not him. To that team, Scrum was a bunch of bullshit. To me, how they were doing it was obviously flawed. That said though, ultimately, that organisation has derived value from their half-assed implementation of it. It's shown them precisely who contributes in their IT team and who is cruising. They've got a few people who claim a monopoly on certain areas and jealously defend them because it makes them feel necessary and as such, safe from being laid off. Hence I had a GIS guy telling me that "You can't expect .NET developers to learn GIS!!" and an ABAP developer saying the exact same thing. Now that organisation faces the challenge of managing the coasters out - unlike the US of A we don't have at-will employment.

pinkpussycat 13y ago

Heh... Totally love the "We'll ask for estimates and treat them as deadlines" meme. I think that captures the essence of the article. The problem is usually caused by management - the technical team has to hold strong and push back on forces from above. Since the person above them is usually trying to cover their own rear-end, the tech team needs to learn how to give sounds bites to their manager. That manager takes the sound bite and replays it higher up. Win-win.

asdkl234890 13y ago

I worked for a large corporation which used a hard core water fall method to produce software. And yet it called it Agile. Why? Because why not.

donretag 13y ago
I worked in a similar environment. Sprint 1 is requirements gathering. Sprint 2 is coding. Sprint 3 is testing. Water fall really is agile!
collyw 13y ago
I have noticed this. Every one claims to be doing agile, even though they pick and choose the parts they decide are "agile". I just continue to write software the way I always have. Kind of disciplined version of cowboy coding I would say. Sometimes I have design documents - when I feel it helps. Other times the problem might be less clear, built a prototype, and iterate from there. It really depends on the problem you are trying to solve and the time frame you need to do it in. I get software working, usually in a decent time frame. Is that not what agile is supposed to be about?

eliasdelatorre 13y ago

I'm stuck trying to finish a project as a vendor. The original team in charge of selling the project has put a guy as Project Manager that takes pride everytime he says: "As you know, I'm not a technical guy" just before explaining something completely wrong from the technical standpoint, or agreeing into something that can't be delivered as explained. I can't agree more on the quote that says "Please don’t put non-technical managers in charge of software developers." I just hope finishing this without a lose, and getting a better position for the following projects.

wpietri 13y ago
I think the problem isn't with who you put in charge. I think the problem is the notion of "in charge". One of the best things for me about teams that were working well is that everybody was in charge. Everybody felt responsible for the outcome. Everybody cared. Everybody knew they could make things happen, and that differences of view were resolved through collaboration and experimentation, not power. You can see that explicitly in the structure of Extreme Programming, a major Agile process. There were developers and there was a product manager (called "customer"), and neither controlled the other. Indeed, people created an XP bill of rights that described the balance of powers: http://agile.dzone.com/articles/worth-repeating-xp-bills http://agile.dzone.com/articles/worth-repeating-xp-bills You can see that working in the large at places like Spotify, where teams are cross-functional. People do have managers, but they aren't on the same team, and technical people report to technical managers, not generic businesspeople. Those managers aren't "in charge" in the typical sense. They mentor and support the people working directly on teams. They only really manage when things go wrong. And I think that's what the Agile community was going for early on. It's a shame that fell by the wayside.
- watwut 13y ago
  I had very bad experience with "everybody in charge". We oscillated between nobody makes decisions and war for power and decision making. The project was simultaneously pulled in multiple directions and there was no such thing as shared priorities. Every team member had his own. It got hell when the company hired very smart and capable guy who turned out to be very lazy. Nobody is in charge in that case means also that it takes too long time until someone in charge finds out about the situation.

datawander 13y ago

The demotivation poster (we'll ask for estimates, but then treat them as deadlines) really strikes a chord because that is one of my major 'gripes' with the agile planning process. Particularly when a manager is heavily involved in that process. It may be no coincidence that the best projects I have been on are the ones where the manager deliberately stepped out of the room or was not a part of those phases of the planning process. Agile is part of a more disturbing trend I've noticed [0] of companies striving very hard to turn software into a literal sausage-making factory [1] and to make software engineers just another cog in the machine or a replaceable part to fatten the bottom line with a lower salary. This is provably the aim of some of the top companies given news on no-hire agreements. [10]. [0] with Java being the favored "currency" of programming languages being the other disturbing trend-- it's much easier to replace a Java programmer than any other for a reason [1] you know what they say about how sausages are made [10] http://gizmodo.com/apple-guilty-of-price-fixing-730018979 http://gizmodo.com/apple-guilty-of-price-fixing-730018979

wpietri 13y ago
Yeah. 100% agreed. In some ways I don't blame people. Industrial approaches to organizing people provided a major leap forward for humankind. And they work well with primate power dynamics; modern corporate structures are basically feudalism in suits. It's natural that people would just want to take the top-down, command-and-control structures and replicate them in the new thing they're doing. But they just don't work well. They don't even work well for industry anymore; there's a reason that Toyota, which has a very different management philosophy, wiped the floor with the US auto companies, which stayed stuck in the early 20th century. To be fair, Agile started out to be 100% the opposite of that sausage-factory approach. I know a lot of the early players, and they sincerely had a very different vision. It makes me sad to see their work used as just another stick to beat developers. Meet the new boss, same as the old boss.
jaggederest 13y ago
I think the correct way to do it is to do the old 'pick two' method - quality, features, timeline, pick two. (I'd say you never want low quality but... situationally.)
13y ago

wpietri 13y ago

As somebody who has been involved in the Agile movement since before the term existed (I was using Extreme Programming in 2000 or 2001), I agree 100% with this. I definitely think the consultants get a good chunk of the blame. But as I explain in detail elsewhere [1], I think that happened because executives, the consultants' customers, were mainly interested in buying BS. Not consciously, but when they were offered a choice between hard Agile and easy Agile, they bought easy Agile. It's sad, because in the 2001-2005 timeframe, there were a lot of great people doing a lot of great stuff. There are still some doing great stuff today. But yeah, among most of the people I talk to that are "doing Agile" (as if there were such a thing), Agile is just putting new labels on the same old power dynamics. And it's those power dynamics that are the problem, and no matter what methods you supposedly adopt, unless you change those, the system will return to making powerful executives and managers feel safe and in control. At the expense of productivity, quality, value delivery, and a whole lot else. [1] http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...

sdrothrock 13y ago
> But as I explain in detail elsewhere [1] > [1] http://mikehadlow.blogspot.co.uk/2014/03/coconut-headphones-why-agile-has-failed.html http://mikehadlow.blogspot.co.uk/2014/03/coconut-headphones-... Did you mean to link something else?
- wpietri 13y ago
  Fixed. Thanks!
amputect 13y ago
> when they were offered a choice between hard Agile and easy Agile, they bought easy Agile. This touches on what I believe to be the real, underlying issue: you (as a company) can't manage yourself out of a hole you've managed yourself in to. If management is defective, it will taint any process no matter how well conceived, because the underlying problem is not that the process is flawed, but that the people enforcing it are. Edited to add: your (fixed) link is right on the money

bitwize 13y ago

Those who can, do. Those who can't, become methodology consultants. It's as true of agile as it was of six sigma...

MRSallee 13y ago

I'm only superficially familiar with Agile. I feel this piece isn't very specific -- specifically, what benefits of Agile are being missed and why? I like the Cargo Cult analogy, and the author paints a fairly clear picture of what misapplied Agile tends to look like. Just not clear on what it should look like.

crag 13y ago

No... agile has failed cause most of the "enterprise" apps written in the "agile way" (and many claim to be) are crap. This isn't the fault of the agile manifesto. It's the fault of consultants who used Agile as a buzzword. The same consultants who never understood agile or cared to; producing apps riddled with bugs. Agile was heading to the abyss the day it was co-opted into a marketing buzzword.

carsongross 13y ago

To the extent that I've seen development methodologies work, they appear to mostly fix organizational barriers that get in the way of The One Thing That Actually Works[1]: hire a small group of extremely talented developers and product designers and then let them work. [1] Assuming your codebase isn't already a monstrosity. If it is... well, then nothing works.

brightsize 13y ago
> hire a small group of extremely talented developers and product designers and then let them work. Spot on. Whenever I go into one of my own anti-"Agile" rants, among my main points is that formal organizational process is simply unnecessary with talented, motivated development teams. In my long experience across many start-ups (which tend to get the aforementioned sorts of teams), if you just put a bunch of really smart people (devs) in a room with a project to do, Good Things happen. They know what needs to be done. They know how to do it. Any kind of formal development methodology just gets in the way. Management in those environments (and I've done that) is about care and feeding and listening and gaining consensus. It's not about religion or process. When I first read the Manifesto, not long after it came out, my reaction was YES! But in no time the Formal Methodologists came out of the woodwork and hijacked the whole thing, turning an attractive philosophy into just another management fad, one with nearly as much religious orthodoxy as what it replaced. Agile, with a capital "A", can't die quickly enough.
joshyeager 13y ago
How big is a "small group", in your opinion?
- carsongross 13y ago
  10 or fewer people.

adorton 13y ago

A "people manager" should never be put in charge of project or schedule management. It creates a conflict of interest between the realities of the project, and the outside pressure the manager may receive from other teams. That's why, at least with Scrum, the agile manager, if he or she is part of the same team, reports to the same manager as the development team. The agile manager's job is to keep the agile process running smoothly, removing impediments, etc.

allochthon 13y ago

> Because creating good software is so much about technical decisions and so little about management process, I believe that there is very little place for non-technical managers in any software development organisation. Well said.

nnq 13y ago
Yep. Good software companies tend to get this. But the zillions on creative digital-media agencies that popped up recently, and realized that yes, what they are doing is software development and nothing else, and that their "creative secret sauce" only contributes 10% max to the business fail to get his big time!

deleted 13y ago

[deleted]

hpaavola 13y ago

All these late "agile has failed" posts are out of touch with reality. They assume that it is always possible to get the best developers and best managers to work with the problem on hand. I'm a consultant. Officially my title is Senior Test Engineer and usually my job is to go to a company where shit has already hit the fan or will hit in a short time. The reality is that the company has a bunch of developers who are mediocre at best (and maybe one or two good ones) and managers who do not understand the situation. And of course the budget is already been eaten. They want to ship their product and make some money with that so they can continue to live their life. If I go there and say hey, you need better developers, more rapid prototyping and managers who are technical enough, nothing will change. Nothing will change because there aren't "rock star" developers avaialble, there isn't time to find new managers and definetly no motivation to change everything right now. Sure in some sense I might be correct to say so, but my goal is not to show my superiority, but to improve the situation. But if I teach them a little Scrum, help them setup some CI and so on, they almost always perform better. And then this statement "Because creating good software is so much about technical decisions and so little about management process, I believe that there is very little place for non-technical managers in any software development organisation." No. Good software comes from understanding the needs of your customers and meetings those needs. Shitty developers have and will create awesome products just because they know what the users want and need. "Agile" helps even the shitties companies to meet the needs of their customers.

briantakita 13y ago
Agile is the new RUP. The main audience is shifting toward the shitties. It's the circle of life for cultural movements. Nothing wrong with Agile. It's just not my thing anymore.
- hpaavola 13y ago
  By definition most companies, most teams and most individuals are average. There are very few really good developers and managers. What suits those few does not really matter. They will do great things not matter what. Agile works for most better than the alternatives.

briantakita 13y ago

IMO, the worst meeting you can have is the "agile inception". Do not allow a consultant who has no skin in the game to lead an inception. Do not allow them to have a louder voice than the engineers in the project. They can set a tone which is not coherent with the engineering team, which is bad, bad, bad. I've been involved with a few inception meetings. Two of them had terrible consequences for the life of the project. I got into a disagreement with a high level company executive in one and an "inception master" consultant in the other. They had no accountability for their "guidance" and they nearly killed the projects from the start.

oinksoft 13y ago

I had a comment I made into a post: http://www.oinksoft.com/blog/view/7/ http://www.oinksoft.com/blog/view/7/

abalone 13y ago

He just vaguely blames everything on "non-technical management" without really offering a cogent argument why. When he does get to concrete points, one of them is "Short feedback loops to measurable outcomes create good software." And yet "two week iterations" he calls "agile nonsense". The overal tone is kind of "technical macho" to me.. like, Real Developers don't need management and if you slipped then it's because your programmers suck and you should just hire better ones.

briantakita 13y ago
Non-technical agile management usually gets in the way. They get in the way with rigid prioritization. Prioritization means less gets done because you are optimizing sequential outcomes instead of a solid development process. Good engineers will evolve the architecture toward where the product is heading. Non-technical agile management uses points to measure the work that gets done because they don't know any better and they "need" to measure something. The technical architecture starts to go downhill over this never ending treadmill of the prioritized backlog with the non-technical task masters whipping their developers to get more points done. Sure, we can educate the non-technical management over keeping a low standard deviation of points. We can bargain to get technical cleanup time (marked as chores). We may even have a debt cleanup week out of the month. However, the spirit of the engineering endeavor is lost to the marketers, or their henchmen, running the project. It's too bad because subpar products and subpar code are the result.
SixSigma 13y ago
It would also suggest that someone who isn't a qualified doctor couldn't run a hospital. I continually run up against this attitude that programmers are somehow special and the rules of management somehow don't work with them. The sentence should read "The core problem is that bad managers will usually fail, or at best be counter productive, whatever the methodology".

keeptrying 13y ago

Has anyone actually seen a product manager cut features to make product better and to make sure the product gets shipped asap? Well now you know why agile was just iterated waterfall in most organisations...

alien3d 13y ago

I don't believe in agile. Agile come from inexperience project manager who tough programmer is cheap .The most problem this type of manager is,wanted to prove,if not from him company will gain zero income and income come from his negotiation and paperwork . Security,quality code all is abandon.It's about if the customer love it do it by hook or crook and wanted 110% quality .. In the end,customer is tired because changing of idea and implementation delay because didn't take counter measurement analysis on each request agile and time. both loose.

wavefunction 13y ago

Scrum Agile works great. Keep it light and loose and watch the code fly. I don't know much about the other flavors or taking it too far into process but I've seen the amazing things Agile as a philosophy can do.

mcv 13y ago
Different teams handle Scrum in totally different ways. On my previous project, it actually felt quick and light and agile. From one sprint to the next, we could switch to an entirely different sub-project, planning poker was quick, we never got around to backlog grooming, but somehow that wasn't a problem. We got lots of stuff done. My current project feels more sluggish. Long planning meetings where just one or two people decide on the story points. Somehow we never really get all our stories done in our sprints. This isn't a big problem, but it makes you wonder how we plan this, and why we plan this. The main differences I can tell between the two: this project we have a lot more documentation. All on wiki, but on the previous project, be barely had anything, and just asked people what the idea was and then did it. But my current project is at a bank, so it makes sense they want more planning and documentation, and less just figuring it out as we go. At another job, our Scrum wasn't really Scrum. We had standups, but that was it. No sprints, no poker, no scrum board, no burn down charts. But what this article makes me realize is that that project may actually have been more agile. Very few formal planning meetings, lots of informal communication and programmers just doing what they're good at and calling the shots.
- EdwardDiego 13y ago
  > My current project feels more sluggish. Long planning meetings where just one or two people decide on the story points. Somehow we never really get all our stories done in our sprints. This isn't a big problem, but it makes you wonder how we plan this, and why we plan this. When you raise this at retros, what sort of response do you get? I believe you can measure the health of a Scrum team by a) what issues get raised in a retro and b) do they get addressed? The iterative aspect of Scrum is also very much about iteratively improving process.
  - 13y ago

Toenex 13y ago

This comment on the OP site pretty much sums up a lot of these kinds of posts: Learn about all good and important methodologies, and take what fits your character and team. Any religious treatment of any method is not natural.

programminggeek 13y ago

This recent meme about agile is so dumb that I feel like I shouldn't say anything at all, but here goes anyway. I'll keep this as short as possible... Agile works fine for teams that embrace it. It's going to work totally different from team to team. The real point is to find the process that works best for your team to deliver software that meets the customer requirements and budget. Agile for a team of 1 or 3 is not the same as agile for a team of 10 or 100. Agile tends to fail in two places and they are both communication related. First, developers give terrible estimates because of pride. They don't think through the problem, they don't consider complexity, and they want to look awesome so they ALWAYS over promise and under deliver. That makes them look bad and destroys confidence in the project because it's dishonest. Second, managers will take estimates and turn them into deadlines because that is kind of their job and they are doing the best they can with the bad information that developers give them (see bad estimates above). A good PM needs to really push their team for real esteems. Poor estimates lead to poor communication because when things go badly, nobody wants to send up the signal flare for help or tell the boss that the project is not going to hit the deadline. This is often compounded when the client decides to firedrill a feature or bug fix mid sprint, and the manager doesn't push back and say that it is going to push everything else back. The best estimates are the ones that are the most honest, not the shortest. Between the bad estimates and the poor communication that comes out of it, there are plenty of times that "Agile" goes wrong, but it's not agile's fault. It's your fault. It's your team's fault. It doesn't work if you aren't willing to continuously tweak and reevaluate the process until it fits your situation. That means doing retrospectives and making improvements based on them. Continuous improvement makes agile work. A stagnant process is doomed to failure as requirements and resources change over time.

romaniv 13y ago
First, developers give terrible estimates because of pride. They don't think through the problem, they don't consider complexity, and they want to look awesome so they ALWAYS over promise and under deliver. This sounds like bullshit. More often than not, bad estimates are a result of built-in bias in the overall estimation system that gets blamed on the people. For example, I routinely see people underestimating larger tasks when the cost of splitting them is prohibitively high, while the cost of being late with a task is largely imaginary.

seivan 13y ago

Agile become this another layer of unecessary job creation for non-engineers

seivan 13y ago

The problem with agile was never engineering, it was non-engineerial management bs.

bowlofpetunias 13y ago

Once again, this is about mismanagement rather than Agile or software development. Besides the objections concerning throwing out the baby with the bathwater when it comes to Agile, I also object to the notion that non-technical managers cannot manage a software project. True, 90% of all non-technical managers do not have the knowledge necessary to manage software development, but very little of that actually includes hard technical knowledge. As a tech manager with 25+ years of development experience, most of my work involves management skills, not technical skills. The technical insight needed can be taught to any smart non-technical manager. Also, managing a software project is not about being "in charge" and micromanaging, but mostly about serving, protecting and coaching a team. People in the "no management" camp mistake management for hierarchy. Being the manager is a team role, just like being a back-end developer, and interaction designer etcetera. None of this is about Agile or management, it's about two sides, old school hierarchical "programmers-are-codemonkeys" management and tunnel vision "we-don't-need-no-stinking-suits" developers, trying very hard not to understand each other. And using Agile as a stick to beat each other with. If Agile is dead, it's because it's been brutally murdered by two factions unwilling to face their own shortcomings.

McP 13y ago

I found that in my team that agile worked brilliantly for us at first - we were working together to create features that customers loved. Then support queries came in for the features we developed previously. At first a couple of team members would split off and work on the existing features while the rest of us carried on working on the new hotness. As we increased the number of (quite diverse) features, the more diverse the support queries got. Now we're basically no longer a team, but a group of individuals working in different areas, who happen to be in the same stand-up each morning. I am actively looking to fix this problem. I'm sure this must have been discussed already but I can't find it! Any suggestions?

joshyeager 13y ago
We have a similar support load, but have been able to avoid that problem. I attribute this to two things: - We have a highly skilled support team that can handle pretty much everything except actually writing bug fixes - Every iteration we pull the whole team back to swarm on feature development together. They may get pulled into different historical features for support, but new development is always done as a team. Support is still very costly for us, because the distraction of working on old features slows down new development. To combat that we're putting a lot of effort into fixing the root causes of our support issues and training our support team to handle more and more technical problems.
mhw 13y ago
It depends what you mean when you say 'support queries' - I'm guessing it's more than just someone not understanding how a new feature works. Here are some possibilities for what you're experiencing: * 'support queries' are actually bug reports: you're getting something wrong with your automated testing that's letting bugs get out into released code. Ideally you should have acceptance tests that make sure the code is doing what it should before you release it. Check what your team's criteria for 'Done' is - are they cutting corners to get things out the door? * 'support queries' are actually missing functionality in new features: you're not getting all the requirements for the feature in the sprint where you implement it. You need to make sure the conversation with the product owner covers everything that the feature (user story) should do. * 'support queries' are actually new feature requests: they should go in to the backlog and be prioritised along with everything else. You shouldn't let people push work into a sprint that hasn't been prioritised by the product owner.

hibikir 13y ago

The issue is not really having a manager that is technical or not: I have met great managers that were not technical, and terrible ones that were technical. Success comes from trusting your people, having a clear goal the team believes in, and a team of the right size to accomplish said goal. Every successful team I've been a part of had all three. When even one is missing, there is much dysfunction. The agile rituals are there to try to make those things easier, but they are just a way in: If you meet the important principles, you do not need them. Just look at the Valve method: No management, no ritual, but a hiring process that attempts to just get the kind of people that focus on those principles like a laser.

mankypro 13y ago

...

MartinCron 13y ago

The article closes with this idea: @sbellware we should bury agile, mourn the dead, and get on with establishing something that is designed to be resistant to being so easily undermined https://twitter.com/sbellware/status/443397344436817920 https://twitter.com/sbellware/status/443397344436817920 Which makes me wonder, is it even possible to create a "thing" (idea, movement, methodology, system, whatever) that is resistant to being undermined? I don't think so. It seems like a natural cost to attaching a name to something. This is why I try not to talk about "Agile" these days, but rather just to try to discuss the specific principles that have proven valuable for me.

wpietri 13y ago
The one big mistake I think the Agile people made is not trademarking the term Agile and then enforcing some standards. There was discussion early on, but for some reason it never happened. For Agile it would have been hard, because Agile isn't a methodology on its own; it's an umbrella for a bunch. Enforcing standards doesn't make it proof against being undermined, but it does make it harder. There's still a tradeoff between being popular and being great that's hard to resolve. Especially since a popular, non-great thing is more likely to get lots of money and attention.
- MartinCron 13y ago
  That's an interesting idea, but my first instinct is that the cynical developer response to "Agile(tm)" would be even more harsh than to just "Agile".

davidgerard 13y ago

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