Where did all the developers go?

http://agilewarrior.wordpress.com/2014/05/13/where-did-all-the-developers-go/

by mpweiher • 12 years ago

71 101 12 years ago

agilewarrior.wordpress.com

malvosenior• 12 years ago

Once Agile was co-opted by management, it was time to move on.

YTowOnt9• 12 years ago

Co-opted is the correct word.

I like the idea of story points as a tool for communicating with each other about rough estimates. I don't like story points as a source of data for management to put into spreadsheets and use in dubious "velocity calculations". I especially don't like the results of those calculations being used to measure my individual productivity and set expectations about my future work rate.

The language of agile has been co-opted to suit the needs of mediocre managers.

logfromblammo4• 12 years ago

Exactly this. Agile was converted from an adjective to a noun, and then people started selling the noun.

There's only so much you can charge someone to tell them, "The skills your developers possess for creating and modifying computerized systems can also be applied to organizing software development teams. Just make it part of their jobs to improve their own process, and give them frequent, objective feedback on how they are doing."

ratsbane• 12 years ago

Yes. That could apply to other things as well. Once anything is co-opted by management it's time to move. If management would just learn to program...

wil421• 12 years ago

Most people at my company who are attending Agile training/conferences or whatever are definitely not technical people. Mostly they are Project Managers, Continuos Improvement Six Sigma types, or non-technical people put on software projects.

I've always wondered if our Devs know Agile practices already, learn it on the fly, or dont care. I am going with the latter.

typicalrunt• 12 years ago

Agile is software. How can you talk Agile without involving the people who create it?

And yet, non-devs are the people that talk about going to these Agile conferences. They're also the people targeted for Certified Scrum Master certifications. The movement of Agile away from developers has been happening for awhile. It's just another management philosophy now.

Does it matter that the people creating the software are no longer at the table.

Yes. Full stop.

All in all, I feel that the author is simply answering his own questions.

dragonwriter6• 12 years ago

The movement of Agile away from developers has been happening for awhile. It's just another management philosophy now.

No, its not. Its a management buzzword now. It started as a philosophy, and where it still is, the substance of its principles remains important. But, increasingly, its become a meaningless phrase that marketeers that neither understand nor care about technology slap on snake oil to sell it to managers that are out of the day-to-day process of technology.

allochthon• 12 years ago

Its a management buzzword now.

To expand on this a little -- members of larger organizations have succeeded in neutralizing a threat to their perceived interests by making the language mean less than it used to. Effective agile practice breaks down a barrier between people making decisions and people doing the work. That must feel like a threat if your position involves little more than politely instructing other people what to do.

dev3602• 12 years ago

I used to be in 'Enterprise' development and I have noticed that a lot of people I knew who were doing PM work have now jumped onto the Agile bandwagon.

codeonfire• 12 years ago

Who controls the travel budget at most companies? It's not developers.

Loque• 12 years ago

For me, it is two things; 1. Agile methodology needs to be managed by someone, and this someone is not normally a developer (in my experience), it also needs to be understood by the client and other members in the team, and this again, in my experience is not the case. 2. Personally I feel I have a negative view of these meetups, I feel unfortunately surrounded by non-developers in my teams who are more interested in their linkedin profile appearance, or having a 'cool' job, uninterested in the intricacies of their job and how much of a benefit it has to everyone involved. Working with people who think that if they are not being paid, they shouldn't care, it can take the enthusiasm out of your developers, especially when they are expected to go the extra mile to make up for the lack of process and documentation.

I apologies in advance if this comment is not to the satisfaction of the community. Just my (possibly bitter) two cents.

sergiotapia• 12 years ago

Is it because we’ve been hijacked by Scrum professionals, certification wonks, vendors, and other ‘professionals’ who do everything but deliver software?

Right on the money I'm afraid.

joshstrange• 12 years ago

