BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Opinion: Take Agile Off Your Resume

by Deborah Hartmann Preuss on Sep 29, 2006 |
Stevey Yegge is an articulate and prolific writer, author of Stevey's Blog Rants. Yesterday he blogged on problems he sees with Agile methodologies under the title "Good Agile, Bad Agile", covering "Good Agile" at Google, "Bad Agile" almost everywhere else, and offering consultants and job hunters some career advice: "drop the name."
Up until maybe a year ago, I had a pretty one-dimensional view of so-called "Agile" programming, namely that it's an idiotic fad-diet of a marketing scam making the rounds as yet another technological virus implanting itself in naive programmers who've never read "No Silver Bullet", the kinds of programmers who buy extended warranties and self-help books and believe their bosses genuinely care about them as people, the kinds of programmers who attend conferences to make friends and who don't know how to avoid eye contact with leaflet-waving fanatics in airports and who believe writing shit on index cards will suddenly make software development easier...

But I've had a lot of opportunity to observe various flavors of Agile-ism in action lately, and I now think I was only about 90% right.... I'll just go right ahead and tell you about the Good Kind, free of charge.
Presently, Yegge is really enjoying "Good Agile" at Google. He likens Google's style to what's more commonly seen at grad school, on an open source project, or in a startup. What distinguishes Google is how they've managed to keep this style on such a large scale.

Here's a summary of Yegge's observations about Good Agile at Google:

  • The organization's structure does have heirarchy, but in practice it seems pretty "flat" - managers code.
  • People evolve processes as they need to (rather than processes grinding down people).
  • Great discipline is practiced with respect to the codebase.
  • "Slack" is built into the system - allowing developers to explore other ideas that interest them.
  • Incentives are linked to the business value of each project.
  • The organization makes it easy to focus on coding - for example, by providing good tools and free meals.
  • People are treated with respect.
  • Requests are simply queued and prioritized.

His summary of Bad Agile, from his own informal poll of colleagues elsewhere, includes these ideas:

  • "[It] focuses on dates in the worst possible way: short cycles, quick deliverables, frequent estimates and re-estimates"
  • This focus on delivery hurts the overall codebase because folks don't pitch in to help one another, and housekeeping tasks fall by the wayside.
  • They're exhausted by the unvarying pace and the unnaturally regular hours.
  • "They're all new, all afraid to speak out, and none of them are even sure if it's Agile that's causing the problem"
  • Those Agile folks are slippery: "evading criticism by embracing anything good, and disclaiming anything bad."
In a related conversation on AgileSoftwareDevelopment.org, Keith Braithwaite asks: "Who is doing the "bad Agile" that's causing relatively high profile developers like Mr Yegge to write things like this?"

Yegge's blog entry is very long, so long it has chapters, sporting titles like "Emergent Properties versus The Whip" and "The Tyranny of the Calendar".  Sprinkled through it are some interesting questions, such as:
Is it true that this is the only other development process? And is Cowboy Programming actually bad?
Is it any wonder Chrysler canceled the [C2] project?
How do we know [XP] is not more productive?
  He concludes:
I worry now about the term "Agile"; it's officially baggage-laden enough that I think good developers should flee the term and its connotations altogether... And frankly, most Agile out there is plain old Bad Agile.

So if I were you, I'd take Agile off your resume. I'd quietly close the SCRUM and XP books and lock them away. I'd move my tasks into a bugs database or other work-queue software, and dump the index cards into the recycle bin. I'd work as fast as I can to eliminate Agile from of my organization.

And then I'd focus on being agile.

Related content on InfoQ: Do Agile Practices Make it an Agile Project?

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

A glimmer of the light is seen by Paul Oldfield

It's nice to see that Stevey has eventually seen a glimmer of the light of what Agile can bring. We'd be doing ourselves a disservice if we didn't admit that there's a lot of 'bad Agile' going on. The description of what works in Google is interesting and encouraging. One need not expect the same combination of tailorings to work in all other situations. Some of the things not done in Google, that he lists as 'bad Agile', are things inappropriate to Google but appropriate in other situations. Stevey hasn't 'got it' yet, but it's nice that at last he's seen it can work, somewhere, somehow.

