Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
The moose likes Agile and Other Processes and the fly likes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark ""Agile" is cheating" Watch ""Agile" is cheating" New topic
Author

"Agile" is cheating

Alistair Cockburn
Author
Ranch Hand

Joined: Feb 21, 2002
Posts: 43
I posted this in another thread - thought it needs it's own thread...
I found myself these last 3 weeks describing "agile" software development as "cheating legally to win".
When I tell people how to play agile, someone in the room almost always comments, "but that's cheating!"
So "agile" is finding ways to deliver the software without having to go through some "standard" procedure, i.e., cheating.
Hiring good programmers, putting them in a room together, forgiving most of the documentation, letting them talk to users and deliver code every few weeks - those are some of the cheating tactics that agile people use. As soon as we find more, we'll use them.


Alistair Cockburn<br />acockburn@aol.com<br />Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0201699699/ref=ase_electricporkchop" target="_blank" rel="nofollow">Agile Software Development</a>
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4442
    
    5

Not quite sure I see how it could be called "cheating"
What "rules" were broken? Of all the cheating tactics you mentioned, only "forgiving most of the documentation" seems to me as being close to breaking the rules of the "standard" methodologies.
Thanks,
Junilu
Joe Gilvary
Ranch Hand

Joined: May 11, 2001
Posts: 152
Do any "standard" methodologies even address
office space for programmers? I have done work for some
companies whose process explicitly prohibited direct
contact between programming staff and the intended users
of the software. I can't put the name to that methodology
(my ignorance), but I saw it in place at one very
large, well known company.
Thanks,
Joe
Alistair Cockburn
Author
Ranch Hand

Joined: Feb 21, 2002
Posts: 43
Actually, it's the "hire good people" like that most often gets the "that's cheating!" line.
Hire a small handfull of good people, and you don't have to worry about process at all - they'll take care of the issues all by themselves.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4442
    
    5

Originally posted by Alistair:
Hire a small handfull of good people, and you don't have to worry about process at all - they'll take care of the issues all by themselves.

But isn't this a pipe dream for all but the luckiest/best?
For one thing, there's almost always going to be somebody stupid on the team and more often than not, it will be the PHB.
And even when you do, by some outrageous stroke of luck, find those "few good men (and women)", wouldn't it be necessary to just leave them to their own devices, to let them figure it out for themselves? How many managers would be comfortable with that idea?
Is there no hope then of agility for the rest of us?
Junilu
[ February 21, 2002: Message edited by: Junilu Lacar ]
Doug Wang
Ranch Hand

Joined: Oct 05, 2001
Posts: 445
Alistair,
What is the secret behind "cheating"?
So the success of agile process depends on small handful of good people you hired, nothing else.


Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep
Alistair Cockburn
Author
Ranch Hand

Joined: Feb 21, 2002
Posts: 43
Cheating... and Good People...
I'll answer here from another thread also - - - There is this misconception that Agile only works with topnotch people. This isn't true. I've never had the luxury of working only with topnotch developers - I've always worked with a mix of people. Therefore, I can say from first hand that the "Agile only works with top people" idea is a misconception.
However, and there are two howevers...
Recall in my book it describes 3 levels of practitioner: (1) those just learning, who need a technique to follow, (2) those learning how to break out of a specific technique, (3) those fluent enough not to care about which if any technique theyr'e using.
However(1): You will need at least one Level 3 person on the team. Because there will be some improvisation. After that, put on the normal crowd. Of course, I view that if you don't have a level 3 person anywhere on the team, you're sort of doomed no matter what process you're using, so actually, this is just business as usual.
However (2): With regard to cheating, obviously the more level 3 people you can put onto the team, the faster the team moves. That is also true in all cases, and so is again business as usual.
The difference, I guess, is that the Agile group *announces* that you must have at least one Level 3 person on the team, whereas the other groups *pretend* you don't need any such person.
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1441
Do other groups (and who are these groups?) really pretend you don't need good, senior people to help assure success. I can see where this is ignored because it is so obvious that it is easy to overlook but pretending implies that someone knows that this is important/required and chooses to ignore it. Definitely a good step towards failure.
Can you cite any examples? You can change the names of the other groups to protect the guilty, if necessary!
John


