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.<p>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.<p>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.<p>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.<p>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.<p>But if I teach them a little Scrum, help them setup some CI and so on, they almost always perform better.<p>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."<p>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.
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.<p>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.<p>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.<p>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.<p>[1] <a href="http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/" rel="nofollow">http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...</a>
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.<p>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].<p>[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<p>[1] you know what they say about how sausages are made<p>[10] <a href="http://gizmodo.com/apple-guilty-of-price-fixing-730018979" rel="nofollow">http://gizmodo.com/apple-guilty-of-price-fixing-730018979</a>
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...<p>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.<p>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.<p>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.<p>The best estimates are the ones that are the most honest, not the shortest.<p>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.<p>Continuous improvement makes agile work. A stagnant process is doomed to failure as requirements and resources change over time.
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.
He just vaguely blames everything on "non-technical management" without really offering a cogent argument why.<p>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".<p>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.
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.<p>[1] Assuming your codebase isn't already a monstrosity. If it is... well, then nothing works.
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.<p>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.
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.<p>Of course many individual teams fail at agile but those teams would probably fail no matter what approach they were using.
No... agile has failed cause most of the "enterprise" apps written in the "agile way" (and many claim to be) are crap.<p>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.<p>Agile was heading to the abyss the day it was co-opted into a marketing buzzword.
I found that in my team that agile worked brilliantly for us at first - we were working together to create features that customers loved.<p>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.<p>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.<p>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?
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.<p>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.
> 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.<p>Well said.
Once again, this is about mismanagement rather than Agile or software development.<p>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.<p>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 <i>management</i> skills, not technical skills. The technical insight needed can be taught to any smart non-technical manager.<p>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.<p>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 <i>not</i> to understand each other.<p>And using Agile as a stick to beat each other with.<p>If Agile is dead, it's because it's been brutally murdered by two factions unwilling to face their own shortcomings.
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?<p>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.
Has anyone actually seen a product manager cut features to make product better and to make sure the product gets shipped asap?<p>Well now you know why agile was just iterated waterfall in most organisations...
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.<p>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.<p>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.
The article closes with this idea:<p><i>@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</i><p><a href="https://twitter.com/sbellware/status/443397344436817920" rel="nofollow">https://twitter.com/sbellware/status/443397344436817920</a><p>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.<p>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.
This comment on the OP site pretty much sums up a lot of these kinds of posts:<p><i>Learn about all good and important methodologies, and take what fits your character and team. Any religious treatment of any method is not natural.</i>
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.
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.
I had a comment I made into a post: <a href="http://www.oinksoft.com/blog/view/7/" rel="nofollow">http://www.oinksoft.com/blog/view/7/</a>