Yep, the "Agile" that I was taught through a 2-day course I went to for a client I used to work with was quite different than the "Core Agile" that was laid out originally. It didn't take long for the company to slide back into a sort of waterfall-agile or, as this author phrases it "everyone is falling backwards reverting to 30 day waterfall sprints under the umbrella of Scrum".

Really sad that at the end of the day "Agile" meant more admin work and meetings and no noticeable improvements (to me). Of course management saw "improvements" but the "scrum masters" would just tweak numbers to make it look like we met deadlines or completed enough story points. It was really sickening to watch everyone pat everyone else on the back for doing a good job when I knew at least 1/3rd of the scrum teams didn't get close to what they were supposed to accomplish.

twistedpair2• 12 years ago

It goes both ways. I've been at a company that had "scrum coaches" that ensured the Agile practices were followed to the letter and fought against the higher managers when they pushed back in waterfall like ways. Agile was quite a success and we shipped a ton of bug free/stable released of our product in 1/6 the time as anyone in the corporate had bid the job at. The process also engaged and empowered developers far more than they had been in the past.

Conversely, at another employer they pasteurized "agile" into their own canned "agile-fall" methodology that had many antipodal theoretical conflicts, resulting in just 4 week single iteration waterfall sprints. The results of said agile-fall were very lackluster as no one was empowered, and there no greater clarity into process for dev's.