One wonders how he would feel if, on focusing on being agile, the decision is taken to work in short iterations, have daily meetings to uncover impediments, write requirements at a high level for prioritisation and planning, keep the design simple, etc.

We, the agile community, who have succeeded in being and becoming agile, can tell him what has worked for us. If he doesn't feel happy until he's re-discovered agility for himself that's his choice, I guess. Others get to choose whose advice they would rather take.

And he may do better by putting his focus on delivering value for the organization.

Ouch by Paul H

And we should code after our instinct ?
Basically Steve claims that only a bug tracking tool will do, (maybe i got it wrong but still), i've seen a few projects built like that, but their success depends on the skill of the developer !!! (yeah i meant only one :D), but if there is a team with a lot of people with different skill levels, it will be a failure.

But i kinda agree with his opinion on the "consultants" and "trainning sessions". I'm wondering how 1 day in a "Transaction camp" at x price / day can help someone to understand better etc. (i assumed here that 1 day is not 24 hours :)))))) ).

doesn't good agile also focus on timelines and delivery? by Floyd Marinescu

Steve criticized bad agile for focus on dates and delivery. I thought Agile was supposed to be all about iterative development, and focused on delivery. Unless I am misunderstanding the summary. How do 'good' agile projects treat dates and deliverables diff from bad ones?

Re: doesn't good agile also focus on timelines and delivery? by Deborah Hartmann

Jim Johnson of the Standish group referred to this, too, in our interview. He called what Google does "pipelining", and it sounds like whatever is ready on the next planned delivery date is what goes.

In classic Agile approaches, it's similar: whatever isn't ready on the planned iteration's end is removed from the deliverable.

If I understood the article correctly, the difference lies in expectation setting regarding when a feature will go live. Apparently at Google a feature (story, whatever) isn't tied to a particular iteration end date, so it's just done when it's done.

Re: doesn't good agile also focus on timelines and delivery? by Stefan Tilkov

My view is that a team with good developers will succeed, and it will be hard to ruin the success with a methodology, no matter how bad. On the other hand, no methodology will turn a bunch of bad developers into a successful team.

I often wonder whether Agile is not simply based on the illusion that copying a specific part of a good team's working approach will make success more likely for weaker teams ...

Don't forget by John Brothers

Google has a great, low key process, but there are some things that Steve doesn't mention:

  • Google puts every developer through a very rigorous screening process, virtually ensuring that only very smart, very adaptive, very skilled developers get offered positions. If you were surrounded by coding geniuses, almost any process would seem to work.

  • Virtually none of Google's projects are profitable successes - they're still a "one trick pony" using their slush profits from Search to fund everything else. In companies where success in a certain timeline is a critical requirement for staying in business, I don't think this 'methodology' is tenable.



Now, having said this, if Google were able to deliver profitable projects with this methodology, it might be worth writing up as an example of a "good" methodology, one that we all could learn from.

Re: Don't forget by Jesse Kuhnert

The real question you all have to asks yourselves is:

"do I think I'm smarter than Steve from google? "

I'd guess that in probably 90-95% of the cases the answer would be no. Maybe I'm wrong....

Re: doesn't good agile also focus on timelines and delivery? by Jonathan Allen

I often wonder whether Agile is not simply based on the illusion that copying a specific part of a good team's working approach will make success more likely for weaker teams ...


I think that describes the fundemental problem with every methodology, not just in software development but throughout the business world.

Re: doesn't good agile also focus on timelines and delivery? by Jonathan Allen

I think agile goes wrong when it goes from "short iterations" to "2-week iterations". I have worked on projects where 2 weeks is too short, and others where it is ridiculously too long.

Focusing on "2 weeks" or any other time interval seems to change the attitude from one of "it's done when it's ready" to "it better be done in 2-weeks". It is as if we traded one long death march for a series of short death marches. How many consecutive Scrum "sprints" can you go through without feeling like you are in a marathon?

Questions by Deborah Hartmann

I think there is another question: how did Google get to this state? Being relatively new, I wonder if smart Steve knows the history of the patterns in place there now. Agile process is evolutive... Google's process probably didn't start out looking like this.