The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1441
BTW, isn't "cheating legally" an oxymoron?
I'd prefer to think of it as intelligently ignoring those aspects of the game that do not contribute to you playing well and winning.
Or maybe I'm getting carried away... :roll:
John
Joe Gilvary
Ranch Hand

Joined: May 11, 2001
Posts: 152
Originally posted by John Wetherbie:
BTW, isn't "cheating legally" an oxymoron?

Didn't Starfleet Academy Cadet James T. Kirk "change
the rules"? Heh, heh.
Joe
ersin eser
Ranch Hand

Joined: Feb 22, 2001
Posts: 1072
I am a good programmer but nobody cheats for me :roll:
Alistair Cockburn
Author
Ranch Hand

Joined: Feb 21, 2002
Posts: 43
Originally posted by John Wetherbie:
BTW, isn't "cheating legally" an oxymoron?
I'd prefer to think of it as intelligently ignoring those aspects of the game that do not contribute to you playing well and winning.
Or maybe I'm getting carried away... :roll:
John

You are quite correct, John. I only say "cheating" because when I tell other people how we do agile software development, that's what they tell me - "But that's cheating!" So I conclude I must be "cheating", but legally somehow.
What it really means is detecting that some "rule" isn't really a rule, and so can be bent or broken.
Alistair Cockburn
Author
Ranch Hand

Joined: Feb 21, 2002
Posts: 43
Originally posted by John Wetherbie:
Do other groups (and who are these groups?) really pretend you don't need good, senior people to help assure success. I can see where this is ignored because it is so obvious that it is easy to overlook but pretending implies that someone knows that this is important/required and chooses to ignore it. Definitely a good step towards failure.
Can you cite any examples? You can change the names of the other groups to protect the guilty, if necessary!
John


