Slashdot Mirror
Is Agile Development a Failing Concept?
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.
No.
Yes.
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.
SJW n. One who posts facts.
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.
Article is second link. First link is a BS dice write up
It is hard to take someone seriously when the argument seems to be 'my idea is brilliant! but most people are not good enough to implement it!' rather than 'hrm, maybe my idea is not the universal solution and one needs to fit the methodology to the requirements and resources involved?'
Sales / Management are on strict Waterfall and dev is on Agile
Until those concepts align in a company they will always be at odds with each other
Agile, done right, has been a game changer here. Yes, we had to let some of our developers go - the ones who couldn't actually think. We're better off for it.
There is no way to optimize the development process for software. Inserting terms such as "Agile" or "Waterfall" really just create bloat and waste time. The best software development process is to have no process and work in the way that fits you best. For instance when I write large software projects, I just start coding, I pick a place to start at and go. I wait until I have large testable blocks completed and then debug and integrate them. I don't follow and form of standard development process and yet have never been held up via a deadline of meeting request.
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.
IMHO, methodologies are a goo starting point, but none of them are ideal. If you don't tweak your methodology to suit your team when appropriate, you get what you deserve. If your team was working great before Joe had to pair program with John who has chronic halitosis, maybe you need to pair John with Jane who has no sense of smell. OTOH, if Jane isn't geared to work on that module and is an expert in some other domain, that's not a good idea either. Let John and Joe e-mail once in a while, and work in separate offices. Screw blindly following the methodology. Likewise, if all your SCRUMs devolve into 2 hour long water-cooler sessions, you could try to discipline it, or you could scrap the idea, or you could just have fewer meetings. Maybe you've got the skills to keep the meeting on track... maybe you don't. Etc., etc., etc.
Our development and project management groups (~ 50 people) moved from waterfall to scrum/agile 2 years ago. Since then, we have seen a significant increase in quality and velocity. It is also more comfortable for the devs on the teams because they know exactly what the PM process will be and what is expected. I don't know that Scrum/Agile is the best practice out there but in our case, it has brought increased productivity, higher product quality, less worry and overall comfort with all our processes.
Error reading device 'Signature'. (A)bort, (R)etry, (F)ail?
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.
New books to be written and sold, new training programs, new seminars. That's the reason there has to be a new methodology every decade.
Agile is great in theory and if you can get everyone involved to understand it then it's great in practice, too. The reason I say agile is a failing concept is because those of us in the industry understand it but are remarkably terrible at selling it to the non-technical people we need to have involved in order for our projects to be successful. What good Agile methodology really drives at is an effective amount of involvement from all parties -- customer, analyst, technical team, testers, operations, etc. Most businesses want to fire things at their IT department and then go off and do other things while the project is underway. This is clearly more conducive to the "waterfall" model (which we all know is terrible) and it prevents them from ever seeing and effective agile development implementation.
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.
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.
Helping with organizational effectiveness is our job.
Is Agile Development a Failing Concept?
No. It's just that people suck at doing quality work. People released shit when using procedural/modular programming. But that's people, not procedural/modular programming. Then OOP came, and people did more shit with it. But that's not on OOP, but on people.
I can say that with confidence because I know teams and companies that have delivered quality work using either any (or all) of these paradigms.
Same with processes. People have done good work with waterfall, and bad work with waterfall. Good work with spiral/iterative process, and bad work as well. Same with RAD, RUP, all flavors of agile, XP, Scrum, Kanban, etc.
It is people. It is organizations. A group of engineers that do good work with one reference process is very likely to do good work with most other processes, newer or older than the reference process by which they are currently being measured.
Newer processes are typically better than older ones when applied to general cases. Better as in helping ameliorate cost or increase delivery, or pretty much optimize some type of software development KPI. But that neither implies older methods are bad or that newer methods guarantee better deliveries.
It's never the tool, but the wielder. Give a process to a good engineer, and he will find a way to get things to work. Give any process to a code monkey, and you are just going to get a lot of shit flinging irregardless of the process of choice.
Yet another name for the same dog and pony show?
It's never the tool, but the wielder.
This is bullshit. Tools can be poorly made.
I think it's been dead for years. I think it's time we came up with a new buzzword acronym just to pad our resumes.
At least it works for what it actually does, which isn't what most people probably think it is for. What it does is offload the work of a manager on to a team. Spending developer time with co-ordination and extra information they don't need, tasks normally handled by a competent manager, allows a team without a manager, or with the far too common incompetent one, to still succeed. However if you're in the fortunate position of having a good manager, agile is a waste.
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.
It's never the tool, but the wielder. Give a process to a good engineer, and he will find a way to get things to work. Give any process to a code monkey, and you are just going to get a lot of shit flinging irregardless of the process of choice.
Good luck hammering nails with a hammer made out of plastic straws. And when you can't get it to work, it must have been your own fault not that of a bad tool.
Agile fails because it requires Management to think differently. Agile is either incorrectly deployed as a means for management to do even less, where they think "someone else" or the Agile framework will magically keep features and versions under control. Management fails to filter constant business requests into the proper versioning framework and bypasses it whenever the properly influential stakeholder wants an immediate change. Management in the stakeholders gets upset that one voice isn't completely "in charge". The whole thing devolves into a chaos of changes being lost or forgotten as priorities shift back and forth, goals shift and change drastically on a daily or even hourly basis, documentation never able to keep up, and the whole mess being blamed on the developers while all levels of Management cover their butts with "we're using Agile!" as some sort of ultimate excuse.
Agile is NOT chaos. Nor laziness. It requires "thinking" from ALL levels. INCLUDING all stakeholders. And it involves ALL checking egos at the door, as well as "seniority" or "priority" after step is approved. Not just a verbal buy in but actual behavior in following the ideal.
all the devs think or they wouldn't be decent devs. Management needs to follow along, and in organizations where they don't Agile fails badly. In organizations where they do, they're probably using some home grown system that looks a lot like Agile that produces the results they want.
Its just another tool in the toolbox to use. If it works where you work then no. If not then yes.
I've worked on agile teams that accomplished little more than completing the required checklists, and I've worked on agile teams that were very productive. It all depends on the skills of the scrum master and the product owner; of course the same could be said for any development process - good people can make it work, incompetent people will make it fail.
Sort of. This is a big part of it.
True. It's fine and ok for requirement to change. That's because requirements are usually a topic put off until after the product goes live. Do it, then design it, then start thinking about what the goal of the project is and what you might want the software to do.
Sort of.
False. You don't talk to business people until after you delivered the software. That's when you start working on the design. And as I mentioned, later on you'll start to get the business people to admit what the requirements are.
True! You have to be motived, nay, love the company (I really mean this) to do it. And the support is actually pretty good. I really like my workstation.
Probably true, but I'm not sure it's appropriate to be talking about efficient and effective in this context.
True.
WTF? No. This is completely and utterly false.
Nope.
Definitely a big gigantic no. Simplicity is something we say we want, but we always pick the most complex approach that we can imagine.
Maybe. I don't know.
No. Never, ever ever reflect on what has been working and what disasters could have been so effortlessly avoided. That would be ruinous.
It's never the tool, but the wielder. Give a process to a good engineer, and he will find a way to get things to work. Give any process to a code monkey, and you are just going to get a lot of shit flinging irregardless of the process of choice.
Then you haven't been in software development for very long or how little ability to discern a good tool from a bad one. Shitty tools are foisted upon software developers all the time in the form of buggy and/or poorly documented frameworks, databases, IDEs, etc.
or *have* little ability, that is.
I've seen plenty of Agile advocates in management positions absolutely hate it when they get stuck with their own process.
In fact every Agile manager I've worked with who has said: "We going to do this by the book", has in reality hated it when they get stuck with their own book.
The ones who have used it as a flexible framework and stuck with the spirit of the process, rather than the book have been very successful.
An example is making the entire team agree on what every story means rather than simply the manager/lead, developer working the story, product owner and QA.
I saw it with my own eyes too many times to tell.
Bad manager knows AGILE buzzwords and train wrecks a project by exercising 75% waterfall and the only part of agile that makes up the other 25% is the part where developers aren't provided shit and are expected to code, design, document, spec, and then turn around and explain it all two or three times to four or five people who heckle themselves as 'chickens'. Bad manager is rewarded as a pioneer and visionary while developers are branded as shy and slow (not to mention horrible attrition rate even facing above average pay and shares).
AGILE is fine. The world is full of bad managers though.
Agile as a concept has its merits, but the way it is implemented by corporate bean-counters is not at all what was intended.
"Agile" as it is "sold" to development groups is completely different than what is "expected" by management. To management, "Agile" is a way to push responsibility for scope creep and indecisiveness off onto development teams. It is also something management uses to try to "guess" what the customer is going to want, and then make sweeping, dramatic changes to scope as customer wants materialize, all without actually being responsible for the added cost, because that is blamed on R&D not "guessing" right.
If I were to boil it down to a sentence, I would say "Agile is a way for a company to reduce perceived risk by being neither a leader nor a follower in its space."
A company can and should do one of two things - it should develop products that follow the leader in a competitive space, or it should create its own competitive space where other companies follow it. One or the other. Both are risky, and Agile is an attempt to eliminate risk by eliminating the company.
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.
It must have been something you assimilated. . . .
As a system admin, I admire agile for the rapid proto-typing. Because as we all know, business users seldom know what they really want, but they all know what they don't like. However, I hate agile for being the universal excuse for turning project management into an exercise for "let's make it up as we go along", because then everyone expects me to work like that too. They don't want to acknowledge, let alone understand, that being a good system admin is about being organized and informed and having a more than 5 minute attention span.
Agile doesn't make a crappy team good.
An excellent team is good with or without Agile.
Too much effort is spent on methodology compared to construction of teams which work really well.
Usually, people just end up in a team. "Here's Steve, he starts today. Hi Steve!".
Setting up an excellent team is usually very hard, and take a lot of skill. I.e. it requires excellent leadership.
I've seen it once in 20 years, and fortunately, that time is now. I'm happy to go to work, despite crappy
customers, budget constraints, slow hardware. The people are awesome and make the best of it.
Agile Development: in which we pretend that not planning things is a good idea so long as we gather together and not plan for 15 minutes a day.
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.
Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
Totally agree- I am certified scrum master and most of the attempts I have seen at organizations being 'agile' have been atrocious.
love is just extroverted narcissism
The problem isn't that many programmers don't know how to use Agile methods. The problem is that many programmers don't know how to think critically.
If you have a terrible HR process that allows morons into your company, then no investment, no snappy buzzwords, not nothing is going to make them change how they fundamentally approach problems. By time you graduate college, 99% of people are already set in their ways, and within the first few years of working, the rest have.
It's like my Differential Equations 2 teacher in college said. "This is not the class to learn fundamentals of problem solving. If you've come this far and still haven't learned to solve problems, there's nothing I can do in this last semester to fix you."
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
It's a good article, but the pattern is an old one. Twenty (20) years ago, I wrote much the same thing about object-oriented technology. Since then, I've found that the same issues, the same pitfalls, pretty much apply to any new technology or methodology; here are some more generalized pitfalls (based on ones from the 1995 book) that I wrote up nearly a decade ago (2008):
-- Adopting a new technology or methodology for the wrong reason
-- Thinking a new technology or methodology comes for free
-- Thinking a new technology or methodology will solve all your problems
-- Betting the company on a given technology or methodology
-- Getting religious about the technology or methodology
-- Adopting a technology or methodology without well-defined objectives
-- Overselling the technology or methodology
These all apply to Agile -- but they also apply to just about every other 'silver bullet' technology or methodology that's come along. ..bruce..
Bruce F. Webster (brucefwebster.com)
The problem is Agile is fundamentally incompatible with the way most businesses are run. Top down command and control organization, blind adherence to process, lack of discipline / peer accountability, lack of team autonomy, etc will all create a disaster out of Agile. Blame corporate culture, not the person pointing out the inconvenient truth that "Hey, software is hard and I'm not arrogant enough to sit in a room and design everything upfront and pretend here at the beginning of the project when I have the least amount of information over the problem that half of my decisions are going to be right."
https://xkcd.com/927/
Agile has a good idea: that at any moment in time the project should have a working version ready to deploy.
Any programmer worth his salt has worked this way without some consultant training him/her/it into that.
And then come the part that any programmer worth his salt loves: pointless meetings. Daily.
Note that those 17 programmers met to TALK about programming, not DO programming...
That's what Andy says as well:
When you are first learning a new skill—a new programming language, or a new technique, or a new development method—you do not yet have the experience, mental models, or ability to handle an abstract concept such as “inspect and adapt.” Those abilities are only present in practitioners with much more experience, at higher skill levels (see my article Why Johnny Can't be Agile for more).
I agree though I'll put it more bluntly. Most programmers, for all their alleged smarts, are drones. They can crap out code with varying degrees of ability if you tell them what you want in painstaking detail but they can not think and have no understanding of the bigger picture, in terms of the business, the market, and so forth. Some programmers grow out of this as they gain experience and mature into software engineers. A lot, a hell of a lot, don't.
(This would be a whole lot less irritating if most of them didn't act as if they were God's gift to coding.)
I've done some form of agile for the last decade. Participated in/led/struggled for/struggled against, the whole bit. The real problem with agile is that it only works when the sales force sells an agile service rather than traditional products. That means devs talk to customers. Live with it. And, if you're not doing that, then (a) it's not agile, it's a mess of broken expectations, and (b) it's probably not working. The real problem, frankly, is that most of the time customers do not want to talk to devs. They do not want you to craft their own special little diamond. They just want a fucking usable product so they can get on with their fucking business.
Sorry, I've just lived in the developers' gap between sales and management for a little too long. The bottom line is that MANAGMENT, SALES and DEVELOPMENT ALL need to be doing what the CUSTOMER WANTS.
Process exists, but focusing on it is a mistake that people just can't seem to stop making.
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.
In the correct application, it can be a miracle. Misapplied it does nothing, or worse kills the patient. I've seen it misapplied many times.
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.
Do you even measure "quality and velocity", let alone "increased productivity"? Do you control for confounding variables? I bet the answer to all of that is "no". For all you know it might be hurting all those metrics, but you feel good about yourselves because you do "stand up meetings" every day and talk about how you couldn't get anything done the day before, but today you will definitely be able to do it.
Places I've worked agile has been dumbed down to aggressive stupidity and seen as synonymous with scrum. It is very good at being business driven and very bad at technical excellence. On the positive side the blame game is faster at assigning responsibility for issues because it is easier to see the cookie crumbling but the usual investigation process is more or less survivor style voting card games. It is essentially bureaucratic with a scrum master as political commissar. Like many 'new' methodologies it is a factory management system which assumes all individuals are replaceable and have no special talents which can be balanced in a team. It is millitary in origin and assumes teams of highly trained functional specialists. There are many fundamental differences between military and civilian life and this is one reason it fails on some levels. It is able to extract a lot of additional value for the business but at a high cost to many human values. When it is working well I have never seen so many people unhappy with and at their daily work.
My experience for most of these development methods and problems almost always comes back to requirements gathering. People typically want to jump on what ever solution they seize on or what is being asked of them instead of taking the time to truly understand the problem space and only then designing their solution. Often your Customer has no idea how a software implementation will change their work so I have watched agile being the blind leading the blind a lot. Rapid iteration is good, but to be successful in the end it requires an upfront understanding of the domain, thinking, and how it might change with different solutions.
...uses Agile.
not some subproject of a subproject, but a real project.
AFAIK no such thing exists, but if it did it could be analysed.
Frankly every time I down load a project I don't see any unit tests for examples. Code is written by one person.
I consider Agile a major failure, not in that it was a bad failure, but it took up all the oxygen from other iterative processes like RUP, and has reduced the progress of design overall.
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.
It's never the tool, but the wielder.
This is bullshit. Tools can be poorly made.
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.)
The context should have been apparent, but I guess we needed to go Barney Style with it.
I actually could not care less about "pure" agile.
It will never work at my company (Japanese).
Waterfall has been a huge, corn-studded, three-curl steamer. FAIL, in big red letters.
We need to do something different.
I'm working on that.
No silver bullets, here. "Pure" agile has a fart's chance in a tornado of ever making it in my company.
If anyone has ever worked with Japanese engineers, then they know all about Process (note the capital "P," for it is a HOLY WORD).
Ironically, many of the practices that agile claims as its own started in Japanese companies, like Toyota.
I'm in the process of hammering out a new process that allows project tracking without introducing a lot of overhead (instilling coding best practices and a lot of DevOps automation), scales to match team size (small teams should have less overhead, large teams require it), and fast projects.
Lot of work.
LOT of work. What's out there now won't fit the bill. I'll need to build a lot of this as I go along, and expect to encounter lots of fail on the way.
I have no intention of publishing or blogging it (in fact, I'd probably get fired if I did).
I'm keeping my fingers crossed, and my sleeves rolled up...
Once more unto the breach...
What if the straws are melted down into a hardened composite? (ducks)
I am very small, utmostly microscopic.
It's never the tool, but the wielder. Give a process to a good engineer, and he will find a way to get things to work. Give any process to a code monkey, and you are just going to get a lot of shit flinging irregardless of the process of choice.
Good luck hammering nails with a hammer made out of plastic straws. And when you can't get it to work, it must have been your own fault not that of a bad tool.
Why would you use a hammer made out of plastic straws? What is the use of that tool? What is the purpose? What is the context? These are obviously rhetorical questions used to highlight the stupidity of your counter example.
For that matter, why don't you go and say "good luck hammering nails with a bar of soap, a saw, or a roll of toilet paper"?
All of these concepts are bullshit.
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.
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.
Agile means: Completely loosing the big picture, allowing people to write code without knowing what the scope is they are doing it in. It also means: If something is too big to fit in a scrum sprint, you have to split it up in pieces which will not be scheduled in adjacent sprints because of -wheee Agile- higher priority stuff. Which means the pieces might easily go to different teams, or the second half might not be executed in the near future at all. It also means, if something requires more than a sprint to do, it will never be properly finished, so you better not start it. Agile is nice if everyone has the same knowledge about your project. Which means it is a small project for which Agile is completely over the top or you don't have any specialists -correction- you ignore the fact that each human being has his own areas of interest, areas of specialisation and capabilities.
Why would you use a hammer made out of plastic straws?
Why wouldn't I? You've proclaimed that every tool is perfect and it's only the user that is at fault when it doesn't work.
Which is true.
Can't be possible. Your original claim was pretty adamant that all issues are the fault of user and to quote you "it's never the tool". If a tool is poorly-made then it means that it is not the fault of the wielder if they can't get the job done using a faulty tool.
There is no one methodology that works for everyone. Usually the purest form of any of the major concepts is fundamentally flawed in that in general you will not get what you want with Waterfall, you will never have a finished product, or even know the feature set for the next iteration in a pure Agile development.
What you need to do is look at the work you are doing and borrow from the main two, and any other, methodologies to come up with what works for your group for the type of software you are developing.
I have been in a group where the Waterfall with added iterations worked really well. We were working on embedded office automation controllers.
I have been in a group where we were making a tourism web site and a more Agile approach of faster iterations and showing the customer was more appropriate
I say Agile is a failed concept, because all the concepts are failed. You just need to take from them what is appropriate and modify it if things don't work, or the nature of the work changes.
Microsoft, Apple, Google, Amazon what's the difference? All steal money from devs and control with walled gardens.
It can't fail cause all of the critics are doing it wrong.
Why would you use a hammer made out of plastic straws?
Why wouldn't I? You've proclaimed that every tool is perfect and it's only the user that is at fault when it doesn't work.
I didn't say every tool is perfect. I said that every tool has a function, has a context, and that works in that context. But hey, I guess I have to go Barney Style in these realms.
It's never the tool, but the wielder. Give a process to a good engineer, and he will find a way to get things to work. Give any process to a code monkey, and you are just going to get a lot of shit flinging irregardless of the process of choice.
Then you haven't been in software development for very long or how little ability to discern a good tool from a bad one. Shitty tools are foisted upon software developers all the time in the form of buggy and/or poorly documented frameworks, databases, IDEs, etc.
Been in this business for 20 years, 9 different companies in various industries, doing application and system/embedded development. But whatever. If you want to play my lightsaber is bigger than yours, by all means, knock yourself out, you win.
We are obviously talking about processes in general. But if we want to talk about shitty IDEs, languages and coding-level artifacts, let's do it. Yes, there are shitty IDEs, bad languages and such. They make work difficult, if not painfully insane, but none of that stop good workers from delivering good work (or at least avoid the number of sophomoric WTFs from piling up.)
Back in 1994, I once had the disgrace of having to do support report generating programs on PICK systems, using nothing but ed (not even vi for ${DEITY:-FSM} sake), using a bastardized language that mixed sh-based constructs with SQL-like statements for multi-column databases and PICKBasic.
That last thing, PICK Basic, utter crap that made GW-BASIC look like Haskell. At least GW-BASIC supported named labels for your GOTOs. PICK Basic oth only supported numeric labels. Imagine that if you can. You can have named labels in most assembly languages, but not in PICK Basic. Wrap your head around that if you can.
Anyways, the existing programs were a monstrosity we inherited were a monstrosity. We started fixing that by establishing standards and procedures for creating new programs (or introducing changes in new ones). We established a hierarchy of numeric labels - labels in the 1000-1999 range for initialization, 2000-2999, 3000-3999 for general computation, 4000-4999 for reporting/output and 5000+ for error handling and abnormal termination.
Those are the tools we had for that specific job, and as ugly as they were, we found ways to deal with them, to increase value for our employer while minimizing the number of WTFs that had been piling up for years by incompetent code monkeys.
There is no question in my mind that PICK systems were pure crap because they required us to put significantly more attention to detail to avoid introducing WTFs. Thank God that was just one job I had to do, and that I have never had to deal with that ever since.
And I've experience deja-vu moments like that, in Java, Visual Basic, C/C++, FoxPro, you name it. There is no language or IDE out there that does not have some unbelievable collection of WTFs.
But none of them cause people to unavoidably fuck it up again and again and again. Wielder, not tool.
When we had our choice to pick, we try to pick the best tools we can get.
But more often than not, we do not. And when that happens, what do you do? Do you go on auto-pilot and let the tool WTFquery imbue themselves into WTFs in your own code?
No. Not at all. You use your skills and find ways to make that shit work, to put some structure, some standards, some sane mechanisms and patterns and practices to maintain some quality in your work.
It can be done. Actually, it is done, and it has been done. Wielder, not tool. Always.
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.
There have been many in the industry, and no doubt there will be many more. Agile is now beginning to enter the final phase of its existence, to be replaced by the next fad, whatever that will be.
Bad developers will do poor development with or without Agile. For good developers to do poor development, that takes Agile.
We don't deserve such a great system as you've given us. Please accept our humble devotion and apologies. We promise to be more agile in the future!
No, you said and I quote: "It It's never the tool, but the wielder". This statement could only be true in a world in which every tool is perfect.
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.
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 the quarter. On our team the compromise is doing some one quarter rough-grooming and having our engineering team manager (who was a team member before being promoted) flesh out the more distant epic level grooming with our PM.
Let us live so that when we come to die, even the undertaker will be sorry -- Mark Twain
From my experience, Agile works really well when you or your manager can define "mini projects" that are completed within 1-2 days. Yet, if you are slow and such projects take 1-2 weeks, it doesn't work as well.
From this perspective, the best Agile teams should have several super fast developers who would interact on such development every morning and keep the good speed of going forward.
Agile works cheaply for software which is a relative island onto itself; facebook, google stuff, etc - where you have to meet a standard for a web client, but where otherwise you can publish API versions and allow people to continue to use previous versions, but that nothing is really built /on/ your product. It works horribly for anything which has to work with anything else which might change (yes, standards change....slowly). Operating systems, libraries, etc - when a core principle is to ignore documentation or any group other than the engineers themselves (including clients) then yeah - works well for islands, not things which are parts to a larger puzzle.
To me the biggest risk in any product is not getting the right product out. Quality comes second. Iterating rapidly allows you to get to the right product. The impact on quality that comes from not having enough time to think through design, code and test, in theory, could be compensated for by "smarts". To the extent Agile helps iterate to get to the right product it is valuable. The specific mechanics of it are not "nature laws" and hence should and must be changed by smart people to see if it fits their purpose.
Developper not doing proper testing simply doing only unit test and some very limited automated test , then not expanding automated test because there is no time, and then no real business test (integration). And then in the end stuff not working with a simple test. And don#t get me on the doc never updated or written because hey code is self explanatory (yeah tell that to the client or the specificator or when somebody want to test or understand the implementation like end user).
Nm
"agile team lead themselves". We tried that. Gave outline. And the agile developer used that to explain them being much slower than estimated because the spec are not deep detailed enough. And then test were dropped in favor of coding. Yeah sure. Excuse are invented to be used. Too much micromanagement. not enough micromanagement. So yeah. You'll excuse me if I see I am skeptical.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
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?
If you want to do it semi-scientifically, then test a given methodology for at least 7 years on actual projects for multiple project and organization types.
Why is it methodologies start spreading before being properly field tested? It appears to be hypsters jumping the gun in order to get rich selling hype (books, training, & consulting), but I'm open to other explanations.
Table-ized A.I.
I made enough money with agile, its caught on and I can't make money anymore.
Look at that shine! Use GROWS and you too can look like me! Ka-chow!
like waterfall.
on a project burning a million a year between various team, we had a successful delivery 2 months ago. Its a large DW BI project with tons of data.
The fact is that a good team will deliver with Agile or Waterfall.
Been a developer for 15+ years, the problem I have seen with Agile is that hip shops pick it up. Kids are out of college and that contributes to failure than Agile it self. The mentality, "Its cool to be agile, who wants to do waterfalls, thats what my dad did".
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.
Agile is a fine way of implementing a design and a really, really bad way of designing anything. Agile will move you inexorably to a fixed objective, but run you right off the rails if the objective wavers even a little.
It works because it forces developers meet regularly, track progress, discuss problems, pay attention to requirements, be aware of the schedule and what everyone else is doing, The rest is theology, more or less.
Please do not read this sig. Thank you.
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.
"First they came for the slanderers and i said nothing."
Agile probably fails because it is the next Management Buzzword that somebody heard somewhere. Then try to use it, because it is the new best thing.
Like anything, it likely has it's place and time, probably mostly dependent on size and type of project being worked on. Having it misapplied because Management thinks it is a swell idea, then having people just try to make it work because they have to, well it might work, but if you are trying to fit a square peg into a round hole it may be difficult not to fail.
From what I have read, for small to medium sized project Agile can work quite well. However once you get to the large and gargantuan size projects it starts running into some fundamental problems. Sure you might be able to break it down into smaller projects, but that is not always reasonable or makes sense, or then you are adjusting requirements simply to fit your development process. Also those pieces need to be able to work together in a seamless and coordinated way, which requires some higher level planning...
Anyway when I hear about a very large system being done in an Agile manner, the first thing I think of is, enjoy that incomprehensible pile of garbage that is going to be the result unless you are very careful.
I think some like it for infinite job security, as you will just be constantly going back over and redoing and readjusting things for that application forever just to keep it limping along and running like some Quasimodo. Though in this example, perhaps Frankenstein might be a more apt analogy where you are trying to take a bunch of badly related pieces and building a single system out of it, zapping it with lightning and hoping for the best... The result? Fire and Mobs... Fire and Mobs...
You can theoretically hammer nails with a saw. :)
All this discussion from Pro-Agile folks--ya'll make waterfall sound like it was really:
waterfall@aol.com
Just saying.
I'm seeing posts from people saying things like, "Agile isn't working for my team, I just spent my whole daily standup reading this thread" or, "I get a lot of work done during my retrospectives". Of course agile sucks for these people! Agile will get limited—but still useful—results when the team has this attitude.
But if they have a different mindset where they actually try during the daily standup or retrospective, it works so much better.
Look, every really good developer I've worked with has had good opinions and ideas about how the project should be run. When they spend the entire standup or retrospective looking at on their phones, the team doesn't get the benefit of those opinions and ideas. But when they use the meeting to actually share those ideas, and maybe even engage in a good discussion (or even argue for them!) with the rest of the team, the whole project benefits. But that only works if they care about doing a good job with the standup or the retrospective the way they care about doing a good job with their code.
I'm plugging my book, Learning Agile, now. I hope you don't mod me down too much for that. But I think we did a pretty good job arguing this point in the first few pages the first chapter. You can read the first chapter for free [PDF].
Building Better Software
" 'Agile methods ask practitioners to think, and frankly, that's a hard sell,' "
It seems to me that if Agile works so long as practitioners are willing to "think" that it might be most profitable to just fire the ones who aren't adaptable enough -- or not hire them to begin with?
I've been through four different methodologies and all of them have good parts, its more about understanding what applies to the project you are on.
Delivering a website, VS. delivering a desktop application.
Delivering software for the International Space Station VS. delivering software for a phone app.
Delivering a 1.0v/2.0v of a product VS. delivering 1.0v+/2.0v+ of a product.
I find agile is better suited for post-1.0 product deliveries of a Django website, rather than initial development on a C++ application for a mission critical system. I find it bizarre that it becomes a buzzword and so it gets used on every project under the sun. I tend to like fresh (1.0) software development on more critical apps, which allow for more design and proof before hard-core development happens, and so I tend not to like Agile in general, and wish it would just go away. Agile is at odds with Lean start-up mentality, and I hope that encourages a trend away from Agile or at least a rethink of its usefulness. (Read the original waterfall papers, and you'll see that agile is really just a dumbed down waterfall).
The best thing to do is find the (custom) process that's best suited for the project you are on at the current point in time, and forget about what's currently the hot buzzword.
Waterfall is a straw man. It only continues to be mentioned because it is an easy target. Claims that X is better than waterfall are a waste of time; they tell us nothing about whether X is actually effective.
which falls under the Agile umbrella. Oh wait....
The origin of agile and scrum (and the use of rugby as a metaphore) is "The Knowledge Creating Company" by prof Nonaka and Takeuchi. When you read that book, you realize that Scrum as it is practised today, in nothing resembles the ideas of Nonaka and Takeuchi. So, my answer is "yes". Even the scrum metaphore is wrong: the book uses team play in rugby as an example. Scrum is not team play and agile, it's standing still.
no, I don't have a sig
Agile works for many teams or projects, but Scrum only works for some.
Agile has received a bad name due to real-world implementations: The real-world implementation of an agile project philosophy is often done via Scrum, which is a very strict and prescriptive process. There are others, but Scrum is the most popular one. Scrum doesn't work for all organizations and projects, though! Shoe-horning unsuitable teams and projects into the Scrum process can lead to lots of problems and disillusionment with Agile, even though it wasn't really Agile's fault in that case.
It's a bit like how Socialism gets a bad name from the (totally failed) real-world 'implementations', such as what we've seen in the Soviet Union or East Germany, even though the theoretical ideas of Socialism may actually offer some good points. The "agile" (lower case) aspects of "Agile" (upper case) are quite good, so it's worth to see if you may be able to adopt some of them.
If you are interested in a less prescriptive and much more flexible approach to Agile, may I recommend you have a look at Kanban? It starts by just watching how you do things now and then can be used to slowly add a few processes here and there to strengthen the good things and reduce the bad things in your process. Especially large, established organizations can benefit greatly from that.
Unlike other methods (and I'm strechting the term "method" here), agile methods rely on excellent optimised and product oriented software production pipelines. This is how you should do it anyway, agile or not. But in my experience roughly 1 in 20 software shops implement even the flakiest of standardised production. Most of the time you still have to explain to people why they should use versioning.
The decision makers, sales people and IT strategists also usually have a very hard time commiting to a product and produktion pipeline. They want to sell whatever goes and have the devs sort it out, understaffed, ill-equipped and with extra weekends.
There are a few companies that have sales and technology and perhaps even industrial design/user experience all on par (Apple for example), but most companies that offer software development have no decision makers that understand even the faintest about software development.
Agile methods such as Scrum are the ones that expose the fastest wether you actually are doing professional development or if your crew is just a bunch of people faking it with poor gouvernment, bad organsiation and a sales and production team that don't communicate professionally with each other. IT mostly is a second and third afterthought with most companies and in such environments the best method won't improve development, no matter what.
If a PM can't tell a client from a server or Java from JavaScript and couldn't be bothered to understand why it is important to make a call and a final decision about tabs or spaces Agile will show how shitty your environment is in an instant. Waterfall (i.e. we don't know what we're doing but we're doing it anyway) will disguise that indefinitely, because there's no fixed model for accountability built in.
Bottom line: Until IT stops being the cellar child of the company no method in the world will professionalise development as it is desperately needed. We're still like medicine in the 16th century in that regard.
We suffer more in our imagination than in reality. - Seneca
http://programming-motherfucker.com/
Left MS Windows for Linux Mint and never looked back!
Vote for Bernie in 2016!
Agile fails because horrible management wants an "Agile" work environment but still get involved and want the overhead of a waterfall project.
You cannot possibly have both, and until they understand that it will continue to fail.
The largest Agile shops in the world that are successful always give their employees the latitude to self-manage the project and their customers work with the product owner to create a proper backlog. The Agile environments I've worked in have gone something like this:
0) An idea is had, a pitch is thrown, and, it is decided a project will be introduced that promises to completely revolutionise the way we do business.
1) Create the entire project during initiation, including complete system architecture. Ensure that modularity is not in any part of the system.
2) Begin the project, working on the disperse parts that will all end at the same time at the end of the project.
3) At 70% of the way through, the managers will then have to come in and start complaining about how their commissioned design has not been followed properly and if it had, the system would be up and running by now. Manager starts complaining about the architecture and how the developers screwed it up and now they need to implement modularity.
4) A few months after schedule, the developers are barely able to pull together the original system as they had to write in a few different "modules" to get functionality working that broke other parts of the application.
5) Users being actually using the product, complaining, and, whinging.
6) Managers deflect fault onto others.
7) ???
8) A year later, a new Agile project will be introduced that promises to completely revolutionise the way we do business.
Also, anyone that attempts to implement a third-party piece of enterprise software is doomed to failure if they attempt it using an "Agile" project.
I am not a big fan of "Agile" development. To me, it sounds like dropping important parts of the development process in order to churn out more lines of code per minute. Of course every group has their own best methods of dealing with the development process. Having "agile" in the name certainly implies that it's superior to the old, stodgy, "inflexible" methods. Of course developers are happy, because they don't have to do those parts that were dropped. And management is happy, because they are "producing code faster" and buzzword compliant.
Now, I had the displeasure of working for a company that attempted to adopt "agile" development practices.* Not long after I started, I told them I wouldn't do that any more, and they stopped. It may be just that they were implementing things incorrectly, though, so I looked at Wikipedia to find out more.
The "waterfall" method as described in Wikipedia is just a straw man. The only company that would implement a completely inflexible process where separate groups implement each step in isolation is a completely management-heavy company that would be painful to work at for any position. There is always feedback between processes. The "V" method is probably the most common method of implementing "waterfall". Just because it got its own name doesn't mean that it isn't what's meant when people (who are not "agile" proponents) say "waterfall".
Here's the Agile Manefesto, with commentary by me:
> We are uncovering better ways of developing software by doing it and
> helping others do it. Through this work we have come to value:
> Individuals and interactions over processes and tools
Processes and tools empower individuals to get their jobs done without uncertainty and with great efficiency. Also, many agile shops insist on using certain methods that require certain tools (e.g. Rational Rose, Microsoft Visual Studio), so this is clearly not a shared value.
Valuing individuals is good. The proper way to do this is to adjust the processes and tools to meet the needs of the individuals, rather than dictacting what sounds best to everyone without feedback.
Wikipedia provides elaborations:
>> ... self-organization and motivation are important, as are
>> interactions like co-location and pair programming.
What does this even mean? Are you saying non-"agile" methods do not encourage self-organization and motivation? Motivation in particular is completely dependent on the individual. Agile methods do not motivate me, for example. Self-organization sounds a lot like "we have no clue how to manage this, so we'll rely on you to, even though you probably have no clue, either". ISO 9001 compliance, which was popular for a time, requires that every task an indivdual performs be written down. This prevents management from inventing new tasks outside of the employees scope, helps orient new employees, and when it comes time for status reporting and performance reviews, it gives the employee a reference against which to evaluate. Self-organization can be part of that, by not forcing procedures that dictate organization, but I don't see a lot of that coming from the "agile" programming folks. Instead, a new set of rules is forced on people, claiming that they are somehow superior.
Co-location is fine, and saves money for the company. However, it's missing an important point: we have the technology to stay in touch regardless of physical distance. Email is sufficient for most communication, and chat protocols allow more real-time interaction. It's not hard. It helps people who don't like live meetings, it allows people to work from home, and it allows blind and deaf people to communicate as equals (although maybe not so much blind people when other people start drawing diagrams). It's also easier to retain a record of the discussion. It also helps prevent common communicable diseases, such as the cold and flu. Of course video conferencing provides some of thes
well no most coders are rather clumsy. Look I don't have time for morning snuggles or can can boards.. Don't force nerds to talk about their code, omg we're trying to avoid that. Just show me who to beat the specs out of and let's program, muffukas
There are more choices than just Agile and Waterfall.
Care to recommend other suitable alternatives that can tackle the complexity of big projects?
Thanks!
So the argument is "the methodology is perfect, it's the people that are failing". Just like "waterfall is perfect, it's the people that are failing". Accept that "agile" has some good stuff and some stuff that doesn't work, applies in some cases and not in others. Take some good stuff from it, and move on.
People taking part in agile development just needs to synergize and refactor their b2b b2c ROI scrum before they close the loop by getting more eyeballs on the strategy.
All of the techniques of which Agile is composed exist independently. They can be usefully applied by themselves. Furthermore, there are techniques which don't exist within the Agile definition which can also be useful. Developing a broad, integrative understanding of the range of management, workflow and development techniques available is critical. Ideally, that knowledge is held by "the boss", whoever that is. It could be a project manager, a product owner, a software team lead. Whoever has the capability to drive change will be the person to drive change; whoever has the capability to push process compliance will do so.
That capability comes from a mix of organisational authority; knowledge-based authority; people-manangement skills; problem-solving ability and a broad range of ideas. What's important is that the key nexus points in the informal org chart have the knowledge of how to get work done.
That's the challenge. It's not standardisation on a narrowly-defined, specific set of processes and terminology.
Agile isn't dying, because it's a great starting point. It allows managers and leaders at around about the competence / proficiency stage of the Dreyfus model of skill acquisition to present a model for their team to follow. However, there are many levels above it.
In my opinion, there will forever be a constant cacophony of stress, challenge, failure, success and rework in our attempts to deliver software, based on the skill acquisition points of the whole team.
In my first encounter with Agile back in 2001, our management decided to follow Scrum.
We did the daily meetings, of course. Then we divided our project into sprints:
Sprint 1: Design
Sprint 2: Coding
Sprint 3: Debug
Sprint 4: QA
Sprint 5: Release
Needless to say, it didn't work out too well. Since then, I've seen agile done a lot of ways, some worked, some did not. Frankly, most waterfall proponents simply don't get Agile. Managers who DO get agile are able to deliver far better quality, in far less time, than any waterfall model.
Firstly, criticism does not mean failure- it means things can be improved, which is part of being agile...
I'm a big fan of Agile. In a team of intelligent, talented, motivated developers and managers who trust each other it can be fantastic. Sadly, once it got a label, people tried to codify it. Then they started following processes and ignored one of the tenets of the Agile Manifesto - People before processes. That's when it started to go wrong.
My team tried Scrum, it didn't work. Rather than give up (or keep plowing on), we looked at why and decided to give Kanban a go. It worked, mostly. Where it didn't, we tweaked it. As the team grew in size we did more tweaking.
One of the most important things we do is to bring up any issues in our retrospective - if something isn't quite right we try to fix it. We criticize our process. Sometimes managers do it, sometimes devs. We talk, we trust each other. All in all it works pretty well.
The problem is not with Agile, but with people who believe in magic potions.
Nothing in this world ever solves all problems. Nothing in this world ever fits everyone. Agile is no exception. It might be good or bad, depending on circumstances such as your team, your culture, your project and a dozen more.
The best you can do as a leader (manager, lead dev, CTO, whatever) is to pick and choose and come up with a system that works for your company, your people. It might be Agile, or Agile with something else mixed in or something else with some Agile mixed in, or no Agile at all. It depends.
If you believe you can take something that someone else cooked up without knowing your situation, and just apply it by the book and that's it, then you are not doing your job.
Assorted stuff I do sometimes: Lemuria.org
We've gone full circle! Something that promised to improve *everything* has been badly applied for a decade or so, and now it's considered failed.
Go figure.
"the Agile Manifesto, the product of 17 software developers coming together in 2001 to talk over development methods."
So they figured it all out for the rest of us devs. Awesome! Works for everything!!!
The major takeaway in Agile is to develop software in an incremental fashion. Now here's the kicker: that methodology was well understood for 30 years before the Agile Manifesto was even published.
Incremental Development is spirituality. Agile is religion. You don't need the latter to achieve the former.
I have worked as a developer in many environments using both Agile and Waterfall methodologies. Many of these organizations have claimed to be Agile but cling to some Waterfall practices and so are not true Agile. Of all the environments claiming to be Agile, the common denominator I have seen that makes them not true Agile is that Management has not bought into it entirely. When this happens it is only "Agile-like". In order to be true Agile, Management has to have bought into it completely. Typically Management will say they support it entirely yet when a product is not going to be completed by a particular date they do not behave in an Agile manner; by either changing the date or by dropping features as appropriate. True Agile also requires there to be a product owner. The product owner's job is to have full power to make product decisions. Many of the Agile shops I have worked in have a product owner, but they do not have the power to make any product decisions or they are product owners of too many products concurrently and tend to end up unavailable when it matters most. These are the primary reasons I see Agile fail.
The three minutes standup
Manager: (looks at Dev 2) Kanban board says you moved Blah task to done yesterday and pulled in foo task today.
Dev 1: Yes.
Manager: Good work. Need anything from me or the team.
Dev 1: No
Manager: (looks at Dev 2) Kanban board says you moved Oober1 task to done yesterday and pulled in Gobblygook task today.
Kanban board says you moved blah task to done yesterday and pulled in foo task today.
Dev 2: Yes.
Manager: Need anything from me or the team.
Dev 2: Yes, I need help from Dev 1 to do Gobblygook.
Manager: (looks at Dev 1) Dev 1, can you talk to Dev 2 about gobblygook after standup.
Dev 1: Yes
Manager: (looks at Dev 3) Kanban board says you moved Whatsit task to done yesterday and pulled in WrongWork task today.
Dev 3: Oops. Yes, I finished Whatsit yesteday, but I pulled in the wrong story. I am working on RightWork.
Manager: Fix the Kanban board mistake. Need anything from me or the team on RightWork.
Dev 3: Nope
Manager: (Looks at Tester) Kanban board says you finished tests for oober1 and you are working on testing Blah.
Tester: Yes, there was one bug, I verbally told Dev 2, he fixed it. I retested an now all tests pass. I am testing Blah now.
Manager: Good work.Need anything from me or the team.
Tester: I'll maybe need to speek to Dev 1 about Blah sometime after lunch.
Manager: Great job team. Keep up the good work.
Stand up ends.
Agile development in the more pure form such as XP is doing just fine where I see it being used. But the management/certification/terminology/paid courses version of Agile should be taken out behind the woodshed and shot. Basically when I hear a company has SCRUM masters then I add it to the dead pool of tech companies that my friends and I bet chocolate bars on. I have a long list of these sort of silver bullets that can claim to turn shitty programming teams into productive machines. Six Sigma would be another pet peeve.
I am partial though to some parts of the PMI PMBOK type stuff but some care needs to be taken distinguishing between certification and ability. At least half of managing people is being a people person.
But to me agile seems to be mostly adopted by really really shitty programmers who aspire to management so as to cover up their complete inability to get anything done. Also many Agile people tend to use the guise of agile to ram their shitty programming style down everyone's throat as some kind best practice. People who like ++i or have insane commenting styles.
All AGILE does is allow a PM or architect the ability to terrorize the development process with useless process. All 4 week sprints do, is burn your developers out. On current project that uses AGILE, most engineers last about 7 months and quit, or move to another project. AGILE just plain sucks.
So, there's a brilliant programmer or programmers who can and do create and negotiate their own path by constantly juggling the requirements, the current state of the project, the gap between where it is and where it wants to be, within their heads at all times, while keeping the code clean and readable. And you want to convert your organization from reliance on one or a group of these talented programmers, so that you'd have to quit the business if anything happened to them, into one where the talents and knowledge and wisdom and good habits and skills and styles and diligence are all built into the processes so that mediocre programmers can do good work by just adhering to processes; and good programmers will find these processes are in accord with what they're doing anyway and not be hindered. Ha! Welcome to the dilemma of every organization, ever; making the leap from a bunch of talented people pooling their talents into an organization where the talent is built into the structure/function of the organization. If 5% organizations make the leap successfully, I'll be surprised.
Star Trek transporters are just 3d printers.
After reading some of the comments about how Agile is being done elsewhere, I'm pretty pleased with how well it's going where I work. I do wonder why the difference, though.
Standups are 15 minutes (officially) but went longer because we had two scrum teams (called "pods", which name no longer irritates me) working on a project that affected both. We needed the expertise and the resources.
We don't spend a lot of time on backlog grooming, in part because we don't have to split many of our user stories. Things were pretty well broken-down into manageable size when we laid out our work, up front. (Somewhat waterfall-ish, but it has worked out OK.)
Another reason is we have a separate meeting (which we call a "champion meeting" for some reason) where a subset of the whole team identifies uncertainties and determines things that were TBD, if they have to be before the user story can be sized. User stories normally are sized at that time.
We used to use "planning poker" cards, but now people are comfortable singing out their estimates or doubts about the estimates of others, and working to a consensus. If we can't come to a consensus, we'll go with the higher of point estimates.
Teams are small, 5 or 6. (Except for our duo-Pod team, during that project.) About half our people are in St. Louis, the other half are contractors in India. Almost always a St. Louis QA tests what a St. Louis Dev produced, and an India QA tests what an India Dev produced. One BA/scrummaster for the team. (Two, during the duo-Pod project.) Only St. Louis folks attend the "champion meeting", but all attend the daily standup and a weekly coordination meeting (at the end of the India day and the start of the St. Louis day).
Much of the above applies all Pods, some only to the the duo-Pod team, which is breaking up now. Next week, some are going half-time on the duo-Pod work, and then it's just going to be one of the pods.
We've not been slavish in following Agile rules, or our own. The "champion meeting" was added a few months back. And with the end of the duo-Pod, we'll no doubt have to make more changes. We've already started on that.
Why has it gone so well? A couple explanations.
Management had a strong commitment to it, and for the most part hasn't micromanaged it, or even come close. All pods are now on 2-week sprints, and are synchronized, with a 6-2-1 at the end of each quarter. Initially we had a requirement to maintain a somewhat even velocity. If the points accomplished per sprint weren't sufficiently consistent over time, we got "dinged". Now we have to commit to calendar dates for big chunks of functionality, instead, but we get to choose our commitments. (We can't be silly about it, of course.)
We got some training, pretty much from the get-go. Some general Agile training initially, and when we were ready or almost ready for it, more detailed training, like on user story splitting.
Another part is the company culture. There's more of a "fix the problem, not the blame" when things go awry, and the concept of technical debt is understood pretty well, even in the business. (We're about 2 weeks away from removing the last of the Visual FoxPro code from production -- in our Pod's code. We're not quite the first Pod, and won't be the last. So, they know what happens when important-but-not-urgent work is deferred too long.)
There's no time like the present. Well, the past used to be.
Don't fill up pages and pages of Slashdot arguing about which methodology fad is best...
An engineer who ran for Congress. http://herbrobinson.us
From what ya'll are saying, it sounds like big beauracracy all over again! Only the names have been changed, to "protect the guilty".
Note that using new words, does not guarantee a new outcome...
Tired of endless meetings, circling back, and rehashing specifications no one has reviewed? Running out of corporate buzzword bingo cards? I'm working on a new paradigm which I think I'll name: Git-r-dun. Your thoughts?
Logical thinking/work is hard to do in a logical manner. It seems too rigorous at times.