I wonder how it got here?

I wonder what its roots are?

Re: doesn't good agile also focus on timelines and delivery? by Stefan Tilkov

Reginald Braithwaite has a great post on this issue, too.

Re: Don't forget by Muhammad Haggag

>Virtually none of Google's projects are profitable successes -
>they're still a "one trick pony" using their slush profits from
>Search to fund everything else. In companies where success in a
>certain timeline is a critical requirement for staying in
>business, I don't think this 'methodology' is tenable.
This is untrue. Almost all google projects have attracted a huge user-base, which is their #1 asset.

Re: Questions by Jesse Kuhnert

Are we talking about product development or software development? One of us seems to be confusing the concepts, or maybe you see them as being the same thing?

I don't know, I've seen this(or similar..i mean let's be real, no one but google/microsoft/etc is probably doing anything exactly like this ;) ) process used in companies I've worked at in the past and found it to be very beneficial for the end product / client in almost all instances. Do you see a deformity somewhere, do you have criteria to measure your perception of "good" vs "bad" ? Maybe the way in which you are able to switch around on projects gives you the feeling that no one has ownership of each specific product?

I think there is another question: how did Google get to this state? Being relatively new, I wonder if smart Steve knows the history of the patterns in place there now. Agile process is evolutive... Google's process probably didn't start out looking like this.

I wonder how it got here?

I wonder what its roots are?

Re: Questions by Jesse Kuhnert

Oops...My apologies, I see what your original meaning was now..

I view it as more how you might deal with an awkward teenager going through a "phase". Creative smart development types don't normally take to well to any heavy handedness, so if a few get real excited about agile and the upper ups don't agree it's still probably best just to let them get it out of their system naturally. ..And they will, I guarantee it ;)

Are we talking about product development or software development? One of us seems to be confusing the concepts, or maybe you see them as being the same thing?...

What can be done in a day by Paul Oldfield

What one can do in a day of training or consultancy (and I agree that there are some better than others at this) is start a group of people thinking in a different way, and make a start at showing them how to get better results by doing this. If they can't, or won't, use that new way of thinking to start changing the way they do their everyday work, then the value of that day is seriously diminished.

Agile and appropriate by Paul Oldfield

I often wonder whether Agile is not simply based on the illusion that copying a specific part of a good team's working approach will make success more likely for weaker teams ...


I think that describes the fundemental problem with every methodology, not just in software development but throughout the business world.

Definitely. Any agile approach 'out of the box' is a collection of synergistic good practices that have been found to work in other situations. There is no expectation that this set would be the best in any given situation, but they are expected to be a good starting point compared to other possible starting points.

One needs to work out what is appropriate in a particular situation. One may choose to do this by starting at a good starting point, then reflecting to see what needs to be improved.

In response to several of the other comments on this thread, I have heard stories from several organizations that made a really serious attempt to get the best process (including a genuine CMM level 5 shop). Two things in particular seem to stand out as common: First, the eventual process turned out to be very agile, thogh rarely very similar to any of the published approaches. Second, they put their personnel selection process as very important, if not the most important part of their whole process. As someone from the CMM level 5 shop said to me; get that right and all else falls into place.

My summary: go all out to find what's appropriate for you, and you will end up with something that's agile. It may not look like any published approach, but it will be very good for your particular situation.

Good people make good process by Deborah Hartmann

Yes, Reg quotes St. Exupery (of "Petit Prince" fame):
If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.
In the original post, I'd say that Steve Yegge shows passion for his work. If all his colleagues likewise value good product and excellent work, and with the management support mentioned, it's not surprising that their process should have evolved into something sensible and effective.

Google's focus on product also surely drives this... this product alignment is one of the great benefits of Lean and Agile approaches, which are not explicitly captured in the individual practices, and in fact may be more important than the practices.

Re: doesn't good agile also focus on timelines and delivery? by Deborah Hartmann

I'm not clear on whether the problem you see is...

a) requiring that iterations all have a standard length, or

b) deciding prematurely on the standard iteration length (ex: it has to be 2 weeks, or

b) fixing iteration end dates at all?