Barry Boehm of great software engineering reknown just wrote a paper for IEEE Computer comparing Agle and Planned approaches. He wrote a table in which he made just that claim. After soveral rounds of email, he agreed to dilute his claim somewhat. So yes, and he was putting it into print very out loud. (I haven't seen the Jan issue to see what he finally wrote).
shailesh sonavadekar
Ranch Hand

Joined: Oct 12, 2000
Posts: 1874
Alistair , what claim Barry Boehm made ? did he said that good people are not required ? surprising. person who developed win - win model as an extention to spiral development & COCOMO model saying so .
Jim Baiter
Ranch Hand

Joined: Jan 05, 2001
Posts: 532
I really like the approach you are offering with Agile especially in the "no fixed process per project" rule. But do you think there could be a "cafeteria" of processes in an organization from which projects could choose?
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1441
Having a cafeteria of processes, or elements of processes, methodologies, etc. could be very helpful. The most important aspect would be that it would be a means of informing people what is out there and good and bad points.
It occurs to me, though, that the organizations best equipped to develop and have this available are the ones most tied to heavyweight processes and don't necessarily see the value in agile approaches or having different projects use different processes. Conversely, the groups that might make the most use of this don't have the financial ability (and/or enough process, isn't that ironic) to do it probably. It's a puzzlement...
John
Rich Cohen
Greenhorn

Joined: Oct 01, 2001
Posts: 6
Originally posted by Alistair:
Actually, it's the "hire good people" like that most often gets the "that's cheating!" line.
Hire a small handfull of good people, and you don't have to worry about process at all - they'll take care of the issues all by themselves.

Forming a team of good people and leaving them to solve the problem seems like the extree essence of agile, lightweight methodologies. The likely success of this scenario stems in part from the likelihood that these good, experienced team members understand (explicitly or implicitly) the critical, important aspects of team coordination and software development, having addressed practical solutions to these issues in the past, and can be expected to work together as a new team to establish common solutions among themselves -- without requiring an externally-imposed heavy-weight methodology. You could say you don't need to dictate a light-weight methodology to the team, because they will quickly evolve one themselves. Part of the advantage of having an explicitly defined process is that new or less-experienced team members and contribute and learn along the way.
Alistair Cockburn
Author
Ranch Hand

Joined: Feb 21, 2002
Posts: 43
Originally posted by shailesh sonavadekar:
Alistair , what claim Barry Boehm made ? did he said that good people are not required ? surprising. person who developed win - win model as an extention to spiral development & COCOMO model saying so .


Well, he's changed it now. Originally, though, he wrote that the "home ground" for agile vs. 'plan-based' development are:
Home-ground area for:
- Agile methods
- - Developers
- - -> Agile, knowledgeable, collocated, collaborative
- - Customers
- - -> Dedicated, knowledgeable, collocated, collaborative, representative, and empowered
Plan-driven methods
- - Developers
- - -> Plan-oriented, with a mix of skills
- - Customers
- - -> Mix of capability levels
In other words it was a "set up": you'll never get good enough people to apply agile methods, but you can use any normal mix with plan-based.
Obviously I disagreed, and he agreed with my disagreement enough to make some modification.
Alistair Cockburn
Author
Ranch Hand

Joined: Feb 21, 2002
Posts: 43
Originally posted by Jim Baiter:
I really like the approach you are offering with Agile especially in the "no fixed process per project" rule. But do you think there could be a "cafeteria" of processes in an organization from which projects could choose?

A bit of a rephrasing perhaps...
The OPEN process consists of an kit bag of process parts and techniques you might like to use, but you have to put it together yourself. I don't think people can do this "putting together".
The RUP process consists of a truck full of process parts put together for you, but you have to whittle it down to the size you need (ever try making a motorcycle from a truck?). I don't think people can trim it down enough.
The naive Crystal process consists of not enough parts and you have to add to it to make it full. I doubt whether most people can name the necessary parts needed to add and put them together.
The newer Crystal process consists of examples from other projects yours might be similar to, so you can copy and modify from that. There are only three in the literature to choose from, so it's pretty thin pickings.
There is some question in my mind as to whether there is ANY solution anywhere that will work - I constantly bear in mind that there might be no answer. Obviously the newer Crystal process is where I'm putting my money for the best next (9th?) guess.
Gerry Giese
Ranch Hand

Joined: Aug 02, 2001
Posts: 247
We all have problems defining a successful software development process. No matter what process(es) you pick and/or modify, there are numerous monkey wrenches, gremlins, pointy-haired managers, and <*GASP*> customers waiting in the wings to muck everything up, at least from the software developer's point of view.
The whole problem is that there are so many variables, known and unknown, with any given project that the permutations are endless. Each process, or methodology, or whatever you want to call it, attempts to corral and contain as many variables as possible. When you control the variables, your end product becomes more predictable. What makes things difficult is that the most important variables are the hardest to contain - the people.
Software projects always have a fairly well defined set of resources. In my opinion, unless you work for a R&D lab attempting to "discover" something, a poorly defined set of resources is a sure sign of a project that is going to fail. For most projects you an apply some of the generic processes to your resources and you probably have a better than 50/50 chance of success. Pick or tailor the process to the resources and the chances go up. If you have the freedom to pick your resources (most project don't) your chances go up.
Here's a high-level list of variables that I see affecting software projects, along with a few sub-factors, in no particular order:
  • Time
  • Money
  • Developers (Experience, Training, Communication)
  • Customers (Experience, Communication, Stubborness)
  • Problem Definition
  • Solution Definition
  • Tool
  • Politics
  • Development Process

  • These variables are influenced throughout the project, from inception to completion (if it completes) by people internal to and external to the project. We, as software developers (I'm assuming my audience here), influence all of these variables in one way or another, whether we know it or not. Often we get direct control over several items, but usually we have to settle for indirect.
    Earlier in this thread one of the variables talked about is on the resources side of things - experienced Level 3 developers. I submit that a Level 3 developer can sink your ship just as easily as not having one at all. I've seen it happen! I haven't read the book describing these levels yet, but there are many many facets to a developer, so I hope that this is listed as only one checklist item of many for developer selection, rather than the only one.
    Yes, you need "good" developers, but they come in all shapes and sizes, and I think you can still build good software whether you need a specific technique or are just starting to explore others. Having lots of tools (techniques) in the toolbelt is a plus, but having only one doesn't spell doom.
    One of my criteria for a "good" developer is the ability to learn and adjust quickly. This is subtlely different that what I was reading earlier, which suggests technique quantity rather than ability to pick up new techniques. I watched a kid right out of school with a limited number of tools pick up several new things over the course of a project and become the MVP. I've seen a long-time COBOL programmer get a chance to do something new and excel. I've seen the other side of the coin, too. Learning ability is difficult to gauge, but it can be done, and just as important I think we need to teach developers (and others!) *how* to learn, or learn better.
    I find some of the "agile" methods to be intriguing, and have seen some of them in various projects. Co-locating developers and customers is great, and it's highly likely that the problem solution will be correct and timely. What I've found/seen, though, is that they need to be taught how to work together and effectively communicate. I'm guessing that this is what is meant by 'collaborative', but just because accountants work well with other accountants doesn't mean they can work well with software developers, and vice-versa. Lingo (language, terminology), expectations, and preconceptions/assumptions need to be addressed and overcome for truly effective and accurate collaboration.
    I also like the fact that "agile" says you can go outside the box to do something not usually allowed if there is good reason, but on the other hand knowing when it's appropriate to go outside or not is difficult to do. I've been in both positions, where I was asked to do something a certain way that I knew would take many times longer and provide no real benefit, and where I went outside the box on one item and subsequently learned that there was an excellent reason why I shouldn't have.
    I'm not sure if "agile" addresses this, but one of the things I like about XP is the pair-programming aspect. If you're going to 'forgive' documentation, having two people agree on code design (naming, flow, etc) is more likely to produce code that somebody else can follow and maintain. Peer reviews of code (not manager reviews necessarily) are another method to produce good code, and I endorse this as well, especially as a learning tool for developers who are not highly experienced in the language used.
    I still think that documentation is important - the trouble most developers have is they don't know how to do it well. Using prescribed requirements for documentation isn't the solution. This sounds weird, but using "agile" documentation methods is important. Choose the best ways to document what you're doing, be consistent, and be concise. Training developers to write good documentation is difficult, but when they 'get it', the quality and effectiveness of the documentation goes way up.
    I like the idea of using project case studies to show process examples. Case studies where everyone involved is truly honest makes really useful knowledge sharing. I hope that the lead 'historian' of the case studies is willing to be unbiased, to see not only where the process succeeds, but where it fails, and to be able to try doing the same for other processes to get a frame of reference. Being able to go back and document studies from subsequent projects of previous case studies is extremely helpful, too, if possible.
    "Be like water, my friend" - Bruce Lee. I like the spirit of "Agile" from what I've read/heard, but find that I'm worried the more defined it becomes, the more vague and less agile it really is. All I have to say is keep an open mind, learn from your mistakes and those of others, and strive to improve without over-analyzing everything. 'nuff said.


    CJP (Certifiable Java Programmer), AMSE (Anti-Microsoft Software Engineer)
    Author of Posts in the Saloon
    Gerry Giese
    Ranch Hand

    Joined: Aug 02, 2001
    Posts: 247
    Doh!! Did I write all that? I decided to go back and look at my post and wowee did I write a lot.
    Question: If you're required to produce UML documents as a project deliverable, but can pick your process, which process and which pieces of the UML do you choose? If you can use "Agile", how detailed could/should you get without 'breaking' the process?
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: "Agile" is cheating
     
    Similar Threads
    Explain Agile to management in 30 secs
    What is agile ?
    Art of Agile Development - Mastering
    Xtreme Programming
    what is advantage agile over other methods