As such, there is certainly a right and wrong way to do agile. I'd say too many companies fear it because it let's the patients run the asylum (dev's) and reveals that you really don't need so many PHB's.

atomicfiredoll• 12 years ago

This seems pretty dead-on. When hiring for a company, it's generally understood that having talented developers in your company will help attract other talented developers.

As the groups mentioned in the above comment have shown a stronger presence, even more people from these groups appear. And, as the number of developers has dwindled, there has been less reason for others in their profession to come and share.

beat2• 12 years ago

It's going to happen to DevOps, too. :(

ferentchak6• 12 years ago

DevOps always appeared to me to be the more dev centric agile practices (XP, Continuous Integration -> Continuous Deployment, Cross Functional Teams) trying to detach themselves from the project management type practices so that they could have conversations with people that actually know the tech.

IBM has already thrown their weight behind the DevOps buzzword. It will probably be harder to mess with than traditional agile was.

beat2• 12 years ago

I'm already seeing problems where the focus is less on inter-team communication and more on tooling, which is a Bad Thing. Yeah, puppet/chef is wonderful. Cloud is wonderful. But the communication issue remains, and it's much harder to fix than the tech. It requires active management support to break the hierarchy.

skizm• 12 years ago

As a dev, I like agile (or at least the idea behind agile) because it allows me to code more and meet with people less. If other developers are anything like me I have no problem understanding why developers aren't showing up to these conferences (basically day long meetings about meeting structures).

batoure2• 12 years ago

The company I work for follows an agile-ish methodology. Having attended some agile conferences I would say that there aren't really insights there for most of our developers.

We do TDD and run our projects through ticketing and a CI server. Once those policies and technologies were in place developers pretty much stopped caring what agile was.(that doesn't imply we don't do it we just don't really worry about the logistics of it)

I sort of think of agile as a interface language for management to interact with us.

logfromblammo4• 12 years ago

I think it was like that originally, but now it is just another set of cargo cult rituals, with new management buzzwords.

The problem remains that managers in most companies cannot reliably discern the difference between valuable work product and the physical evidence of completely wasted time. They cannot tell at a glance whether the code and/or architecture is museum-quality or DailyWTF fodder. They cannot tell when the entire development team is colluding to implement mortgage-driven development. The fundamental flaw in the system is that managers and developers do not think in compatible ways. To the manager, a developer might as well be an alien, asking him for more cows and sharper scalpels. To a developer, the manager might as well be an alien, asking him to drop his pants and hop up onto the Probulator.

What is really needed is someone with both pointy hair and a neckbeard, who can translate easily between the people who need to cover their asses and justify their own existence, and the people who need both rational objectivity and aesthetic merit in their work. Both sides are needed, because honestly I have known too many co-workers that cannot seem to fathom that they don't get paid unless the work they do can somehow add value to the things the company actually sells to people outside the company.

The artist usually doesn't know when to sign the thing and ship it to the gallery, and the gallery salesman often has no idea what the piece is actually worth when a customer shows up to make an offer.

batoure2• 12 years ago

I definitely agree with alot of your points. I guess what I meant to say was that for alot of organizations it seems to be useless paradigm gibberish.

For our organization it doesn't seem to be, and my purely unscientific observation would be that getting devs on board is more about tools and channeling them through a process. That, you can get someone through pretty quick because its primarily logistics based.

We have tickets that are tied to pull requests you have to submit your PRs for test tickets before you can submit your PRs for feature tickets we have a CI server that will run those PR's against the tests at which point we merge everything.

This makes it pretty straight forward how development has to get done.

Where as, getting people who aren't code driven on-board requires complex paradigm adoption about how we design projects and road-map the business. Some of these people end up at these types of trainings because they are the people who need the indoctrination the most.

Developers we have faced have a tendency to either just sort of shrug and go "ok" or to want to totally fight the system and tear it down and replace it with X. We do our best to weed the violent opposition types by using test writing as examples during interviews the violent opposition types usually get visibly frustrated by the "test then code" approach of TDD so we haven't had to much trouble identifying people like this.

The long and short would be:

I think that the thesis of the OP that lack of dev's is a problem can be rejected because engineering unit employees don't face the same hill climb to adoption that business unit employees do and that this has been enabled by the fact that:

developers have at this point written them selves tools to automate their own side of the paradigm... i.e Jira Github and so on

rjknight• 12 years ago

The wider process is the only part of software development that non-developers can understand[1]. Developers, given the choice, would probably rather go to meetups and conferences about technology than about process. These two facts create enough of a bias towards "agile" events being dominated by non-developers, and it becomes self-reinforcing after a while (developers are even less likely to want to go to the events once they realise how many non-developers are going).

[1] If they could understand development, they'd be developers

skylan_q• 12 years ago

It was about being agile, which is what developers were striving for. Now it's about doing agile which is in direct conflict with the notion of being agile.

NathanKP• 12 years ago

Many of the developers in this community don't care that much about Agile development as a concept, because we are startup devs that prefer to work in a company that only has 3-5 devs total and doesn't need a fancy named system to make the development cycle work.

To us, "Agile" is the organizational system that you need to build out once the company scales up to lots of devs, but by that time we are already gone, working at a new startup building new stuff in another tiny team. We don't like the organizational cruft, we just like the process of building stuff, preferably with limited management.

UK-AL2• 12 years ago

Agile only really works for teams of 3-7. It's defiantly not a methodology for larger teams.

There are things for scaled up Agile development such as SAFe, but it's really a hack.

ferentchak6• 12 years ago

Most of the research says agile teams of 7+-2 are best. At my work we have been trying to look at the differences that team size makes in software output.

SAFe is interesting because it can help show large companies understand the value to using XP practices. Crazy ideas like unit testing your code.

dragonwriter6• 12 years ago

Agile only really works for teams of 3-7.

The usual rule of thumb is that "atomic" teams should be 5-9 members (often expressed as 7 plus-or-minus 2), with larger groups as teams-of-teams. Larger teams simply don't work as single teams, and there's centuries of experience supporting that in pretty much every field everywhere.

AnimalMuppet2• 12 years ago

I once worked on an XP team of 30. It worked. We had people who specialized in some areas of the code, but we worked hard on avoiding silos.

rubiquity• 12 years ago

Developers find the most value in meeting with other developers. Being that Agile was created by developers, you can imagine we're a bit disheartened when we go to Agile meetups flooded with Scrum (which is complete trash and not in the interest of developers in the least bit) "professionals."

The best discussions I have about Agile happen on the internet or at a programming meetup for languages, databases, etc.

smonff• 12 years ago

All the developers are living in Lao PDR.

avz2• 12 years ago

Maybe it's because we've received the secret developers-eyes-only memo:

True Agile:

  Individuals and interactions over processes and tools
  Working software over comprehensive documentation
  Customer collaboration over contract negotiation
  Responding to change over following a plan
  Getting shit done over attending meetings and conferences

lhnz• 12 years ago

This needs to be at the top.

90% of what is sold to me as "Agile" is not at all agile. It is unproductive snake-oil sold by people that benefit by playing with numbers, taking credit and acting as whip.

Nowadays the existence of the word in job descriptions is actually a filter for poorly-run companies. Either they unconsciously swallowed the Kool-Aid or there is a lack of managerial trust in the builders and they have chosen to sacrifice work output for an emotionally comforting feeling of control.

The insinuation from many companies that anybody would want Agile processes to work efficiently is ridiculous. Those that work well are agile because they intuitively or consciously follow the original principles and are part of a cohesive team that doesn't do unnecessary work.

avz2• 12 years ago

I think more and more people realize this. The four original value statements from the Agile Manifesto are mentioned far too infrequently compared to all the processes and tools peddled by various agile salespeople.

A friend of mine recently asked me to give a short presentation to a few developers working at his small software company. He suggested that Agile may be a good subject and we spent an hour discussing how his developers analyse, design, code and test their projects so that I could give a relevant talk. It turned out that what they were doing was naturally very close to agile development and the whole talk would have been a waste of everyone's time. I just gave him the link http://agilemanifesto.org and ended up talking about XSS.

redthrowaway• 12 years ago

Nowadays the existence of the word in job descriptions is actually a filter for poorly-run companies

I've noticed this, as well. In those friendly little emails LinkedIn keeps sending me, the companies who claim to be big-A Agile are the ones that seem like the least enjoyable to work for. The ones that actually are agile and would be fun to work for find other ways to signal that fact - mostly by using descriptions that show them to be developer-centric and focussed on software.

twistedpair2• 12 years ago

I'd add that the concept of the "story" and the fact that it needs a title of the format "As a <party> I need <functionality> because it add <some business value>." That practice is quite powerful. It continues to amaze me how many project managers are content starting and promising delivery of a project without a clear Definition of Done or any understanding how all this effort will add value to the company/product.

eldelshell2• 12 years ago

"Getting shit done over attending meetings"

And yet I've seen "agile" teams waste more time in "agile" meetings than in anything else... except for PingPong.

LandoCalrissian• 12 years ago

Sprint demos, sprint commits, backlog grooming, daily scrums... It goes on and on. So much of it is not actually getting anything done. Make sure your burndown is good guys!

angersock2• 12 years ago

"Working software over comprehensive documentation"

And this is why nobody who is a real engineer should ever take most software engineers seriously.

scrabble2• 12 years ago

Well written software should generally be able to double as documentation.

hatu• 12 years ago

As a developer, I know how Agile works. It's pretty simple. Now why would I want to waste a few days of working time to go to a conference about it? Most people can probably do zero to two conferences a year paid by their employer. To me this sounds incredibly boring compared to something related to my field or ecosystem.

ww5204• 12 years ago

The Agile processes are ways for managers to enforce a manufacturing-like process to software development to micro manage development activities to squeeze every little bit of productivity out of developers in the expense of creativity. They work well for managing junior developers or for body shop. Senior developers hate them.

The daily meetings usually turn into daily status meetings, no matter how much the Agile advocates claim otherwise. The rough estimate become a hard deadline, with daily remainder of why it's slipping. Pair programming - free training for junior developers, a waste of time for senior developers.

dragonwriter6• 12 years ago

(1) There are no such thing as "Agile processes", and anyone that tells you there is is lying to sell you a process.

(2) The only relation anything "Agile" has to do with manufacturing is that the Agile approach to software is close parallels to Lean methodologies in manufacturing (which have circled around to create Lean software methodologies.) But Lean, while it is an approach to improving productivity, is pretty much the opposite of doing so at the expense of the creativity of the line workers, as they rest on the combination of defining and measuring value and harnessing the deep knowledge of the workforce to propose, implement, and test methods of improving value produced.

UK-AL2• 12 years ago

Agile & Lean have quite a few things in common such delivering lots of little chunks of value to customer as fast possible. Not doing things in large batches etc. Asking the people doing the work to implement improvements, since they know the work etc

ferentchak6• 12 years ago

There are agile practices though. Some of them are so simple we don't even think of them as being a practice.

Practices like continuous integration and unit testing traditionally fell into that category. I would say these days that writing unit tests is so common that it doesn't feel like it came from anywhere. Just that it always existed.

AnimalMuppet2• 12 years ago

Lean, applied to software, would mean that the software team can see opportunities to improve their process and/or tools, and would have the power to do so.

I've actually been on a team that did this. "For the next two-week iteration, we're going to change the process in this way, and we'll see how that works."

Process doesn't have to be a static thing handed down from on high. Hack it. Make it work for you. (One of the agile approaches to software is "pay attention to pain". That is, when it's hard to change the software in some way, that's telling you that it should be refactored so that it quits being hard to change it in that way. Well, the same thing works for process. If the process is painful, pay attention. It's telling you that you need to change the process.)

acdha2• 12 years ago

Pair programming - free training for junior developers, a waste of time for senior developers.

The fact that you consider training a waste is depressing. Good senior developers recognize that training is critically important unless they want to do everything personally – and it's extremely rare that you don't learn something, too. If it's a waste of time, you're doing it wrong - a truly senior developer would learn from that and fix something.

logfromblammo4• 12 years ago

It wouldn't be a waste of time if there were not an endemic bias against both having older developers and paying them more for their experience.

As the employer-employee loyalty culture has been systematically destroyed, I am far more likely to see the training of more junior developers as training my own replacement than as improving the capabilities of my team.

If you want me to train someone in anything, you really ought to make me feel secure in my position, such as by offering me some form of job security. For the sake of discussion, let's just call that "tenure". If I am an "at will" employee, the only form of job security at my disposal is to be indispensable, and training others undermines that.

So if your company has a clear career path, with employees from entry-level tenderfoot to ultra-senior guru, and every step in between, you might feel good about training. If, on the other hand, your office is full of young bros, and the dusties are encouraged to move out to pasture when it's time, your time is coming.

If a company truly has a commitment to training, a necessary prerequisite is a commitment to long-term employee retention.

ww5204• 12 years ago

Pair programming is not training. It is not the main function of pair programming. The fact training becomes the most important reason trumpeted for pair programming speaks fully how ill conceited the concept is.

I'm all for training. I'm against 8-hour a day, 5-day a week pair programming. Even if training is so important, developers are not signing up to be a professional trainer.

allsystemsgo• 12 years ago

Pair programming - free training for junior developers, a waste of time for senior developers.

I disagree. That's not how you build a team. Also, senior developers who can't pair program, aren't senior developers. That means you can't communicate, or at least you don't want to, even if it's talking about code you don't want to. That's not how you become a lead/architect.

Nursie2• 12 years ago

Who wants to build a team? Some of us are just there to get the job done and get out...

I can communicate very well, and am helpful as I can be when people need it. But slow-as-molasses pair programming with an 8nexperienced junior sounds like hell to me.

mkal_tsr2• 12 years ago

Also, senior developers who can't pair program, aren't senior developers.

Ah yes, the cliched "if you don't do X you can't call yourself Y" shtick. I know many senior developers that don't pair program. Why? It's inefficient and they get significantly less done. Not to mention, you have no room to experiment with different approaches because you've got some person sitting next to you and human emotion kicks in and they feel like they're being watched and judged at every move.

You know when pair programming is endorsed by the senior developers? Root-causing bugs.

ww5204• 12 years ago

I disagree. You don't need pair programming to build a team. Overwhelming percentage of successful teams exist without pair programming.

One can be an effective leader, communicates well, designs and architects large system, mentors junior developers, inspires them to learn, coordinates development effort, sets up development processes and standards, and develops awesome software without doing pair programming.

Pair programming is not the only and true way to develop software. It's just some passé imposed by Agile advocates.

Nursie2• 12 years ago

When 'Agile' became more process heavy and process driven than previous models, I sorta gave up on it.

Nice idea, shame about the religion around it.

Spearchucker2• 12 years ago

Many devs I speak and work with are either ambivalent or disillusioned about agile. In my circles this article keeps coming up in discussions about agile - https://securosis.com/blog/agile-development-and-security/.

jerf• 12 years ago

Errr, while I agree that Agile has a hard time producing secure code, I see little evidence that non-Agile has any easier of a time. Sure, in theory Agile under some interpretations [1] precludes the sort of thoughtful design that security requires, but it's not as if very many projects are getting it right without Agile either. To a first approximation, everybody does security this way:

    1. Some developer who thinks they understand security, but really doesn't,
       make some vague sketches on a napkin that describe how one particular
       attack, which isn't even that big a threat in the first place, could
       conceivably be prevented, if the attacker cooperates well enough.
    2. Development happens without regard to the napkin.
    3. Flaws are fixed one-by-one as they are reported with little thought
       given to whether the reported flaws reveal a systematic problem.

The most common alternatives to 1 are "Everybody on this project is just so awesome that they would never make mistakes so we don't even have to think about security", "Oh, security, pshaw, 'just' sanitize user inputs and you're done" (though press them on what "sanitizing" is and you'll find it generally borders on meaningless) and "________." (no thoughts given at all).

[1]: That caveat is important, please do not reply as if it is not there.

Spearchucker2• 12 years ago

I agree with you. Security takes discipline, regardless of methodology. Interestingly, the only freely-available security-focused method I've seen is Microsoft's SDL (waterfall)[1].

The article does spark some interesting debate though, also about TDD.

[1] http://www.microsoft.com/security/sdl/default.aspx

nakovet• 12 years ago

My feeling nowadays is that to develop you need to know how to program, that means, you need to know something.

But to be a project manager or scrum master all you need is a chance, that's all you need, a chance to do something you don't understand, you don't know how is built nor how it works, later you can show up in conferences and training sessions (paid by the company of course) to try to improve your performance/understanding in your current position.

Knowing that, is hard to show up in some events, conferences and meet these bozos.

badman_ting• 12 years ago

Where I work, what began as a studiously followed Scrum process (where teams decided which parts were important and which weren't) has devolved into "we put a bunch of stuff in Trello and take it off as if we are short order cooks" and we never meet to reflect on what we've been doing. Very little enthusiasm for process all around. And as everyone knows, Agile has won so thoroughly that it's a meaningless buzzword. Everyone says they're agile even if they aren't. But I doubt I would ever go to an "agile conference", whatever that is.

debreuil• 12 years ago

Technically agile has never been about actual programming, it is a process to plan and coordinate programming. Aka a process to 'manage' programming. So I'm not sure why one would be surprised that managers have more interest in it than programmers?

jdlshore2• 12 years ago

Agile got its first burst of popularity with Extreme Programming, which was all about programming (and how programmers work with business people). TDD and continuous integration both came from XP.

It's only in more recent years that the programming focus has been stripped away.

tibbon• 12 years ago

As a developer, I want to think about code. If I have the choice of learning something new, or digging into a new skillset it is going to be about code- not project management.

The last thing I feel like doing is sitting in a conference of non-technical people talking about how some new funny words they made up in project management will fix everything. Scrum masters, vendors, etc... it all just doesn't really engage me any more than talking about concurrency gets a project manager going.

This isn't to say that I don't think PM isn't important, but just that it really isn't a terribly interesting problem. I haven't seen (personally) that many scenarios where some new trick from a PM book, class, conference has actually made the difference in a project coming in on time/budget.

I personally like a lot of Agile stuff, but I don't strictly adhere to any specific one, nor do I want to in a small team. I just want to produce good code.

doktrin• 12 years ago

As a developer, I want to think about code. If I have the choice of learning something new, or digging into a new skillset it is going to be about code- not project management.

Obviously this.

I suppose I might attend an agile conference in the unlikely event my employer desperately wanted to send me to one. Even then I'd probably try to discourage them from the notion in order to get the money spent somewhere more productive (technical conferences, specialized training, etc.)

praptak2• 12 years ago

I see an analogy between what happened to Agile and what happened to "Object-oriented". Both were, at a time (IMHO) genuinely useful, fresh and thus popular with developers.

Both got a bit overdone (Java: everything must be a method of an object!) and hijacked by the Certified Formal Methodologies people and pointy-haired bosses. People found the limitations of both Agile and Object-oriented - there's no silver bullet after all. The good things got incorporated into the set of good practices (and became obvious and thus not worth mentioning) the bad things are labeled as bad (although some stick with us.) Life goes on.

Agile is obviously a bit earlier in this lifecycle - I believe there are no mainstream object-oriented conferences anymore while Agile ones still exist.

the_af• 12 years ago

Agreed on your main point.

Isn't OOPSLA a mainstream OO conference?

praptak2• 12 years ago

I think it has lost its OO focus.

gtrubetskoy• 12 years ago

Where did all the developers go?

Into the cloud, perhaps?

bowlofpetunias• 12 years ago

This is not entirely a bad thing, although many of the negative conclusions drawn by the author are true.

One of main obstacles for going Agile has always been that it really needed all of the organisation to change, not just the developers.

Also, Agile conferences aren't really that interesting for developers anymore. We've already adopted most of the development practices to the point where many developers are no longer aware that they came out of, or at least became mainstream because of, the Agile and XP movement.

Most of us are Agile without being aware of it, which in turn leads to hilarious anti-Agile rants (based on experiences with top-down enforced cargo cult "Agile") in which the authors propose alternative practices that are typically Agile and tick all the boxes of the Agile manifesto...

The hard part about Agile is still adapting the entire organisation's processes, which generally is of more interest to management-types than to developers.

Finally, you would be surprised to learn how many people that are active stakeholders in software development processes only now start to learn what Agile is.

For most of us, in our fashions and fads driven bubble end of the industry, Agile is already passé, but for many it's still a revelation.

dieg0• 12 years ago

As a developer and designer I think agile methodology is a nice add-on for traditional workflows in startups. I love how it encourages interdisciplinary work. But I believe it took an unexpected turn towards treating the technical side of things as a mere commodity.

Last weekend I attended Startup Weekend event, looking to have fun trying to build something fast from a simple idea pitch. First day more than 80% of the crowd were business / marketing peoples. Designers were scarce and half of the few developers disappeared during the second day. Maybe I’m a masochist but decided to stay until the end, I figured I’d learn something about the agile event fauna. And I did: in most cases the agile methodology is stepping on top of rational thinking.

Do before you think and fail fast is good, only when you know how to do.

Last time I was on SW I had a lot of fun, but last weekend’s experience was somewhat sad. Gurus and their new methodologies might have some to teach, but will never replace rational thinking.

mattgreenrocks• 12 years ago

Commoditization is already happening IMO; many devs have internalized agile to mean "slap together as many open source/SaaS APIs and then apply duct tape so it holds together."

You'll see this sentiment leak out when discussing the necessity of domain modeling or testing in a mature web app that continues to grow. There's always a contingent that shows up loudly complaining, "but that looks like work! I don't want to!" They believe they have to always be kowtowing to Business by constantly shipping features and patching over what breaks.

As michaelochurch likes to say, we've been colonized by businessmen. Our own ideas about productivity and quality are slowly being replaced by theirs.

joesmo• 12 years ago

Why would one need a conference to discuss a process that should be explainable in 5 minutes. If you can't reasonably explain your development process (agile or not) in 5 minutes, it's broken. If it takes you hours to explain your process, how many days does it take to implement and how much time is left over for actual development? I think most developers see through the bullshit of certified scrum masters and other such nonsense and its detrimental effect on productivity and don't want to waste even more time on this.

eldelshell2• 12 years ago

Exactly. And don't get me started on all the buzz-following-I-never-wrote-two-lines-of-code hipsters at this events.

Oh! And also, Lego. I'm a grown man, come on!

mkal_tsr2• 12 years ago

I saw agile implemented at a smaller team at a large corp. They explained their approach to me in about 3 sentences when I joined as an intern. They had no scum master because they didn't add a scrum master initially so no scrum master felt like his job/role was at stake if he didn't feel important.

EnderMB• 12 years ago

At every single company I've worked at an Agile-like approach was used. This meant that the daily catch-up is called a Scrum, and that instead of working in a Waterfall approach we've created sprints of however long was needed to fit a bunch of tasks in. Also, instead of writing large spec documents that are signed off and given to a developer to implement we create a smaller spreadsheet of deliverables, and later changes are introduced into later sprints.

Naturally, things tend to fall apart when the spec isn't accurate, or when an estimate is off. In a client-facing business like an agency these approaches often fall apart when the client isn't getting something when they want it.

I've interviewed at a number of large agencies and it all seems to be the same. Everyone does Agile...kinda. They have the general feeling down, but they all skip some parts to make it usable for their clients.

This brings me to ask, does anyone REALLY do it properly in an agency setting? If you do it properly in a client-facing industry will it fall apart, or are people just too lazy to fully embrace Agile? I'm yet to hear of anyone doing it well, but I would love to hear from someone that knows how to do it well in a team of 15-20 people containing developers and Project Managers.

blutoot• 12 years ago

Does it make sense to teach someone DevOps?

ww5204• 12 years ago

Some people really don't like this article. It has been flagged off the front page after 3 hours despite having lots of points.

It's interesting to see how negative news about Agile are being censored.

Mindless2112• 12 years ago

There's an article that I am reminded of -- What Killed Waterfall could Kill Agile [1]. Essentially, the developers left once "Agile" started being plagued by elitism.

[1] https://gist.github.com/joshwand/710960

asgard1024• 12 years ago

People still don't get it. There is a really simple antidote to elitism - democracy. Everybody gets the same amount of power, well defined as one vote. If you want to abstain your power, you can - just don't vote.

That way, people who want to do real work can concentrate on it without worrying about power games. Power games become pointless, because the power structure is set to stone. That's why democracy is so effective system - it lets you focus on the job, without the stresses of not having any power. Because you can have it, when you need it.

krfsm• 12 years ago

It turned out agile processes contained a bunch of important but unpleasant aspects - business people needed to be much more present in daily development, while developers needed to meet with business people much more frequently (often at specific times when said business people were available) and keep lots of non-development action points in mind (as the team now had collective ownership of those action points).

So, in a stroke of mutual back slapping, everybody embraced the less objectionable features of agile methods - daily meetings, short iterations, reduce documentation and focus on shippable code - thus feeling really good about themselves. This caused ample moral licensing, letting most development team members and business people cut down on the unpleasant aspects.

This collective ball dropping was fortunately mitigated by a surplus of employees happy to pick up this poor, unloved ball. Being orderly people they would suggest improvements to the process to prevent further ball dropping, carving out a place and title for themselves while they were at it.

Where did all the developers go?

Related Stories