I'm not sure what you've encountered, but most leaders I know suggest a relatively arbitrary iteration length to start, and teach the team to understand how changing length can impact their work. After that, it's inspect-and-adapt.

Resume ... by Jim Standley

I'm curious, has anybody been tracking phrases like "Knowledge or experience with Agile, Scrum or eXtreme programming methodogies (a big plus)" on job boards?

Maybe so... by Paul H

What one can do in a day of training or consultancy (and I agree that there are some better than others at this) is start a group of people thinking in a different way, and make a start at showing them how to get better results by doing this. If they can't, or won't, use that new way of thinking to start changing the way they do their everyday work, then the value of that day is seriously diminished.


If we take a particular technology, usually such a trip (for training etc) takes a lot as in cost, so is cheaper for the employer to pay for the individual research (at least from where i'm standing).
So lets forget the financial part, and see a few others, i wouldn't put on my "resume" such a training, no offense but i would be embarrassed.
A new way of thinking, no way, usually you change it as a result of the amount of work (as in years of experience) you busted, not because some hot shot tells you.

Back to the subject, from what i saw, agile works with smaller projects (or big projects broken into modules), short iterations yeah a big plus for feedback, buuuut the biggest drawback i can think of is the need for changing requests (a client must understand what can be done quickly and without a mess and what affects the entire project or a few modules), so if you have a rule like, okay we'll analyze it, then we'll give you a response, after that you take your pick and agree with the delays, extra costs bla bla, and we'll move on, then it should be ok.

Re: Resume ... by Paul H

jobs.joelonsoftware.com/default.asp?595


* Excellent communication skills and ability to work as a team player.
* Familiarity with Scrum/Agile processes a plus

Re: Resume ... by Deborah Hartmann

...has anybody been tracking phrases like "Knowledge or experience with Agile, Scrum or eXtreme programming methodogies (a big plus)" on job boards?
I get alerts from monster, and sometimes pass them on to friends. I see "Scrum" a few times a month... too often accompanied by "skill with MS Project" and "RUP expertise".

Monster alerts for "agile" are useless here - one of the big Canadian banks uses the term on every single job posting - whether or not they have anything to do with software or even systems. You know: "honest, hardworking and agile" or some such.

Headhunters are occasionally calling, too, looking for "an Agile RUP BA" or "a senior Agile PM" though they seldom realize that Agile is not a language... and they think "senior" is determined by years in the business, not how long one has been applying Agile. lol ;-)

I've yet to hear of anyone getting a job working with an Agile team through those job boards... in my experience, teams doing "good agile" have good retention, and tend to hire by word of mouth when they need to... because they know that quality people are essential to good process.

Re: Ouch by Scott Ambler

Last week I attended a 1.5 hour talk given by someone explaining agile/lean concepts. In small groups we did a couple of exercises where we developed something as a team first following a serial approach then second following an agile approach. At the end of it a lot of people seemed to get some of the fundamentals. Did they walk experts at agile? Of course not. But they did learn something and I suspect that they're motivated to go learn more.

- Scott
Practice Leader Agile Development,IBM Rational

Re: Resume ... by Nicole Comer

Good evening. As a recruiter who is currently looking for strong project managers that understand agile methodology and iterative development I find it increasingly valuable to have it remain your resume. It allows me to ask the right questions to know if you added it to your resume or if you have expereince. But on the subject of excellent PMs who don't move onto new projects. My client has just started with a firm in Philadelphia as a new principal. He has traditionally run his IT shops using Agile methodology (FDD, SCRUm, running Sprints)and is transitioning his new organization. If you know of any great PMs I would be happy to speak with them. Thank you.

Nicole Comer
610.345.0043
nbcomer@cerecruit,com

Re: doesn't good agile also focus on timelines and delivery? by Amir Kolsky

One of the things you learn to do as you go agile is to break down the job at hand to small stories. It takes getting used to, but the stories are usually small enough to be completed by the team in a day or two at most. This means that the length of the iteration can be kept down to a week or two.

If you need longer than that it means that you are not breaking down your work correctly -- time to learn something new :-)

Re: Resume ... by Neil Dodson

Yeah. Great stuff Nicole. Anything else to contribute?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

26 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT