Is Agile Development a Failing Concept? 507
Nerval's Lobster writes: Many development teams have embraced Agile as the ideal method for software development, relying on cross-functional teams and adaptive planning to see their product through to the finish line. Agile has its roots in the Agile Manifesto, the product of 17 software developers coming together in 2001 to talk over development methods. And now one of those developers, Andy Hunt, has taken to his blog to argue that Agile has some serious issues. Specifically, Hunt thinks a lot of developers out there simply aren't adaptable and curious enough to enact Agile in its ideal form. 'Agile methods ask practitioners to think, and frankly, that's a hard sell,' Hunt wrote. 'It is far more comfortable to simply follow what rules are given and claim you're 'doing it by the book.'' The blog posting offers a way to power out of the rut, however, and it centers on a method that Hunt refers to as GROWS, or Growing Real-World Oriented Working Systems. In broad strokes, GROWS sounds a lot like Agile in its most fundamental form; presumably Hunt's future postings, which promise to go into more detail, will show how it differs. If Hunt wants the new model to catch on, he may face something of an uphill battle, given Agile's popularity.
Agile. (Score:5, Insightful)
DNRTFA, but I think this will be a fun thread.
Regardless of what Agile really is (a true scotsman?) the abuses perpetrated in the name of agile are appaling. I think a lot of people think agile means something like:
make bad developers good by not bothering to organise things properly
Which is really amazingly appealing if completely bogus.
Re:Agile. (Score:5, Insightful)
...and make good developers bad by drowning them in meaningless process (i.e. create task for every minute change, span multiple tasks if it takes too long), all while making everyone less productive by wasting time in scrum meetings taking 2 hours every day.
Re:Agile. (Score:5, Funny)
I'm in a "stand-up" even as I type this response. Ours are typically only 30 minutes or so. Unless, of course, our PM decides to tack on some estimation at the end, then they balloon to an hour or more. Then our QA lead tacks on a discussion of every recently-active ticket.
Most of us just check out of it mentally and go do something else (like read /.) after our personal status update.
And it ended as I typed that last sentence. LUNCH TIME, MUTHAFUCKAS!
Re:Agile. (Score:5, Funny)
Funny you should mention this... I actually got a lot of actual work done in the two-hour monster retrospective I sat through this morning. I just listen for my name and glance at the Kanban board occasionally to see if I come up next. :)
Thank Heaven for wifi and laptops, is all I can say, else I'd never get anything done.
Re:Agile. (Score:4, Interesting)
Thank Heaven for wifi and laptops
Sigh. That's why my company banned laptops from sprint planning and sprint retrospective meetings. With forty devs, it takes about six hours to score enough stories to keep all of us busy for two weeks. The retrospective, aka bitch sessions that really hurt morale, take a couple of hours. That's an entire day wasted every two weeks with nothing done. Add-in the JIRA-induced overhead, preplanning meetings, creating user stories, etc., and I think I only get to write code about ten hours a week. Agile is just too heavy of a process.
Re:Agile. (Score:5, Insightful)
Re: (Score:3)
We practice stop/start/continue retrospectives where each team member gets to put up at least 3 items. They are then ranked by frequency ( if 3 people say that doughnuts every morning is a continue item) it gets a rank of 3.
It a structured and relativly fast process, we take the top 5 stop/start items and apply them on the next sprint. It important to limit it to 3 or 5 so that its achievable.
Hence the retrospectives can be reduced to under an hour.
We also practice the 70/30 rule, only 70% of the devs tim
Re:Agile. (Score:5, Insightful)
We limit our scrums to 15 minutes per day. If it's taking longer than that, you're doing something wrong. Your teams are too big, or your sprints are too long, or you're going into too much detail on items, etc.
Re: (Score:3)
Exactly - scrum is a status report to make sure everyone is on track, not a meeting to resolve problems. If you have problems, take it up with the scrum lead after the meeting. In three years of doing scrums, two hit the 20 minute mark and most are 10-15 at most.
Re:Agile. (Score:4, Insightful)
If you need something from someone, or are having a problem, there is no reason to wait until the next day to bring it up.
If your scrum is a 'status meeting' and you also have an issue tracker (like Jira), then they are redundant.
If you are working with someone in the same section of code, and you need to go to a meeting to find out status, you are doing something wrong.
If you are bringing up issues in a meeting that don't relate to 90% of the people there, you are doing it wrong.
To look at it a different way, the Linux kernel coordinates hundreds of developers perfectly well without having a daily standup. You can do that too.
Re:Agile. (Score:4, Informative)
Standups are the one time you're guaranteed to catch everyone on your team, so that you can't be blocked for more than a day on anyone internal - and the scrum master should be taking note of anything external your blocked on.
When scrums say more than "I'm on track, next" or "I'm blocked by X" or "I'm late, sorry", the only real excuse is that you're not using any issue tracking system for tasks, and so the 15 minutes standing around at least saves you the time to keep fiddling with tasks in a DB. If it takes more than 15 minutes, you should just walk away from the standup (I've done this before - it sends a strong signal once multiple people have the courage to do so).
Re:Agile. (Score:5, Informative)
The hell? My daily standup is 2-4 minutes. Restrospective takes 15-30 minutes, subsequent planning takes another 30-45. We do weekly sprints, so you're looking at an average worst-case of averaging 19 minutes a day. Boo-fucking-hoo.
If your standups take 2 hours, then screw that. Tell them what you did, what you're going to do, and what's blocking you. If someone wants to have a long discussion, sit back down and go to work, because the standup is apparently over. If anyone complains, tell them to take a course in scrum.
Re:Agile. (Score:5, Interesting)
I've tried to point out the stupidity of this situation to some of these people (at least change the name!), but the irony escapes them.
Re:Agile. (Score:5, Insightful)
If your Scrum meeting takes more than 30 seconds per developer, you are not doing Scrum.
Re:Agile. (Score:5, Insightful)
Scrumm meetings should never be more than 15 mins, each team member gets 2 mins to describe what they did yesterday, what they will do today, and what inpediments they have. Scrumm meetings should be just the team standing around a whiteboard. They are fast, focusec, to the point and designed to get the team synced up and problems surfaced.
If you are spending 2 hours on a scrumm meeting/standup then you have a seriously screwed process.
Re: (Score:3)
Scrumm meetings should never be more than 15 mins, each team member gets 2 mins
If you have 8 members, that's already more than 15 minutes.
Re: (Score:3)
Re: (Score:3)
Not when you have a large project, being delivered by 30 or 100 devs. You don't do scrum at that level (well, some do some silly scrum-of-scrums nonsense), but you do do Agile. The actual teams developing the deliverables, though, need to be kept small for scrum to work. (There are non-scrum flavors of Agile, too).
However big or small your project, however, if you don't accept that requirements will change, and choose some methodology that makes it cheap to change, or if you don't get the smallest V1 you
Re: (Score:3)
However big or small your project, however, if you don't accept that requirements will change, and choose some methodology that makes it cheap to change
What methodology from the last 40 years doesn't accept that requirements will change?
Re: (Score:3)
Re: (Score:3)
I've been on several projects over my career where months were spent designing stuff in painful detail, and half the design would inevitably be thrown away as requirements changed during the 18-month release cycle. Throw-away coding work, throw-away design work, throw-away costing and task breakdown work. What crap. And then people would start getting indignant about requirements changes (because no one likes to see work thrown away), and it's all downhill from there.
And then at the end, the PMs are livi
Re: (Score:3)
Its n to n, do you really want to have to read through a bunch of emails broadcast to everybody from everybody. standup makes sure everybody DOES sync up, no phones allowed, no laptops or tablets. Focused syncing of purpose.
Re: (Score:3)
The status updates are just status updates. n one way communications. No discussion/planning allowed.
I'd rather have them in my inbox (where they won't change) then have to listen to them. I can read faster than most people can talk. Written communication is usually better thought out.
Also I can just cut and paste my daily status updates.
That said: I'm team lead. So I'm keeping track of what everybody is doing, most devs only need to know what one or two others are doing and can read only those updat
Re:Agile. (Score:4, Insightful)
Standups are all about keeping the team synced up and surfacing issues preventing completion of tasks. They are so the scrum master and the team lead can do thier jobs and smoke out and remove impediments. They are not about providing management status reports, I get that data by inspecting the project burn down charts, and the bug tracker ticket reports for the sprint. Nobody writes down any minutes for standups, so they are not about management or reporting, scrumm master and tech lead may make notes do they can investigate blockages.
Re: (Score:3)
Besides, a daily scrum as they are supposed to be done is meant for team members to get together to tell each other what they are doing. Managers are not supposed to be involved or run them.
A great sign that you're doing Agile right is the absence of weekly status reports. Your boss should learn all he needs by listening to the scrums, and seeing what actually get delivered at the end of each sprint. If you have scrums and also have weekly team meetings or status reports, then you have the worst of both worlds, and should probably fire your boss (economy permitting - lots of hiring in the Seattle area!).
Re: (Score:3)
Which is also really amazingly appealing and also completely bogus :)
Re: (Score:3)
I'll split down the middle of this. In the agile shops I've worked in, there has been a consistent strong aversion to producing documentation that is actually useful: design specs, etc. However, there has also been a consistent trend to dramatically increase the amount of worthless documentation: documenting the process itself (encouraged by tools like Version One).
Re:Agile. (Score:5, Insightful)
Yeah, people put it forward as some universally awesome technique.
Different teams, different projects, different management .. you can't simply say "yarg, teh agile" and have it work in all cases.
You don't see most other forms of engineering or building of stuff done in an agile manner .. bridge builders do not wait to design the deck until later, car makers don't just wing it an hope they'll be able to make the parts fit.
For rapid prototyping and some kinds of projects, sure.
But I've seen someone try to run a distributed project using agile techniques to build a replacement for a key piece of software with very specific requirements, and which needed to work against published interfaces.
And the end result was a project which produced a random subset of required functionality, was abysmally late, what it did do it did poorly, and then the project was cancelled. And as often as not the developers were writing the eye candy before the functionality, and adhering to the published interfaces was non-existent because the people involved decided to reinvent the wheel and decided that the existing stuff didn't matter ... because apparently the existing stuff would magically take care of itself.
Agile is a tool in the suite of project tools ... it's not universal to all projects, it doesn't produce perfect results just for being agile, and it sometimes doesn't even produce the required results.
Saying "we're going to keep throwing pieces at it and hope that in the end we wind up with what we were hoping for".
Like it or not, the waterfall method of development and project management still has its place, and it always will. And, likewise, I'm sure there are teams and projects for which agile will be an awesome fit.
And sometimes the people who decide which method to use are the least qualified to run the project -- I've seen developers insist on agile and fail to deliver anything useful, and I've seen PMs insist on waterfall and do a terrible job of managing it.
Methodology is a tool, not a magic wand.
Re: (Score:3)
And the end result was a project which produced a random subset of required functionality, was abysmally late, what it did do it did poorly, and then the project was cancelled. And as often as not the developers were writing the eye candy before the functionality, and adhering to the published interfaces was non-existent because the people involved decided to reinvent the wheel and decided that the existing stuff didn't matter ... because apparently the existing stuff would magically take care of itself.
I'm confused. What the fuck does any of that have to do with Agile development?
Adopt any fucking methodology you like and it would've gone wrong because you were clearly employing clowns.
Re:Agile. (Score:5, Interesting)
But you know, development isn't about making developers 100% happy. It's about product.
I spent around 15 years as a developer, and now I'm closer to a PM.
Development has to have actual goals, clear targets, and measurable outputs -- because you're either writing something specific which has to work as designed, or you're releasing a version of a product which has to fix a set of things and add a set of features. Both of these will probably have deadlines.
The problem is when we see it as "we must keep the developers happy" or "we must keep the middle management happy".
You're all, in theory, on the same team. If the developers have no measurable yardstick to judge their progress, or middle management collects a bunch of meaningless metrics which don't help the development process ... you're doing it wrong.
It has long been observed that managing developers is like herding cats.
Fundamentally what is happening is you need to ensure all of the cats get to the same place at the same time. Some cats, once they understand the goal, will plan their own route and get there in plenty of time, and will assist in getting some of the other cats there ... others need to be dragged hissing and mewling to make sure they don't go off in random directions and not show up.
In my experience, some teams will organically manage their stuff, and others need a good swift kick in the ass.
I've met a few developers who need to have a little friction foisted on them, or they drift a little. And some of the best managers I've known are ex coders who understand this.
The trick is to fool the cats into forming a self organizing collective, as well as implementing ways to keep tabs on all of the cats to ensure none have gone chasing butterflies.
The specific methodology is as dependent on which cats you have as anything else.
Good idea, hard to implement in the real world. (Score:5, Insightful)
Like so many other things, it's very difficult to take an ideal theory and put it into practice in the real world. If your team really understands the ideas behind Agile and you have a good process in place to make it happen, you can have a great deal of success.
Unfortunately, like so many other things in life, most teams don't get it right and they end up failing to some degree or another.
Re: (Score:3)
Like so many other things, it's very difficult to take an ideal theory and put it into practice in the real world. If your team really understands the ideas behind Agile and you have a good process in place to make it happen, you can have a great deal of success.
Unfortunately, like so many other things in life, most teams don't get it right and they end up failing to some degree or another.
Cannot be restated often enough.
I've worked in a shop that started doing "Agile" development after years of more waterfallish practices. This essentially meant that we started to get customer requests organized in an Agile toolset and then had a sprint planning meeting to negotiate the value of the various requests so that we could start work on them. Standups often took a half an hour for 6 people, including the PM, who unfortunately doubled as the scrum master. It wasn't terribly agile, and it didn't buy
Re: (Score:3)
1) Pay attention to who you hire and who you select for your team. Software development is about people.
2) Do not replace thinking with process and methods.
Process and methodologies provide useful structure and standardization but it will not turn crap employees into good ones. They do however have the potential to turn great employees into mediocre ones.
Right conclusion, wrong reasoning. (Score:5, Insightful)
Re:Right conclusion, wrong reasoning. (Score:5, Insightful)
Re:Right conclusion, wrong reasoning. (Score:5, Interesting)
From where I've sat Agile just looks like 'weekly iterative waterfall; skimp on testing'.
Re: (Score:3)
Well ... people will cherry pick what they want out of stuff, and will NEVER implement it all according to your perfect idea. Reality simply doesn't allow for perfect implementations according to an abstract theoretical model.
That is a 100% true fact. It's true for Agile. It's true for Waterfall. It's true of religions, philosophies, and all other -isms.
At the end of the day, someone says "but you didn't do all of the things I said you should and therefore the failure of my awesomeness must be in how yo
Re: (Score:3)
Well ... people will cherry pick what they want out of stuff, and will NEVER implement it all according to your perfect idea. Reality simply doesn't allow for perfect implementations according to an abstract theoretical model.
That is a 100% true fact. It's true for Agile. It's true for Waterfall. It's true of religions, philosophies, and all other -isms.
At the end of the day, someone says "but you didn't do all of the things I said you should and therefore the failure of my awesomeness must be in how you did it".
Which is convenient and all, but if your system comes down to "my idea is perfect but your execution sucked" ... well, maybe your perfect idea is far too damned reliant on fundamentally unrealistic assumptions which aren't justified?
If your perfect abstraction doesn't hold up to reality, maybe it's not reality which is lacking? Or at the very least that your perfect abstraction is an incomplete theoretical model.
No software development methodology survives first contact with actual coding.
Re: (Score:3)
But that is exactly what is the core of Agile.
"You keep using that word. I donna think it means what you think it means."
Re:Right conclusion, wrong reasoning. (Score:5, Interesting)
Funny thing is that the original 'AGILE Manifesto' wasn't 'theory' or even a methodology: it was really a set of observations on what did and didn't work for them.
I think the 'universal solution' aspect of AGILE is let your smartest people work the way that they find most efficient - trust your (best) people. Many of the core concepts are not revolutionary: don't get bogged down in planning, work in small teams, prepare to adapt rapidly when your spec cannot be fixed.
The AGILE guys were inspired by the obvious wastefulness and inefficiency of the big enterprise software projects they had been on, so to that extent their observations were dead accurate. But now people are acting as though the *specific methodology* that's grown up around it is precious, holy and applies to everything, everywhere.
It's exactly like the scene in 'The Life of Brian; where Brian loses his shoe running from the crowd: one guy argues that they should all hold one shoe in the air, and the other guy wants to gather shoes together. The shoe is not the point (SCRUMS, Pair programming, backlogs), it is the idea of working intelligently.
Re: (Score:3)
All development methods are flawed (Score:5, Insightful)
When developers try and add those stupid terms, they're basically saying that they can't self manage and instead of taking responsibility, they're going to throw silly management methods around in an attempt to streamline a task which is unique to each individual developer and situation.
The only things you need to write good code are the right language, the right platform and proper requirements. Once you have those, you can just start and work to completion.
Re: (Score:3)
The first one is easy, there's so many to pick from that one must be a decent fir. The second one also has plenty of choices.
Ah. Next time we'll take them in reverse order. As they say, fail early!
Re: (Score:3)
The only things you need to write good code are the right language, the right platform and proper requirements. Once you have those, you can just start and work to completion.
I guess that means the world has never seen good code.
Re: (Score:3)
Exactley right, developers are not hired to write code, they are hired to produce products.
My .$02 (Score:4, Insightful)
Comment removed (Score:5, Insightful)
Yes (Score:5, Insightful)
Agile started failing pretty much as soon as it met the real world. I disagree with Andy Hunt's explanation of why, though. It's not because "thinking is hard", it's mostly because of two things: management not allowing agile to be done correctly, and (from the developer's point of view) it drains software engineering of the things that make it a satisfying and enjoyable activity, turning it into the software equivalent of grunt factory work.
Re: (Score:3)
I second the management thing. None of the managers want to change the way they manage things (I need a schedule for your work for the next 6 months!) in away that prevents any of the advantages of Agile from being fully realized.
Re: (Score:3)
Management push-back is a tough one and understandable. They want to know where the company is going in a quarter, two quarters, next year. That means big plans, and it means estimating the size of things way in advance. That's something that Agile is specifically designed to avoid - unnecessary advance planning. I think this conflict exists (or should exist) even in the best Agile development shops. The alternative is the ultimate in management short-sightedness - no plan for the future, just get through t
Re:Yes (Score:4, Insightful)
it drains software engineering of the things that make it a satisfying and enjoyable activity, turning it into the software equivalent of grunt factory work
I'm confused. The satisfaction and joy of software engineering is turning a problem into a working solution.
The agile methods I followed let me realise that joy multiple times a day - checking in working code, and see it pass the automated test bed on the build server.
What is it that you perceive to be satisfying and enjoyable, and how are you losing that?
Yes, but not because it's a bad idea (Score:3)
So, yes, Agile is a failing concept. Not because the idea bad, but because it's so incredibly difficult to implement fully, and it's not very valuable when partially implemented (you basically just turn it into mini-waterfalls).
I foresee DevOps ending up with a similar problem.
It's only been 14 years... (Score:5, Insightful)
That's not even close to enough time for a major cultural change to take place. The Agile Manifesto describes a culture of work that is so fundamentally different from how work was (and still is) performed, that I expect it will take another 15 to 30 years for organizations to really "get it". This is the same thing that happened with Lean manufacturing. Toyota developed it, other manufacturers adopted it as a fad over the course of about 15 years, and then it declined in popularity... but it never died out because it was "correct" and "good". Now, 40 years later, most manufacturers are still learning to be lean, but lean has fundamentally changed the culture of manufacturing. I have clients that will probably be working to adopt Agile methods over a 10 to 20 year period. Agile hasn't failed... Andy Hunt's patience has failed.
Hmm... (Score:3)
The articles to which TFS links point have more than a few links and references to other articles, blogs and books (yes, "see my article/book") written by Andy and the "gang of 17". Not exactly astroturfing, but certainly rather self-promotional. "Agile" is one methodology, appropriate for some situations, but certainly not the "one ring to rule them all." (if I recall, wearing that ring had some negative effects...) Now he wants us to move on to: "The GROWS (TM) Method."
All this probably benefits someone, not sure it's always us.
love/hate view on agile (Score:4, Insightful)
Certainly Not (Score:4, Insightful)
Iterative, incremental development - the core of agile - has been around at least since Barry Boehm described the "spiral model" of development in 1986, and has been successfully used for nigh upon 30 years since under various monickers (and I'll bet there were practitioners before Boehm's paper).
"Agile" has matured and developed a lot of inter-related supporting practices and tools that have made it increasingly powerful and easy to implement. Continuous integration, test-driven development, use of "stories" as a tool for requirements definition, you cannot tell me these techniques and tools are not successful.
I have personally seen the development practices of a company dramatically transformed for the better by having an agile trainer brought in and training the entire staff, including managers, and instituting formal agile practices. It is great when a junior developer can tell the VP of marketing to take a hike because his request has not been submitted through the grooming and priority assignment process.
This one experience gives me complete confidence that people mocking agile simply do not know what they are talking about.
One problem agile does have is with zealots who don't understand that this is, and has to be, a collection of related practices that must be tailored to the needs of the environment, not a one-size-fits-all, all-or-nothing thing. Another problem is thinking that "form" is what is important, not "what is happening".
For example: holding stand-ups is not agile. It is a common, useful tool to use in an agile environment. If your team is coordinating with informal sessions as needed, Skype, chat tools, and an updated Wiki in real time, and the managers are keeping in the loop using these tools, then maybe a stand-up is a waste of time for you. I think most teams benefit, but design and planning is not part of a stand-up, other meetings are needed for these.
There can be long-term planning that does not follow the agile model, and can be described as water-fall, and this has its place too. But I think the only really successful development practices are variants of an "agile" type process.
Well (Score:3)
I've been watching the idea since the early 00's. I've been on teams that have adapted the processes to work for the team and have been very successful doing so. I've seen a team get a cadence going and become extremely accurate at estimating new work for a product the same 5 people worked on for 5 years. During that time they also dramatically improved the quality of the code, reducing crashes that required weekend coverage to almost 0. Every once in a while they'd adjust their processes if things weren't working smoothly. Teams can work very effectively in an agile environment, if they're actually allowed to.
If you follow the evolution of agile, you see a lot of key concepts that get repeated over and over. The guys who wrote it understood that code is never perfect and never really correct the first time you write it. It pushes unit testing as a core component of the process. As with other things, making mistakes and correct them teaches you something about the problem, and so the whole process is designed around uncovering those mistakes quickly, throwing code away and rewriting it and constantly improving quality. The philosophy of most companies is that the developers should just crap something out that kind of works and then move on.
What it basically comes down to is just because your team is agile doesn't mean you can hire chimpanzees to write your code. Or manage the team. If you're looking for a silver bullet that will fix what's wrong with your company, agile isn't it. It enforces much more discipline than whatever crappy process you were using before that, but you really have to understand what it's about, and most people don't.
The problem is not methodology... (Score:5, Insightful)
it's management. When you get a good project manager its like a breath of fresh air. The best PM I ever worked for was a guy that used to be a developer and just didn't understand object based programming, after an honest assessment, so he decided to go into project management. He shielded us from all the corporate BS and just let us code.
Most of the other PM's I have worked for have no background in programming. Some of them claimed to and didn't, which is much worse than someone that just tells you they don't. They would insist on idiotic exchanges like the following:
PM: How long will it take to code this?
Me: I'm not sure until I get all of the requirements
PM: Can you give it a guess?
Me: Sure but what's the point? It won't be a very good guess.
PM: That's OK I just need something to put on the project plan
Me: *Bullshit radar is now on full alert* So you just want me to pull something out of my ass so that you can finish up your project plan? Is that it?
PM: Umm, well, no...it's not like that
Me: OK, fine. I'll give you numbers but they are going to be grossly inflated to account for the unknowns. It covers my ass. Kind of like what you are doing, no?
PM: *Grunts and walks away*
Most of these people look at project management as if we were building widgets on an assembly line. As if we know exactly how long each task is going to take. Well, software development is not not like that. Not in the least. The ones that understand that - the ones that are truly "Agile" as it were - are the successful ones. The successful ones understand that any number of things can go wrong and plan accordingly.
Agile is like ITIL (Score:4, Insightful)
I do systems engineering work for a professional services/software company. Development is fully Agile with a capital A, whether or not it makes sense for a particular project. On the systems side of the house, we have another particular religion called ITIL which lots of companies have jumped into with both feet. The problem with both of these concepts is that they are adhered to, almost to a comical level, even if it's painfully obvious that parts of it don't fit.
Adhering to all of ITIL, for example, is a really good way to ensure your production systems almost never change. The number of people and sheer volume of paperwork, tickets and meetings to get anything even scheduled for a change in a "true ITIL" system is beyond insane. The same goes for incident management -- we have so many single-task focused "resolver groups" that I have no idea how anyone knows how any of our systems operate end-to-end. ITIL is great for mainframe systems, safety sensitive stuff, and networks which never change.
"True Agile" and "True Waterfall" are opposite ends of the spectrum. Agile gets you very fast development, at the expense of pinning down any sort of architecture in the beginning. Waterfall often results in software you have to throw away because the requirements change out from under you. However, there are some things that require at least some discipline, both in systems and development. No systems guy would ever advocate just logging in and making random changes on a production system to see what happens. No smart developer/architect charged with writing something that underpins tons and tons of other things would advocate swapping out the core components without at least some backward compatibility thrown in. The prpblem is that "gurus" make their money selling management on these methods. In the case of both Agile and ITIL, it's a manager's dream -- everyone becomes a replaceable unit and business requests can get promoted to production in one Sprint.
Agile was always a scam. (Score:4, Insightful)
Why would anyone take something seriously that was created and peddled by consulting outfits at $700-per-hour bill rates? I had the misfortune of being incarcerated at Pivotal Labs for a month by a misguided boss who thought their bizarre religion was the answer to all of life's ills. Boy, was that eye-opening.
As many people rightly point out, that doesn't mean we can't pick up some new ideas from it - my company now does short daily meetings and have a chart with everyone's daily tasking on it, and those have proven very effective. But the other 99% of what the Snowbird 17 vomited forth upon our industry is empty zealotry and jingoism. It was like Scientology right in our codebases, and worked about as well. And no, for god's sake, it wasn't because we just weren't doing it well enough.
We do have shockingly dramatic quality issues in the software industry, but they will never be addressed by the next dumb-ass management fad. We need to sit down and re-think the ways that we learn to code, get serious about "Software Engineering" degrees in our colleges, and let go of fetishized code patterns as the primary unit of engineering ability. In my own experience, we know plenty enough design patterns, but almost no one understands how to exercise coding judgment in the context of a team or long-term project.
Agile truth. (Score:3)
Agile is nothing but an admission by clueless marketing/business development folks that they're terrible at their jobs. They have no idea how to do market research, they have no idea how to interact with actual or potential customers, they have no idea what a company's products actually do and what solutions they provide, they have no idea how to do the analytical side of their job, and have no vision at all for their industry. So instead they shove all the responsibility onto the development team: hack a small iteration together quick, show it to a customer (or more likely, show it to a cross-function representation of development groups within the company, none of which is trained in market analysis), and repeat until someone in upper management says "hey, this was supposed to be released this quarter". Then marketing will swoop in and offer to put together some glossies.
Obviously for situations like with a small start-up, you aren't going to have a well-rounded business development unit, and you'll be forced into having developers and other non-specialists pick up the business development slack. That's when agile makes sense: when you have no other option. But big companies with full business development and analysis teams pushing agile on its developers is nothing but welfare for idiot marketers.
It can't fail (Score:4, Insightful)
It can't fail cause all of the critics are doing it wrong.
You can thank "process improvement" consultancies. (Score:5, Interesting)
At its inception, the Agile manifesto was simple. Four priority/value statements and then a list of simple principles. The goal? Merely to say that delivering value to the customer, collaborating with customers, frequent delivery and feedback, and team empowerment are the way to deliver software. Focus on delivering value. Don't focus on delivering things that aren't valuable. Very simple.
Once Agile values started to become embraced and a couple of new development processes came along (SCRUM, etc), you all of a sudden had a bunch of consulting companies and community meetups appear that all but destroyed the perception of Agile. For these companies and community groups, it's all about the process. They will teach you how to "do agile". They will provide you with bodies/contractors who can "do agile". They will sell you certifications which show you "do agile". They will sell you seminars and training on how to "do agile". They will sell you software which "does agile". Agile has went from a basic set of values to becoming a fundamentalist religion.
So my statement to "Agile Process Improvement" firms is this: You are all just scammers and profiteers. You are software development Pharisees. It is amazing that you focus on profiting from creating processes, enforcing processes, teaching processes, and writing process software... for a methodology where the first value statement is "Individuals and interactions over processes and tools". Why don't you guys teach REAL agile? Why don't you teach companies how to better define value and deliver it to customers instead of selling new processes, fundamentalism, and bodies?
For the rest of you, if you want to be "Agile". Read the Agile manifesto. Create your own process that suits your team and your business. Work continuously with your customers to understand what is valuable to them. Deliver good value to them often and get their feedback. Allow your team to learn and grow and understand the needs of the customer. THAT is Agile. THAT is all you need to do.
Re:You can thank "process improvement" consultanci (Score:4, Informative)
Once Agile values started to become embraced and a couple of new development processes came along (SCRUM, etc)
That's a nice thought, but SCRUM actually predates Agile by half a decade. SCRUM was introduced ~1995, and Agile ~2001.
Though the actual Agile techniques are much, much older. Reading the Mythical Man Month can convince you of that.
Agile Oxymoron (Score:4, Informative)
I always find it funny for something named Agile and aimed at being responsive to needs that people are so "by the book" about it. I find it oxymoronic that there's "one true way" to do something called Agile.
Some employers are so by the book that they have to have a physical whiteboard with postits even though they also have to have jira and keep both those in sync. The purist agile says no remoting- face to face only, which I think is incorrect- I think "some kind of verbal or visual chat" is sufficient, but the key is communication beyond say hipchat and jira and email.
Some employers claim to be really purist about it and yet depart in significant ways. I think a lot of employers also use Agile as a way to squeeze long hours out of devs at the end of every sprint even though "purist" agile says 40 hour work week.
I generally like agile and it took a while for me to understand that MVP doesn't mean do the bare minimum for the sake of doing the bare minimum but with the idea you get it to the customer for feedback sooner and you iterate.
My Kingdom for Good Acceptance Criteria (Score:3)
If Agile is failing despite voluminous developer output, that's where the rubber hits the road.
In real world development, you are going to have acceptance criteria written to your PMs level of understanding of the product. Most businesses don't understand product managers, they understand *project managers*, and since project managers are just bookkeepers, organizers, and communication traffic facilitators, meant to be fungible across many types of projects, it just all goes to shit.
The experts who know the system can't be bothered to write the stories, and the project manager has no fucking clue what they are typing up.
Here's the stupidest thing ever: a company that develops with Agile, yet still has Subject Matter Experts communicating through the project managers. Of course you have to have a project manager, because it isn't a single team, or even all Agile teams, and the teams need to coordinate their efforts. And of course those SME's are too busy answering everyone's questions to be bothered to write out the specs properly.
Agile is like most high school physics: it works *perfectly* in low-friction environments.
Now, the pro-Agile people are going to say you aren't doing it right, etc. etc. You people are like communists: it works if you do it right! No, it doesn't, because it doesn't take into account corruption, greed, politics, propaganda, and deliberate mis-control of information for the benefit of a few. And those things are going to exist in any large-enough group of people.
Agile will not fix your organizational problems. It only shines a spotlight on them. Usually, when you point this out, everyone will nod their heads. They will all agree it needs to change. The problem is that no one with the power to actually fix the issue is in the room.
Re:No. (Score:5, Interesting)
Yes.
Re:No. (Score:5, Funny)
No.
But it'll be yes again by the time of the next scrum.
Re:No. (Score:4, Insightful)
Agile is not failing because there is nothing to replace it. Are we going to go back to Waterfall? Software development is inherently hard. No methodology is going to make it easy. But Agile works better than any other methodology that I have used, even when implemented piecemeal, by mediocre programmers, rather than in its "ideal form".
Ideas should be judged against their real world alternatives, not some perfect ideal. For Agile, there are no better alternatives. GROWS (whatever that is) may be an alternative, but it is untested, and looks like just an incoherent pile of buzz words.
Re:No. (Score:5, Interesting)
Are we going to go back to Waterfall?
In my experience, that would be greatly preferable to Agile.
But Agile works better than any other methodology that I have used, even when implemented piecemeal, by mediocre programmers, rather than in its "ideal form".
My experience is just the opposite: agile is very nearly the worst of the methodologies I've used. The one great thing about it is something that can be done in any methodology: increased communications. We can throw out the bathwater and keep that baby.
Re:No. (Score:5, Interesting)
Now, after two similarly sized Agile projects, all I can say is it seems to be an excuse for developers to skip QA/QC procedures "because we're already into the next scrum" and end up with a mess that doesn't come close to matching the original specification at the end blaming changing requirements and "developmental issues" during the scrum process. I just turned down a contract that explicitly required Agile coding because I don't have any confidence that the end user will be satisfied with the results.
Re:No. (Score:5, Interesting)
Re: (Score:3)
I started coining the term "Chunked Waterfall". Take all the inefficencies of waterfall, split it into chunks and add more inefficiencies due to management ;-)
Whenever somebody tells me they are doing agile I ask them how their chunked waterfall methodology will help them once they realize that 50% of their assumptions on a project are wrong and the market has changed while they were busy with scum meetings.? Denial is usually the response....
Re:No. (Score:5, Insightful)
Re:No. (Score:5, Interesting)
DING!
If by saying QA/QC isn't completed you mean that unit and functional testing is missing, then the developer is not done. If you have problems with the developer not writing these tests, then be sure that "Definition of Done" includes some acceptable target level of unit/functional testing.
If on the other hand you get to the end of a story and accept it only to find out that it doesn't meet your QA standards, then you as a product manager haven't done your job in properly validating the story prior to acceptance; add to your own procedures the time required to properly validate the story for acceptance. Maybe you need a testing resource to do this if you are overworked as a product manager - an assistant product manager, even.
Agile is as good as you make it.
Re:No. (Score:5, Insightful)
Agreed. Too many companies use the Agile "be flexible" rule as a carte blanche, get-out-of-jail free card.
They pick and choose what parts they're going to do, which parts they're going to ignore, and which parts to which they're just going to pay lip service, and call the end result "agile". They don't understand how each part reinforces the other, and as such pick and choose among practices and ceremonies, and tell one another that they're being "flexible".
Failure is usually with implementation, not with Agile.
Re:No. (Score:5, Insightful)
That is exactly what happens. And, some of the leaders in the field have realized that a lot of what is called Agile (Poppendiek, Larman, Vodde, Leffingwell) are essentially implementations of Lean Product Development from Toyota to Software Development. What often happens is that, like Lean in manufacturing, organizations take up some of the forms of Lean/Agile while completely missing the fundamentals and the culture. That is key. If you don't realize that Agile or Lean are an organizational culture change not a set of practices that are a silver bullet what you end up doing is slapping Lean or Agile onto a dysfunctional culture. And, one of the things that many Agile practices will expose very quickly is all of the dysfunctions and waste built into an organization.
Consider the poster who complained about QA/QC being ignored. What was happening in waterfall was the exact same thing, but the long QA/QC cycle was hiding the fact that the developers were producing crap. Actually, calling it QA/QC was a misnomer, it was actually finish all the stuff we half-assed during the development phase. Oh and what management thought they would get from Agile was that they could knock out QA/QC and get the same work done in the same time that would have been allocated for the development phase in waterfall. So, the same schedule pressures that forced developers to take short cuts in waterfall never went away, and the result is that the same shortcuts happened without the QA/QC phase to fix them. And, was there a retrospective or root cause analysis or empowerment of individuals to pull the stop cord on the train to correct these issues that were exposed. Of course not because if you stop you will miss the schedule and that cannot happen, etc.. etc... Slapping Agile practices onto a dysfunctional organization does not fix the dysfunction. Culture changes take years, especially in larger organizations when there is not the top to bottom commitment to changing the entire organization.
There is also the problem of "flexible" translating to "without discipline". My experience is that Agile and Lean requires a level of discipline far beyond typical waterfall. The waterfall processes often require the facade of discipline, but rarely actual discipline especially at the individual level. And, when discipline is attempted on individuals it usually has more to do with imposing additional process and reporting that does not contribute to actually delivering results. Which is exactly the same thing another poster complains about where Agile gets used to micro-manage daily tasks. Which is another example of missing the point, daily tasks and a daily meeting is to free PMs and Managers from micro-managing holding each person accountable for accomplishing something each day. I call it peer pressure accountability because other than sociopaths most people don't want to be the guy who tells their team mates that they did not do what they said they would do yesterday, or did some ridiculously trivial task while some one else did something significant.
In some cases Agile shouldn't be used, but those are generally caused by external forces like being in an inflexible contract situation. In that case, I advise the philosophy of "Don't lie to yourself." Instead understand your constraints and realize a lot of the practices used by Agile and Lean organizations are almost universally beneficial. Automated testing and continuous integration are a good idea regardless. Splitting work into small chunks and working on a cadence (takt time) can be beneficial locally even though globally you are still producing tons of WIP. And, so on and so forth...
Re:No. (Score:4, Informative)
Waterfall just cannot work.
1. All the descions are taken at the time you know the least about the outcome, ie at the begining.
2. By the time you get to the end your requirements are out of date, you get the product you wanted at the start of the project not the one you need now. If you try to support requirement change all you end up doing is replanning and pushing back delivery.,
3. It was a failed methodology from the start, the original paper that started waterfall was an example of how not to write software
https://pragtob.wordpress.com/... [wordpress.com]
Re:No. (Score:5, Interesting)
None of those are failings of waterfall at all. There is nothing about waterfall that requires you to make ironclad decisions at the very start, and there is nothing that prevents you from adapting the course of development as the project proceeds.
In other words, you aren't describing waterfall in your comment. Yes, I'm invoking the "No True Scotsman" fallacy, since that is usually what is invoked when Agile is criticized.
The real truth is that all methodologies can be done well or poorly, including waterfall and agile. The difference that I've seen in practice is that it's incredibly hard to implement Agile correctly (such that I've never seen it done), but implementing waterfall correctly is not a huge chore.
Re: (Score:3)
Waterfall just cannot work.
1. All the descions are taken at the time you know the least about the outcome, ie at the begining.
2. By the time you get to the end your requirements are out of date, you get the product you wanted at the start of the project not the one you need now.
Ridiculous. Maybe in stupid-ass punch-the-monkey dev shops writing web-based crap no one will care about in 6 months. There are plenty of industries where this is nonsense.
In international finance, some country decides on a new law (usually a new regulation). The software therefore must change.
Is the law going to change again this year? No.
Is the development cycle less than a year? Yes.
Is the development cycle longer than a fucking sprint? Yes.
Waterfall will work just FINE.
Re: (Score:3, Insightful)
Ridiculous. Maybe in stupid-ass punch-the-monkey dev shops writing web-based crap no one will care about in 6 months. There are plenty of industries where this is nonsense.
In international finance, some country decides on a new law (usually a new regulation). The software therefore must change.
Is the law going to change again this year? No.
Is the development cycle less than a year? Yes.
Is the development cycle longer than a fucking sprint? Yes.
Waterfall will work just FINE.
I had a small project which despite meet the deadline has took more than double of expected work hours.
Did I know I have to evaluate and change underlying platform 3 times so it could work with other dependencies flawlessly? No.
Did I know I have to write part of DB driver because some thing that has been in DB for years isn't supported in its official driver? No.
Did I know I have to dig into source code of dependent libraries and fix their bugs and even change part of their architecture to meet performance
Re:No. (Score:5, Insightful)
Waterfall just cannot work.
You might want to talk to NASA and tell them all their missions have failed.
1. All the descions are taken at the time you know the least about the outcome, ie at the begining.
You know what that's a sign of? Failure to specify your requirements. (Something Agile people know so little of these days it's unsurprising they should be banned from programming)
2. By the time you get to the end your requirements are out of date, you get the product you wanted at the start of the project not the one you need now.
I need what I specified. If I need something else now, I should have added on more requirements. In fact, at the start of the project I should have added in an allowance that just maybe I will need to change something, or a dependency in the project may shift in time or not meet its capabilities. BTW, for you Agile people, this is where the Project Manager usually does his work. If they're managing which requirement you're coding and how, he's not doing his job.
If you try to support requirement change all you end up doing is replanning and pushing back delivery.,
If I was originally scheduled to make a simple sort in an adequate time period and then need to add in a complex multi-layered sort, um, yeah? What makes you think changed requirements wind up being deliverable in the same time frame? What vacuum do you live in? Are there pink ponies there too?
3. It was a failed methodology from the start, the original paper that started waterfall was an example of how not to write software
https://pragtob.wordpress.com/... [wordpress.com]
Again, I guess you better let all gov agencies know that all their projects involving software prior to 2005 or so failed. Guess that moon landing really was on a stage somewhere.
Having been exposed to a number of Agile projects that all ran over budget, schedule and/or failed, I can truthfully say Agile itself was the cause. I've detailed some of those elsewhere, and the response from the believers is always "Oh, you're doing it wrong" which is hilarious, because in multiple cases they were following exactly what little is laid out by the Agile camp. The real truth is that there are developers of different skills, and there are some that excel in specific areas while the rest plod along, and they are not interchangeable like Agile states they are unless you're going LCD. In fact, if you estimate your "velocity" by your worst performing programmer on an Agile team, you may, just may, have a realistic estimate of when you'll supposedly get to the finish line as long as no one throws any new requirements your way. As soon as they do, everything you think you know just went away. Sorry, my next SCRUM is pulling me out of this one...
Re:No. (Score:4, Insightful)
Why "waterfall"? Why is every Agile evangelist so uptight about "waterfall", do they honestly think that there are only two possible methodologies in the world?
Re: (Score:3)
I've got to agree with JohnFen. As a Program Manager, while Waterfall techniques could frequently end up with late or over budget, or both, projects, at the end of every project (I oversaw 5 multimillion dollar projects using Waterfall methods) we at least had a working application that met the original specifications. Now, after two similarly sized Agile projects, all I can say is it seems to be an excuse for developers to skip QA/QC procedures "because we're already into the next scrum" and end up with a mess that doesn't come close to matching the original specification at the end blaming changing requirements and "developmental issues" during the scrum process. I just turned down a contract that explicitly required Agile coding because I don't have any confidence that the end user will be satisfied with the results.
Having participated in both; I can see benefits either way. However, allowing the developers to do what you've said is a fault in the management of the project. QA/QC/QE is part of Agile. If need be, you just add tasks (stories) in Agile to do it and make sure they get done - if not, you're not managing the project correctly.
Agile itself is about being responsive to the needs of the project, and that includes all the QA/QC/QE stuff, as well as Security, Bugs, Changing Requirements, etc.
Now, if you're
Re: (Score:3)
Because I'm being reponsible to the needs of the project, I end up being unable to do the tasks (stories) assigned during the development period (sprint). If I was irresponsible I would do just my parts in the sprint and tell all the competing needs to bugger off.
So the stories spill from one sprint to another. There's nothing wrong with that. That's part of the methodology of Agile, and also points that the project manager is not properly managing the project - whether not having enough people on the project to handle the work required for the sprint durations, or overloading the sprints in hopes of getting work done faster than they should, or the people involved in the project are not accurately breaking down stories into suitable chunks.
Re:No. (Score:4, Interesting)
The problem we have had with Agile thus far seems to be our inability to produce accurate estimates without doing Big Design Up Front which ultimately means spiking every story before we can get started. Nearly every time we try to shoot from the hip on story estimation for anything moderately complex (or worse), we have missed by several multiples the actual amount of work needed.
This is mainly due to the product being very complex (think enterprise scale SaaS, tens of millions of users, terabytes of data, complex data modeling, and numerous technologies being adapted with a variety of API/interfacing solutions) with many interconnected systems across multiple data centers and cloud services... you just can't stare at a story in the backlog and come up with a meaningful estimate off the top of your head no matter how well defined the acceptance criteria are because no one person knows what the potential impact is to all those systems.
But we're committed to working on improving our processes, cross-training, and reduction of overall system complexity to eventually be able to do just that and are sticking with Agile because it has forced us to take smaller bites which has really been a challenge for our sales/marketing and product owner teams because they want the world and they want it yesterday... and Agile empowers the scrum team to give them a reality check and say no.
I apologize for the run-on sentences... too lazy to edit at the moment.
Re: (Score:3)
Or, as I put is in a longer post. Agile practice have a tendency to expose all of the dysfunctions and waste. The analogy is that a deep slow moving river hides even the big rocks. Agile lowers the water level and starts exposing all the rocks, and the point of having short iterations and retrospectives is to recognize the rocks and remove them. Summarized as "Go slower to go faster." But, management decides not to invest in removing the rocks because the software has to be done on schedule, but reality
Re: (Score:3)
met the original specifications
The key word here being "original" when discussing waterfall vs iterative development. Agile is not meant to deliver the original specification; it's meant to allow developers to adapt to a changing specification.
Unfortunately, it often requires the client to accept a product that was different from their original specification thanks to the dropping of features along the way.
Which is worse, not allowing a change in specifications because it puts the deadline in jeopardy or dropping some specifications to allow time for new specs that are more important to the customer to be implemented?
To me, meeting all the original specs is still failing if the end product can't be used by the customer.
Re: (Score:3)
Well, my take on it is that agile is not actually Agile.
ie, all the rubbish people do to pretend they're working in an agile way is just an excuse to do far less work and far more process. Just the opposite of what Agile is all about.
Alistair Cockburn said it in his Shu Ha Ri [cockburn.us] page - agile is about Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, tested software to the users every one or two months, and otherwise leave them alone
It is not about da
Re: (Score:3)
Agile is not failing because there is nothing to replace it. Are we going to go back to Waterfall?
Re:No. (Score:5, Informative)
There are more choices than just Agile and Waterfall.
Re: (Score:3)
There are more choices than just Agile and Waterfall.
I think Iterative and incremental development [wikipedia.org] is a good approach.
Re:No. (Score:5, Insightful)
Agile is failing in some areas, surviving in others. One snag is that Agile is a cult, pure and simple. If you vehemently disagree, then perhaps consider that you may be a cultist.
And the Agile cultists also believe there are only two world views: Agile versus Waterfall. Which is ridiculous, because the vast majority of developers use neither and instead have a hybrid approach from many different modesl including some ad-hoc methods. I know people who work as contractors who've said every single company they've been at use a different method, even those who claim to use Agile all use it in extremely different ways. When you are told essentially "do you really want to go back to Waterfall" then you know you're talking to a cultist.
Agile is pushed by its promoters as ideal for all types of projects. It does work well in some sorts of projects, where everything can be divided into tiny one or two week chunks, but it fails horribly where you need months of work for some features and lots of upfront design with large teams that need to coordinate. For example, taking an existing web design and maintaining it is easy with Agile, but designing an entire product from scratch, including hardware, software, and services will find Agile to be a frustration. What I have seen happen a lot is that there's a lot of old style design behind the scenes by the designers but then Agile is used up-front by the coders; each sprint picks out portions of the grand plan to work on, features are split into tiny two week slivers and so forth.
Don't forget the Agile industry here too. People whose high paying jobs are to teach Agile, to facilitate Agile, to be paid scrumm masters rather than developers, and so forth. I've seen no other development style that involves so many paid outsiders, most of whom are evangelists.
Of course there are good things with Agile but failing to acknowledge the bad things is not being objective.
Right now I'm on sprint number 10 for my feature. I get pressure to finish up the feature, but then at the same time there is pressure to stop working on it and instead deal with the unexpected emergencies. At the start I thought it was simpler than it really was and my design (which took longer than a sprint to think up) turned out to have flaws. It's embedded so the whole continual testing thing is extremely difficult, you can't put in unit tests when you don't even have enough memory to fit in the basics. And ideally, that two week sprint really should be 3 days of implementation only so that you have time for all the documentation, testing, handoff, training, integration, figuring out the obscure parts that come with no documentation, etc.
The ultimate thing that Agile is doing for me is making me work longer hours than I ever have in my life. That's the goal I think, it's why managers love it. Ie, I have to give a two week estimate of what I can get done. Now I feel personally responsible to get things done. The deadline is no longer an external deadline by people unfamiliar with what needs to be done but instead it is a self-imposed deadline. And self-imposed means I want to get it done so that I don't look foolish. Other people are waiting for it to be done so that they can do their part. If I do ask for more time I get glared at. And what happens now is that there is a deadline EVERY TWO WEEKS. It is ALWAYS crunch time! And there is still behind the scenes the high level deadline from the executives that can not slip.
Re:Is Agile Development a Failing Concept? (Score:5, Insightful)
No, it's just no longer selling as many books and consulting hours as it once did--so it's time to invent a new scam.
Re: Is Agile Development a Failing Concept? (Score:5, Insightful)
I'll dub thee DevOps
Re: (Score:3)
Nah - that one won't get as far - it usually requires that people prove their ability as both a sysadmin *and* as a developer (or at least as a member of a dev team). Most applicants choke hard on one or the other in the interview, and I'm not seeing a credible 'certification' yet that can paper over that deficiency.
Re: (Score:3)
That's it, exactly. You can use agile to weed out developers who can't think for themselves, who really are of no use in a development team anyway.
The methodology debate kind of misses the point. Agile is no silver bullet. A high-functioning team can be successful with agile, or with various other methodologies for that matter.
A dysfunctional team isn't going to succeed with agile, or with anything else.
Re: (Score:3)
So true. When we help an organization "go Agile" it is critical that the managers also use Agile and that they stick with it. But this doesn't mean exactly "by the book" since, for example, Scrum might not be the best approach for a management team. Kanban, OpenAgile, Crystal or other Agile methods or techniques might work better for any given team (including a management team). Long term success of Agile methods in an organization requires that management become Agile too.
Re: (Score:3)
Which is true. But here we are talking about tools, concepts and processes that are known to produce good results when used intelligently (or that should be known by anyone worth his/her salt in this industry.)
No, we have a process that is full of "no true scotsman" defenders who do no introspection on why the methodology has numerous notable failures beyond blaming everyone but themselves. And I say that as someone who does like many aspects of Agile, but it is far oversold on what it can offer by its true believer priests.
Re: (Score:3)
We effectively do without a scrum master. It can be done with an open and communicative team, so long as everyone recognizes the rules of the game and is willing to speak up to guide the process. Product owner buy-in is essential (and a scrum master IMHO an essential backup if the PM is fighting the system); they don't make the system work, but without good backlog management they can make the system break.
Our team succeeds at Agile more than anything else because our developers are respected by management.