As a young software developper, what really bores me with Agile, is the name, the shiny box you put things into, where it should just be named "Good practices for software developement". It's the mentality of selling things as products, with some kind of prebuilt ideology and aesthetic built along with the core, that really makes me run far far away.
I don't want to be sold a product. The fact that it led people to try new ways of developping software, be it TDD or pair programming or whatever, is good, but heck, just give me the core idea, remove the gift wrap, and go away. I don't want nor need some kind of new age manager coach.
Anyway, the article seems to be making this very point in some way, but then, why the name agile ? Well for marketing of course. So, while i sort of agree with the article, well i'll just be far away looking, thanks.
Eric S. Raymond accurately characterized Agile when he described it as repackaging the things hackers do anyway, in a way that can be sold to non-hackers.
Maybe you don't want to be sold a product. You're not the target audience for Agile Methodology(tm). The MBA and Tim Robbins crowd are.
So, this is what appealed to me about the XP/Agile/Whatever movement. It crystallized some of the things I already saw working into a framework that had some chance of making sense to the nontechnical people who would (IME) tend to freak out at some of the ways hackers work.
As with most religions, what might start out as a good idea (love one another, take your vitamins) can turn into a dogmatic religion once the zealots take over.
It's funny that you mention Tim Robbins because after listening to somebody talk for 30 minutes about the "values" of the agile process I felt like I'd just sat through a Robbins seminar. The harder somebody tries to convince me that they deeply, truly, personally care about their customer the more convinced I am that they're trying to sell me something.
It's also an arguably necessary way to change processes in (largish) organizations who do not have good practices. Sometimes it's necessary to be a highly paid consultant to be taken seriously.
The reason for the name Agile is that it was defined in opposition to what came before it- heavyweight, big design up front, fixed requirements, documentation heavy, non-incremental, non-iterative processes. These methods had names- CMM, RUP, V Model, MDA, MIL-STD-498, and we needed a name for the anti-method to go against them and not be labeled a cowboy coder with no process at all, and sidelined from all important decisions.
These were attempts to take the risk and uncertainty out of the process. Agile is an attempt to provide practices and approaches for dealing with the uncertainty- "embrace change" is very much the opposite of the "change is too expensive" mindset that it was trying to reset.
This adjective "agile" is important, if only to be used as a defense against 300 page requirement documents set in stone by a contract, 500 diagram architectures created before a line of code was written, developers who never got to talk to a user.
If we didn't have agile coaches and advocates, people who sat down to come up with a way to run their project might come up with the naive algorithm and head straight over the waterfall.
I can see how the name doesn't seem to make much sense now that it is bandied about in very prescriptive step by step methods that probably seem not very agile to a person who had not lived through the horrors that came before. However, that is how it should be understood.
Warren Buffet is an unlikely person to quote in a discussion about agile, but .....
"First come the innovators, who see opportunities that others don’t. Then come the imitators, who copy what the innovators have done. And then come the idiots, whose avarice undoes the very innovations they are trying to use to get rich."
Most of these approaches are far older than 8 years. But, large companies often have an “education budget” and there is an industry that repackages old ideas, gives them a shiny name, and sells them for a respectable profit.
EX: Pair programming is very natural in a collage or contest setting. You often see people just default to that mode when under time constraints.
Not "you" in particular, but "you" as in enough of a client base that it matters. This is basically the issue with methodologies, regardless of what the contents of a methodology are!
Being agile is applying those best practices as you suggest. This comes from years of experience on your team - either learned directly or through mentor-ship/apprenticeship, and will vary depending on the problem constraints and environment.
Employing Agile Methodology is applying a pre-defined "solution" to a "problem" that exists, usually because the best practices are not applied at best, but most likely because they are completely foreign to the problem scope.
It's the hammer/nail problem. There is a whole market of people looking for solutions to their half finished projects. There are many people selling hammers, screwdrivers, chisels, drills etc. etc. They all run into the same fundamental issue: not working with a complete toolbox.
The solution to the problem seekers is to hire competent, experienced and most often expensive programming teams and allow them to properly define the problem scope and solution. This is complicated by the fact that often "you" cannot judge the competency or the experience of the people you need to hire.
No amount of ignoring that very hard problem will make it go away. Not whatever process IBM was flaunting 20 years ago, not agile, and not whatever people come up with next.
Hackers are painters after all, and you need to have good painters on your team if you are looking for a good painting. It's very similar to hiring a trades-person to renovate your house. In the end, you find one with a good track record and you essentially get what you pay for.
But you can't call it "Good practices for software developement". Over the years, that term has shifted. 30 years ago it meant the Waterfall method of analysis, 20 years ago it meant OOP, and 10 years ago it started to mean Agile.
Hopefully, we actually are getting better at developing software. But don't think for a minute that what you call "Good practices for software developement" is something trivial, that was known all along, and that you'd have to be an idiot not to do anyway.
The name probably makes more sense for people who wrote software before it came about. Even "non-agile" development processes have evolved in response in the last 8 or so years.
The marketing speak is often useful when one needs to sell ideas to management who might otherwise default to waterfall. I can tell not many here have been in that situation or there would be more appreciation for the utility of branded ideas.
Of course. Most software was developed using that model. I think most software is still developed that way, actually, but most people on HN are more likely to be using new techniques.
I also think this is the model that is still taught in most Universities.
Some of your advertising is running a little haywire on you.
> My cousin called me up and was telling me about all the weight he's lost on this strange new diet. He was really excited. So I dug around and found the link to share:
Dr. Siegal's Cookie Diet - More than 500,000 people have used his cookies to lose weight. Now it's your turn! This page contains a single entry by DanielBMarkham published on September 7, 2010 9:42 AM.
You might want to block that ad manually or change providers. Don't know how much cash that's bringing in, but would you be eligible for something classier like TheDeck ads? Seems you've got the right market.
Scrum consultants stay way past their usefulness, turning into self-aggrandizing organizational vampires.
I think there's something to be said for Scrum, and I think the shock therapy of a period of wholesale dogmatic adoption is the best way to start, with gradual backoff from Scrum dogma only after you appreciate the Scrum way, but goddammit you need to KICK THE CONSULTANTS OUT a few months after adoption and not let them set up camp inside your organization, playing politics to extend their gig as long as possible. The Scrum consultants in my company have been here almost a year. We know Scrum now. They still don't understand much about our business or our systems. Why are they here? Why do I keep hearing "<vampire redacted> says I can't do that," when <vampire redacted> is just a freaking process consultant who reports to a peer of your boss's boss? Why do we let them have that kind of power, when they only exercise it to pretend they still have something to teach us so we will keep paying them?
Also, the ScrumMaster role attracts the wrong kind of people. It attracts people who want power and want to be important. The desire for power conflicts VERY BADLY with being a good ScrumMaster, much worse than being a developer or manager or any other job I can think of. ScrumMaster is a simple role requiring only a little more process expertise than the chicken or pig roles. A ScrumMaster is a meeting facilitator. A ScrumMaster has no authority and no ninja skills. Being a ScrumMaster is like being the guy who can fix the printer. Having good ScrumMasters is very, very important, but they are not Important People. Does that make sense? They are not managers. People outside a Scrum team should not treat the ScrumMaster as a decision-maker or the proper conduit of information into the team. Bad ScrumMasters exploit those habits to aggrandize themselves and try to boss around their teams. Then they have power without responsibility.
Do you really believe an organization could function with no management? Can you really not see the wholes that would create?
The programmer attitude of "All management is bad. I'm better than everybody else in the company. I'm the only invaluable person in this organization." gets really old.
EDIT: OK, as pointed out below, I'm an idiot (much nicer than my grouchy post...). I do feel strongly about the anti-management stance, but that was necessarily not what this reply was talking about. My apologies.
If you do the substitution, you get "management consultants," not "management." I think it's a valid statement. Business always needs management, but management consultants are only good for helping a business solve a particular problem or get through a particular change. Then they should get out of the way. Instead, they work their way up somebody's butt and sit there pulling checks, wielding unaccountable power that is inappropriate for their place in the reporting structure.
It goes like this:
1. People do what the consultants say because hey, you're supposed to be learning from them. It makes sense.
2. Some recalcitrant people refuse to go along with any changes, and upper management puts out the word: "We're paying good money for these consultants. On my authority, do what they say." This still makes sense.
3. The consultants start meddling in things outside their original brief, just because they think they're smart and want to prove it. People have to live with it, so the consultants are gradually accepted as a generic part of the power landscape. This is the beginning of the pathology.
4. The consultants continue wielding power in a disruptive way as long as they can, because if the organization doesn't need their constant correction, somebody might realize it's time to get rid of them. This is the full-blown pathology: consultants actively disrupting productive work because it's the best way for them to stay employed.
Ahh, you are absolutely correct. I jumped to my pre-existing stereotypes. Bad me.
I actually have a negative opinion of most consultants (generally defined as people who tell you what you should do). I feel much better about contractors (defined as people who do what you tell them to do), but only in cases where it isn't your primary business competency being contracted.
Most management is bad, because most managers treat the function of 'management' as a separate domain/skill. Really, management is a combination of good people skills and a strong understanding of your product development & market.
I'm not really anti-Agile, but I like seeing people question the crazy hype around it.
Agile is really just a collection of mostly decent project management and coding advice. It is absolutely not a silver bullet, and it's also not best suited for every project.
There is no substitute for actual coding skill, and there is no substitute for thinking about the specific demands of your specific project when deciding how to manage it, how to prioritize things, etc. Every project is different.
To put it even more simply: you cannot substitute a "McMethodology" for actually thinking.
The idea that "being agile" is a fixed process that you can write down and teach to people seems to me to be a contradiction in terms. If you have to train people how to do it, and have meetings about it, and read books about it, how can you possibly be agile?
Actual agility is the ability to quickly adapt to changing circumstances. To do that as a team you need trust, and great communication. No process can give you either of those things if you've not got them, but a bad process can certainly take them away.
It's exactly this. Management loves to impose scrum (I've yet to hear being implemented from a bottom-up rather than a top-down initiative) as it's an excuse to micromanage: daily status reports, extra meetings, fixed working hours. That said, this may be a benefit for people who aren't passionate or interested in their work and want to clock out at five. That's fine, but that's not for me: my work is tied very closely to my personal identity, I put in many night and weekend hacking sessions and (voluntarily) work more than the usual 45-50 hours a week. At home, when not working, I frequently hack on personal projects and read technical books (indirectly benefiting my employer as well).
I chose to work for a place that judges me by what I produce, not by when I come in to the office. The beauty of being a software engineer in Silicon Valley (and I imagine this is the same in other technology hubs such as Seattle, Rte-128 and Austin) is that I get this choice. Here's a prediction: companies that micromanage in this fashion simply won't attract the required engineering talent. All else equal, engineers will choose a place that gives them more flexibility. The market seems to confirm this. Here's an interesting thread on hours engineers work at Facebook on Quora:
Note: I'm not opposed and frequently make use of "lower-case-A agile" i.e., unit testing, re-factoring, iterative development but they are just common-sense tools; much like editors, IDEs and programming languages they are frequently treated as objects of religious devotion, overlooking the fact they may be right for some (in some organizations, even most) projects, but inappropriate for others.
Yes. There used to be a manager who would schedule a meeting at 10am everyday with me to force me to come in. I was like fuck this, if I have to work until 11pm/midnight the previous night, I should have a little leeway in coming a bit late the next morning. I don't want someone to babysit my time.
I once worked at amazon. They hire managers who can barely operate computers and can't code. They like to keep engineers on call.
So for instance, on more than one occasion I was forced to wake up and fix a chronic problem caused by another team at 3-4am,and would show up at 10:15 and miss he scrum.
Got chewed out for being 15 minutes late on only 5 hours sleep.
Trying to communicate with a mix of people who are A) standing too far from the conference phone or B) driving to work and thus drowned out by road noise, not to mention paying attention to either you or the road but not both -- is a waste of time. Plus, people who are not dialed in can't read body language and so they end up talking too long because they can't see how bored everyone else is but nobody wants to be the one to tell them to shut up.
You know, I'm really beginning to regard the "Agile is led by consultants who don't know what they're doing" and "TDD is a crutch for beginners" crowds as being like the Rush Limbaughs of programming. There's a grain of truth to their points of view, but that's it: just a grain. They get their strength just from being loud enough to make people notice.
To be fair though, I think of the Bob Martins out there as being like the Keith Olbermanns of programming. Again, just a grain of truth but loud.
Die hard Haskell programmers get the distinction of being the Ron Pauls: hip, opinionated, and doomed to an existence of never being taken seriously.
Can't we all just accept that different people work different ways rather than being constantly at each others' throats?
(For the record, I'm not in any of these camps. In fact, I try to avoid joining any camps.)
"Can't we all just accept that different people work different ways rather than being constantly at each others' throats?"
We could if we all worked on one-man projects where you are the only one that reads the code that you write. The reality of the situation is, one day someone else will need to understand and modify your code. If you're inconsiderate about your coding style, then I would say, "No, I can't accept that you work in a different way".
Furthermore, given the choice and all things being equal, I'd rather work on the project that has a huge test suite than the one without it. From my perspective, I'd say the programmer who wrote that test suite is the more considerate programmer.
"We could if we all worked on one-man projects where you are the only one that reads the code that you write. The reality of the situation is, one day someone else will need to understand and modify your code."
Please don't patronize me. I'm fully aware of the fact that I'm working on a team of developers. They even work in the same room as I do.
Secondly, my argument is about 5 miles away from the argument you are arguing against. I'm arguing about organizational issues. I'm not saying that any developer needs to be able to be "incosiderate" all he wants (whatever that means). Guess what? Some shops do well by being agile. Some shops do well by not being agile. Some shops (if you can find them) do well by using Haskell. And there are a ton of shops out there that don't. What I'm getting at is that just because something didn't work for you in your particular situation doesn't mean it's bad.
> Die hard Haskell programmers get the distinction of being the Ron Pauls: hip, opinionated, and doomed to an existence of never being taken seriously.
Don't you know, Haskell's motto is: "Avoid success at all costs."
Start with a big list of features you wan to implement. Product Owner/Manager keeps list in proper order of importance.
Every 2 weeks team gets in a room for 1 hour and marks off what they have done and picks off what needs to be done for the next iteration - generally you try to pick off less work then you think you can do. We'd let you pull in additional work as the "iteration" went on - any extra work completed was a bonus for the PM. Unlike traditional agile - we found that having QA and bugfixes trailing dev by an iteration worked best.
repeat.
Now with this, and it really depends what you're working on, you can still do "releases" every iteration if you want - but you don't have to (but to release a feature it would take generally 2 iterations one for dev, one for test/bugfixes). Generally we would only do daily standups if we're 1. Relying heavily on an outside team. 2. Getting close to a release. Standups always had to occur before 11am (usually at 10) as close to the start of the day as possible.
I found this method worked great. It left the managers with the ability to do some scheduling - w/o those effing "points" or "cupcakes" level of work meetings - which created metrics that no one used. You still get transparency and can release quickly as features get implemented.
My experience is similar, but based more on Sprints and more frequent, shorter meetings. We also utilized "Post-It Driven Development", meaning that all our tasks were written on post-its, with an estimated time-to-completion (rough, like 2 hours, 8 hours, 2 days, etc.)
We would meet for 10 minutes or less each morning, and each person would move their post-its as necessary -- we had 4 columns, not started, started, finished or roadblocked. Each day the post-its got moved over to where they needed to go, and anybody who looked at the board could see exactly who was working on what, how much work was remaining, how much work was completed, and who was or wasn't doing a good job of time estimations.
New feature requests would be queued by the product manager until all of the previous sprint's features were implemented (or delayed, or resolved in some other way), and then we'd start over.
I've been doing "post-it driven development" on my own, using my monitor bezel. It seems to work until the stickiness wears off and the task becomes lost forever. Oh well.
I think there's a few key points to take away from Agile ...
1. Involve end users (aka customers) in the process as much as possible, since if they don't like the end result your work was wasted.
2. Do work in small chunks. Releasing every 1-3 weeks gets changes out in front of real users quickly. The shorter your cycle the less likely you are to spend lots of time on something useless.
3. Write tests!
The specific details of any agile methodology are, IMO, less important. If pair programming or TDD or stand-up meetings help you with those three points, great. If not, don't do them.
All of the "heavy" agiles like Scrum have confused me: isn't agile about fundamentally less process and more flexibility? One can't serve two masters. Teams have to pick a point along the completely structured - completely flexible line. As far as I'm concerned, these flavors of agile are just wolves in sheep's clothing that allow existing waterfall autocrats to continue their reign under the guise of adopting "agile."
It's all relative. For example, the reason you have daily 15 minute meetings is because lots of companies had daily 1+ hour meetings. I believe scrum originated from trying to fix companies that were doing things unbelievably bad. From that perspective, it's a lot less process than before.
I'm getting confused by most of you guys. Some of you said that there are Agile consultants that would blame a failure because "you don't follow it by the book".
First, follow what by the book?
Second, what book?
Third, don't confuse Process with Principles.
Organization failed implementing Agile because the people behind it are still stubborn and still clinging to the old ways of doing things. Yes... this is the reality in our field. We often say things like "IT, Computer, Internet change the way we do things", please allow me to finish that sentence: "... but just don't tell us to change how we build software".
Agile never talks about making software faster. They talk about delivering business value and high-quality software. Even then, quality is defined by the Client, not by the developers/engineers. Some clients were okay with small UI glitches.
Scrum is a Project Management technique that uses a set of Agile techniques behind it. In Scrum, after each Sprint, you should have a potential shippable product. How can you have such situation without a good test-automation? Manual test would work fine early on when the list of features are minimum, but it doesn't scale. Remember, a Sprint is usually either a week or two. How can you re-test the whole product every 2 weeks? Hire more QAs?
Developers these days pay lip-service when it comes to writing test-automation. They'll dodge any tasks related to test. This happens because of our university/education doesn't teach us that test is important. Testing is usually a footnote in "Software Development" courses.
The reason why TDD is important is simple: people lie all the time. People are lazy. That's a matter of fact. They would say "sure, my code is testable, we don't have to write unit-tests now". By the time someone tried to write a unit-test, you'll hear tons of excuses. Can't do.
Now, let's get to everybody's favorite part: Superstar Developer. Yes, they do exist. No, they're not perfect, they'll make mistakes, they'll get sloppy, their estimate went south, etc. Superstar developers write unit-tests. I don't care if they do TDD or not, but at the end of the day, their code should be testable from all angles.
Please understand that we are trying to get better in this industry. Developer testing their own stuff is something quite relatively new. There are _plenty_ developers out there that allergic to testing.
Agile/Scrum/whatever consultant engagements should be measured in hours, not days or weeks. Do a workshop on TDD or optimizing your standups, but if a team is being so badly mismanaged that full-time babysitting is neeeded, they need to replace their management, not add to it.
The greatest success I've had is using a hybrid approach of agile and waterfall. But, let's face it, Agile is anything but agile when it comes to the process. The Agilists out there will be the first to beat you over the head when you don't follow the process by the book.
Agile is anything but agile when it comes to the process. The Agilists out there will be the first to beat you over the head when you don't follow the process by the book.
There is a delicious irony here. The first bullet point of the Agile Manifesto is that individuals and interactions matter more than processes and tools. (See http://agilemanifesto.org/ if don't know what I'm talking about.)
The heart of the Agile movement at the start was that no one process fit all situations. So they tried to come up with whole families of methodologies exactly so that teams could choose the one that best fit their situation. Some of those methodologies proved popular. (eg Scrum.) Some people made a living out of pushing those. And voila! The message became, "Here is a magic methodology that is right for all situations, which we'll be glad to teach you about in our next expensive seminar!"
And so it happens. It seems that all revolutions are destined to become what they were revolting against.
* The message became, "Here is a magic methodology that is right for all situations, which we'll be glad to teach you about in our next expensive seminar!" *
Would you hire someone to manage your software development process who's only qualification is sitting through an expensive three-day seminar?
Would you trust an organization which does so?
If not, why the surprise that such projects struggle?
There is no surprise. But many people's only exposure to agile is this, and the result is that people wind up with an unfairly bad impression of what agile means.
That said, I've used a variety of agile methods for years, but I'm quite sure in ways that would make many of the presenters of those seminars object very strongly to my calling it agile.
One thing I've noticed with Agile projects at $work is that the processes better suit a "contractor" mindset, than a "fulltime employee" one. NOTE: I'm a fulltime employee, so view things from that mindset.
As a contractor (in theory), you're bought in to do a specific job, and then you leave - get done, get paid, get gone. This works well with Agile, where you can devote your entire attention to the project, and not get caught up in other things.
However, fulltime developers will find it more difficult to devote all their time to a project, as they're likely to still be maintaining some of their previous projects as well. In smaller organisations, you often end up being the go-to person for part of the system, and the rest of the business may struggle with these people being out of reach for weeks or months.
Another factor is that contractors have less reason to care about existing code and its design principles when designing and implementing a new project, and well as less reason to care about the maintainability of it. This leads to the software platform having a melange of different styles, further complicating the lives of those who have to support it later on.
To me, Agile just seems like contractor culture converted to religion.
"An agile coach should be able to code, perform analysis, manage the project, test -- anything that needs doing on a project."
This kind of statement seems to typify guru-ism. I suppose there are geniuses what can do everything, write your whole project for you in weekend and be done. But eventually these methodology camps will wind-up turning a bunch of fairly average people into consultants, these methodologies need to have these consultants focus on some particular things they are good at and leave the rest to the others.
The best managers I've had didn't try to be programmers. A large project requires coordination and the manager should be there to do that - see what's on and off track, etc.
I don't know if these consultants are supposed to be managers or architects or what. But whatever they are, they're "goodness" needs to be in doing that well, NOT pretending to be so smart they can tell everyone else exactly how to do their job... And, of course, when a given consultant fails, the head guru can excuse the basic by saying "see, he didn't everything about everything so of course things didn't work..."
My sense is that the 'agile' label is not for a specific process or place-in-the-solution-space but for a direction.
It's a direction that's the opposite of many big company dynamics that can impede software productivity. It's also a direction that's opposite some proclivities of otherwise strong and well-meaning programmers, who nonetheless try to achieve certainty too soon in an ongoing, exploratory project.
"Real life doesn't have a theme. Or if it does, it would be amazingly incredible and preposterously improbable if your book matched up with what was going on with my organization." - what a gem.
Regardless of the Agile theme (that I know little of to comment) this sentence applies to almost all the business books (specially the biography type).
I've read a lot of them and they are basically a collection of feel-good stories with some themes. Selection bias. A typical book will have a chapter like "Never give up" describing some story where the author insisted upon something far-fetched and finally got it (never mind the time he spent on other objectives he didn't get and never mentioned). Same with a lot of other typical themes.
A more objective book like "Founders at work" shows that all of them (from what I remember) got lucky not once but at least twice to have their break. Of course insert here the usual disclaimers that you cannot rely on luck only, you have to work hard etc to be ready when opportunity strikes.
The idea of Scrum terrifies me, especially the Daily Scrum, because I've a very cycling productivity. In averaging the days, I get enough done. But if I would have to justify my less productive days, it would be very stressful for me, and it would be quite hard to explain why I couldn't get done more today.
The daily scrum is supposed to be about coordination, not reporting status to management or evaluating progress of individuals. It's just an opportunity to say "I'm working on XYZ" so someone else can say "Oh, I need to touch that area later today. We should chat offline."
That doesn't mean every team handles the daily scrum well or that the purpose is never hijacked. But it does mean that if the scrum starts to feel like a tribunal, it's probably a process smell that should be raised in the sprint retrospective.
When I was an early teenager, I took violin playing lessons. Whenever I asked my teacher about violin playing technique, he would always give me a quote which he attributed to famous violin teacher D.C. Dounis:
"There is no technique, only a bunch of tricks that help you play better."
He didn't want me to get stuck in the 'technique' mindset. I think he was trying to tell me that applying a predefined technique instead of experimenting with different things meant you were not adapting to the current song, style, your, body or cognitive abilities. Different 'tricks-from-the-masters' worked differently with different people in different situations and a smart player would try different things until they found the combination that made playing easier and better sounding in his current context.
I always thought that quote applied very well to programming.
Scrum is a child play compare to what happens when
organization gets Six Sigma like stuff introduced through.
Scrum Master as scamster !? Big deal! How about whole management tree getting additional clones - green, brown, black belts - who put their extremely empowered, yet clumsy and arrogant, hands and noses into and messing with everything? After having lived through such thing, a mild degree scrum feels just like a fly spec, a minimally necessary sacrifice to blood thirsty Gods of Office Space.
In general I think it's wise to beware of gurus peddling software development methodologies. This doesn't mean that there aren't good practices which can improve the process, but all too often the gurus are not applying a proper quantitative analysis to their methodology to judge its relative efficacy, and instead rely very unscientifically on feelgood anecdotes and difficult to falsify assertions.
I think Scrum helps product management more than developers.
Good programmers always get stuff done quickly and iteratively. Thats how they become 'good programmers' and thats how most of them naturally work.
To me, making the product owner think about backlogs and stories from an end user perspective is the real benefit of Scrum.
Just wanted to apologize again for sniping at you yesterday. It was uncalled for. Glad to see you've been able to incorporate it into a proper discussion.
i read the comments here and wonder if the problems people are expressing here about agile are actually caused by agile, or rather, the people implementing agile?
my money's on the latter. agile, like any process, can be abused by those who don't understand or are too process-oriented.
...if the problems people are expressing here about agile are actually caused by agile, or rather, the people implementing agile
If there is no way to tell, does it matter?
I mean, if Agile requires a perfect implementation, support from everybody, very smart people and luck, is it any good? If I have all that, I can do whatever with any methodology.
It's easy to see the flaw in many failed implementations: they don't manage their schedules, they don't have successful iterations, they don't manage their technical investments, and the only thing they don't do that agile suggests isn't usually worth doing is writing lots of specifications and documentation beforehand.
It's easy to see the flaw in many failed implementations
Is it also also easy to correct the flaw? I don't mean to blame Agile practices. It could be the case that Agile is a bad fit to some "corporate cultures" or certain project type and the result of someone pushing hard its adoption is to have some practices really used and other only in appearance. This could be what people hates.
OK. that would not be "True Agile", but what difference makes for the poor guy that's forced to play a part?
Edit: I've had Scrum in mind all the time when writting "Agile". Sorry.
Not at all. If everyone involved in the project (everyone with a stake in the success of the project) agrees to give an agile process an honest chance, great. If not, you'll have trouble. A similar rule applies for coding standards, for test coverage, for security and logging, for transactional safety, for dieting, and for getting out of debt.
I have yet to see an "unsuccessful" project using agile, as in the customer and team was not happy with the conclusion (I've been involved with > 10). Usually things change before that point is reached.
If the team cannot change when things start sucking, then things will continue to suck, regardless of methodology or lack of. Most teams can adjust (at least the ones I want to be a part of).
> If all you've seen is succesful projects, you can only guess why failed ones fail.
True. The project I have been a part of do have problems though. Sometimes the problems get resolved quickly and sometimes it takes a while or never happens.
Failure comes in many forms. I'm not pretending to have encyclopedic knowledge over the various ways projects fail. I do know that issues arise on the team and good communication often helps resolve these issues.
Also, having a good attitude is important. It's easy to be negative to your teammates (I have this problem), but it's also harmful and inappropriate at times.
In my experience, the biggest issues (or the largest cause of my stress) were often issues within the team.
Perhaps Scrum (and Scrum alone) is dangerous, in the sense that it's difficult to adopt without careful, disciplined technical practices already in place and the whole team's understanding that scrum scheduling and management is very different from the so-called traditional approaches.
Implementing scrum turned our team from productive and mostly free of overhead to overbearing, involving a lot of long ass meetings (all meetings are long if you have to stand) and produced a lot of additional confusion. The interesting thing is that previously, with our specs and our so-called waterfall approach were were more agile. It happened naturally as we naturally did incremental development and we naturally talked to each other when we needed to, with no annoying scrum meetings and asinine bs from managers. People say managers have no voice at scrums, but what is a scrum master anyway? Everyone who doesn't write code is a manager and their opinion can interfere with progress. And of course the idiot child product manager would constantly lecture people about talking too much, except she would never shut up herself.
Even if a meeting is 15 minutes, if it is irritating, insulting, distracting and undermining, then it negatively impacts productivity for at least an hour after. I took to. Having breakfast afterwards, where I normally wouldn't eat breakfast, just to get centered so I could get some work done for the rest of the day.
I left that company soon after. If I had stayed i would have gone postal, or had to hire a lawyer to sue them under the ADA for torturing me by making me stand and listen to sanctimonious bullshit from idiots.
People say, when a bad experience is described that it wasn't being done right. Well i see no difference between what i experienced and what is being advocated.
Yes, there is a lot of anger towards the agile movement because it was sold as a tool to pointy haired bosses to impose, rather than a grassroots movement among engineers that embraced flexibility.
That said, on my own we've adopted a number of so-called agile methodologies like incremental and iterative development.
But the whole movement I'd oriented around imposing ideology on people. This is wrong.
For instance, whenever unit tests or test driven development comes up the proponents act like anyone not doing things this way is incompetent. I think the reverse is true, but I would never say there is ONE TRUE WAY. Agile proponents often seem to say there is only ONE TRUE WAY.
Also, don't mod me down just because I work differently to you. This is the ideology of the ONE TRUE WAY that is just wrong.
Programmers come in all shapes and sizes. They actually can be productive and work in a different than I do or you do.
Factors contributing to the success of a development project, in decreasing order of importance:
1. the skill of the team
2. the determination of the team to succeed
3. appropriate choice of technologies
4. process
In my experience management agendas are much more likely to interfere with 1-4 than to help. There needs to be some kind of hippocratic oath for development managers and process enthusiasts. Everybody pays lip service to Fred Brooks but people somehow seem to keep forgetting his message.
They're forgetting it because they want to forget it.
Businessmen want (for reasons that are somewhat rational) to commoditize everything, including labor. Programming labor has been stubbornly difficult to commoditize. Programmers differ in skill in very deep and complex ways, and can't just be swapped out like assembly line workers.
This is immensely frustrating to the bean counters. Anything that comes along and promises to allow programmers to become commodities is going to catch on like wildfire. The desire is too strong from a management perspective. It doesn't matter how many times such efforts have failed in the past. What's old will become new again.
The point of Agile (and Scrum) is to give responsibility back to the clients/managers: pick one -> time or money, you can't have both; we'll show you why from our user-stories, cards, task-boards, poker-game, scrum planning, etc.
Exactly, this is what "calibration" and "velocity" are about. But the elephant in the corner of the room is that skill still matters, you can't swap a good team for a bad one and get the same velocity. In fact it makes the management problem harder; now you don't just need "a hacker" but a whole team...
Agile theory does make some nods to not commodifying the programmers labor and giving programmers autonomy. But when it's sold the bean counters, they filter for the parts that get them what they want.
Not to mention that it appears to eliminate the long "measuring before you cut" thing at the start of new projects. Fingers on keyboards equals productivity!
We have a lot of decent developers on our team. But management is still stuck in 90's where everything is done as huge framework building waterfall exercise. The word YAGNI doesnt mean anything to anyone here.
So yea lot of skilled devs are writing useless frameworks when they could have producing real business value.
So I would say the most important thing is the process once you have a decently skilled team.
Are you in the business of writing software that never gets used? I have, and I hated it. Quick feedback means quickly finding out if you're building the right thing.
Quick feedback means quickly finding out if you're building the right thing.
I agree. That's why I use a development process that encourages quick feedback. I don't consider that market research because I'm not out looking for customers to give me money in exchange for a DVD full of software. I'm sitting down with the person who hired me and demonstrating what I've done in the past week or two.
"No McMethodology can make crappy programmers write good code. Period."
Can't a McMethodology help crappy programmers become less crappy (and eventually write better code)?
Are there any methodologies that can help with this?
Ideally, poor developers get replaced by better developers, but realistically this (for all sorts of reasons) doesn't always happen. So, if you're a project or team leader, what can you do to elevated the level of code from sub-optimum developers?
Anything? Or maybe it's better to give them "fake" code to write so they stay busy and out of the way.
I don't think so, no. My experience is that mediocre and poor programmers take refuge in high-ceremony work environments like agile, where there is basically an infinite amount of non-productive "work" that can be engaged in, and no-one can criticize because they're following the process.
I do think that poor developers can be taught to be better in a work environment, but it's a painful, slow process, and has to be started with an a keen devotion to the process on the part of the trainee, which if it were going to happen at all, would probably have already happened during college.
I have difficulty imagining an agile process worth following where standups don't reveal that people aren't doing worthwhile things, where retrospectives don't reveal that estimates have gone horribly wrong, and where pair programming doesn't reveal that some people shouldn't be writing software.
What exactly do these high-ceremony agile projects practice?
I (the author) agree with you. I also do not like this whole idea of ONE TRUE WAY. From the closing graphs.
Iterative and incremental development isn't for everybody. Lots of teams do things completely ad-hoc. Lots of teams are happy with waterfall. Lots of folks just don't care to change. These are all good reasons why agile might be a bad idea.
My standard for what agile isn't universal, sure. but I'm very happy teaching best practices for iterative and incremental development. You can call that agile, you can call it Joe. Whatever it is, helping people see things and try things they haven't seen or tried before -- and then letting them decide whether it's working for them or not... Over time there can be an us-versus-them attitude that sets up between any two groups of people. We must always be on guard for this. If you're not a servant to the team, you shouldn't be in the room.
Sure, didn't mean to come off as disagreeing with you, as your article makes many of the same points. Just venting because so much of these ideas have become an ideology....I respect that you are advocating a non-ideological approach.
The gaping vulnerability in the traditional ad-hoc waterfall approach is management is constantly interrupting work in progress and changing the priorities, then wondering aloud why nothing ever seems to get done.
Agile is certainly worth the bureaucratic hassles it adds because agile protects developers from the tyranny of ever-changing priorities. At the start of each iteration (every 4 weeks or so) the management team must agree that these issues, and only these issues, will be the entirety of what the team works on for that iteration, no exceptions, no additions, no interruptions. A good management team will respect that agreement and protect the team from interruptions.
This can be solved simply by explaining to your management that Change == Things Will Be Late. If your management can't understand this, then it's unlikely that they'll be able to commit to Agile, anyway.
But using Agile allows you to show this in concrete terms. Waterfall uses the "man hours/months/years" metric which is useless given the difference in productivity between developers. Agile, on the other hand, shows the output that is occurring on average, i.e. what you're realistically going to get.
What I tell people is: what do you want? Do you want to never be told no, but never get what you were promised? Then use waterfall. Do you want to usually get what was promised, but be told you can't have what ever you want? Then use Scrum.
You know what one of the core values of Agile is? People over process.
For fuck sake, the reason the Agile Manifesto came into being in the first place because the people writing it, the people who created various methodologies now known as "Agile", agreed that there was no ONE TRUE WAY, just a set a values they shared. Each and every one of them would agree with you.
This willful misunderstanding of agile is just pathetic. It's like listing to teabaggers going on about death panels.
Back when that is what agile was, I was all for it. But it had become a dogma, just like the dogma that causes you to lie about the tea party and obamacare- you don't carewhat reality is.
Wow, it's pretty surprising to see such a rant get so many upvotes. Your rant is about a bad company (good on you for quitting) but it has nothing to do with Scrum.
You're right that there is for sure no "one true way". For me, I like (the parts I use of) Scrum because (a) it puts a low limit on how long a project can veer off track without anyone noticing (i.e. you can only lose SCRUM_LENGTH time at once, not years) and (b) it puts up a wall that stops business from just coming over interrupting me everything some bright idea pops in their head (they can do this if they wish but it means canceling the current scrum. Usually this is enough to make sure they don't do this for trivial stuff).
Maybe one reason I like it is because I'm the kind of person who always sees "rules" as guidelines, not things to be followed rigorously in all cases.
there is a lot of anger towards the agile movement because it was sold as a tool to pointy haired bosses to impose, rather than a grassroots movement among engineers that embraced flexibility.
the interesting thing is that the agile movement started as exactly the reverse of what you said: as a grassroots movement among engineers that embraced flexibility, not a tool to pointy haired bosses to impose.
If your experience is the opposite, you've been had by someone, and you're blaming agile.
whenever unit tests or test driven development comes up the proponents act like anyone not doing things this way is incompetent. I think the reverse is true
The reverse would be "anyone doing unit tests in incompetent", which is not a defendable statement. What are you trying to say?
Being Agile has become a fad off late. This has led to team adopting agile blindly doing things without understanding the reason or need behind it. This could lead to frustration mentioned by you involving a lot of long ass meetings standing.
I believe as mentioned in the article that Agile is a set of best practices followed by a ever adaptive team. I completely agree there is in no ONE TRUE WAY.
We implemented it because one of the teams we work with implemented it. The big difference no one cared to notice was that they work in terms of iterative builds of a huge application that they determine the timescales of, and we work on learning products that have prescribed deadlines, sometimes down to "this needs to be done this afternoon for tomorrow morning".
We were still forced to estimate the effort of something that we knew had to be done the same day, and it was to be done by the person who had free time, no the person who it would be the least effort for.
No surprise it was a completely hollow experience.
True, It can disorganize the team and make it counterproductive if it isn't in the 'agile' mindset (or hasn't adapted to it in a reasonable period of time).
Thank you, my experience has been same, and I could have not said this better.
I'd like to add that anyone in this position should do exactly what you and I did, and quit. Time is valuable. Leave them to find out the error of their ways by themselves if they're unwilling to listen. They'll think you're wrong. You'll think they're wrong. Fine. Let the free market work it out.
I now work as a contracter elsewhere, solving more worthy and interesting problems, and with wonderful coworkers. Our methodology adapts as required to the problems we are trying to solve. We're incredibly productive and love our jobs, because we think about the product we're trying to create and not about following arbitrary rules in lockstep.
The way to overcome incompetence isn't to fight it but leapfrog it entirely.
whenever unit tests or test driven development comes up the proponents act like anyone not doing things this way is incompetent. I think the reverse is true
Can you elaborate on what you mean by this last part?
yes, and the worst part is when the pointy haired bosses become Agile experts and start to look down on software developers. They couldn't write an application even to save their lives but now they feel they are the experts and try to manage the developers.
Exactly. IMHO the role of the Scrum Master only really exists during the daily standup. The rest of the time that guy should be coding with everyone else.
When people start selling Agile methods and trying to replace ideas with routines, meetings and paperwork - it is became a scam, of course.
But the ideas, on which Agile was built upon - like interviewing experts of the problem domain, extracting and preserving slang and vocabulary from the stories and keeping that terminology through data, code and even a markup by naming the same thing the same name everywhere. Design for changes, code for reuse, start early and iterate, adapt and evolve - all those ideas are working ones.
So, the problem is just with pre-packaged methods and forced techniques. Each group, each project should realize usefulness of some of those ideas by changing their habits and by practicing, not because some "guru" told you that something is such and such. It is the only way.
It is a common situation when some ideas replaced by routines and propaganda and authority of "teachers". Buddhism is the best example. The essence of Buddha's teaching is several simple ideas and conclusions from them. But in many places people have transformed them into sets of rituals, rules and endless empty talks.
Interesting to see the present backlash against agile and TDD. As an independent developer, I can pick and choose what works.
I can say honestly they are both really useful concepts filled with great tools, but I am not an expert on either. TDD has saved my life a number of times. I have seen lots of tragedies averted and productive discussions because of "scrums."
When process takes over function in any environment, innovation and motivation will be squashed.
I don't want to be sold a product. The fact that it led people to try new ways of developping software, be it TDD or pair programming or whatever, is good, but heck, just give me the core idea, remove the gift wrap, and go away. I don't want nor need some kind of new age manager coach.
Anyway, the article seems to be making this very point in some way, but then, why the name agile ? Well for marketing of course. So, while i sort of agree with the article, well i'll just be far away looking, thanks.