Slashdot Log In
You Call This Agile?
Posted by
Hemos
on Mon Nov 20, 2006 01:25 PM
from the the-perils-of-development dept.
from the the-perils-of-development dept.
JoelonSoftware's most recent piece is about some of the fallacies in "Agile" software and some of the issues within it. We use Agile in some parts of the company, and have had success with that -- that said, there's always the peril that happens when development and other parts of the company have...miscommunication, which sounds like the problem described in Joel's piece.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
process first or business first? (Score:4, Informative)
We go through this all the time. (Score:5, Insightful)
a. I don't have to support it.
b. It doesn't have to work.
Yes, that's funny, but it is not a joke. Processes are supposed to be about functionality and maintenance. A one-off app for a critical issue today doesn't need a process (except how to delete it tomorrow so it doesn't become part of they real system).
And that is where marketing and development differ. Marketing sees the opportunities in selling "support contracts" for code that was rushed out, filled with bugs and features that don't work.
Development only sees problems that they're going to have to fix. And fix today. And fix in the quickest possible way because the customers are complaining about a critical issue. And so forth.
So the various processes (and project managers) are supposed to translate/support both views. Get it out in time to make the sales, with a stated minimum level of functionality and no more than X bugs of various levels.
But, as you noted, it is easy to follow the process as the religion instead of recognizing that it is just a means of getting product ready for shipment so it satisfies marketing, the developers and the customers.
Parent
fallacies don't exist within methodologies (Score:5, Interesting)
I think one of the blessings and curses of methodologies, in this article's instance, "Agile" (ha!), is they are their own universe. So, unless there is something within the methodology that is self-contradictory methodologies don't have fallacies. Methodologies are theses, usually tepid ones at best.
Methodologies are someone's or some group's or some company's idea of a way to successfully accomplish a task, project, etc. Fortunately for all who sell these (vapor)wares, methodologies never fail, they merely suffer from those who have improperly used them.
Methodologies then become the convenient whipping boy for work not done satisfactorily. Sigh.
Peel away the layers, eventually it all still boils down to knowing what you want to do, knowing how to do it, and doing it with a strong instinct for balancing things that matter and things that don't. Methodologies won't do that for you, good project managers will.
(Some of the very best and most successful projects I worked on were with a friend who I consider to this day to be one of the best project managers I ever knew (and I knew many). He used no methodology, but had incredible instincts and a strong will. He knew how to handle time frames, important (and not-so-important) crises, difficult workers, and how to prioritize. It's a shame he didn't get better recognition - he might have had he "used a methodology". I found it ironic he was ostracized/admonished by the company, but he continued to be their go-to guy for the important work.
Bottom line, "Agile" isn't. But "Agile" is just one of a long list of bit players for methodologies in IT.
Re:fallacies don't exist within methodologies (Score:5, Interesting)
In defense of "Agile", it can be (agile). But it takes the right mindset from the developers, project manager, upper management and customers. Agile will not succeed in environments where anyone in that chain does not have the "Agile" mindset.
-Rick
Parent
Re: (Score:2)
In one sentence "Seven Habits" is-- know what's important, know what's not, only work on the important. That's a big over simplification that doesn't do justice to the book.
I recommend that every developer read "Seven Habits." Developers aren't the only people in the world who have to manage long and complicated projects. You'd do y
Re: (Score:3, Interesting)
At the risk of being modded down... (Score:4, Insightful)
Yes, it is nice to have a dogmatic approach to programming, but ultimately it really boils down to "what course of action will have the greatest benefit to the company?" It has always been this way (even outside of software development) and it always will.
Or to Quote Sponge Bob... (Score:2)
Re: (Score:2)
"Or as we like to say it, the Krustomer"
Re: (Score:2)
Even if you refactor "those making the decisions" to the company, you can't get away from the fact that if you can alter perceptions of the decision makers, you completely alter the course and outcome of the project.
Re: (Score:3, Insightful)
People still think adding people to a project will in and of itself accellerate a project. They are wrong. Yet we do it over and over again.
My question is, if supporting version 1.0 of an application is business critcal and developing vers
Re:Captain Obvious and his sidekick, Common Sense (Score:4, Interesting)
But the thing of it is, you see, is that Project Management has trouble seeing the obvious, and needs a regular kick in the pants.
I am regularly asked about how long some feature or other will take to implement, and generally give a response in terms of man-days or man-weeks. What's fun is to see how this is interpreted by a Project Manager.
"This feature will take 5 man-days to implement."
Manager: "So, it will be ready on (20, 1, 2, 3, 4, 5...) the twenty-fifth. I'll put that on the schedule."
"No. I said 5 man-days. That's not the same as calendar days, and we're shut down the 24th and 25th."
Manager: "Oh, right. So, next Tuesday, then."
"No, I said man-days, which are not the same as calendar days. We don't have any one who can start on this at once, and everyone already has work to do."
Manager: "Oh. Well, can you start on this tomorrow, then?"
*SIGH* And these are the folks who are creating all the pretty PERT and GANTT charts for senior management.
Parent
Summary author on crack? (Score:3, Insightful)
Miscommunication? He's talking about context switching, which is an all too common and necessary evil in small shop development.
In any given week I can switch from architecture design to business systems analysts, back to VB6 coding for legacy app maintenance, up to
All that context switching definitely has a negative effect on my productivity. My supervisor asked me to tag tickets with time estimates when I closed them out. No biggie, but the shortest I'll tag a ticket for is 30 minutes. Originally I had said 1 hour, but my supervisor vigorously disagreed with my estimate of context switching's effect on productivity.
-Rick
Re: (Score:3, Insightful)
When doing planning-phase time estimates, our mantra is "Everything takes a day".
A whole pile of little things in the same part of the same project might get done in a day, but if you're going to bother getting enough about a particular context into your brain to do real work, you better have something to do wort
The real advantage to Agile... (Score:5, Interesting)
The real advantage is illustrated in the age old swing cartoon [uoregon.edu]. By using scrumm and delivering sprint demos often to the user, they can see how their money is being spent, and can present requirement changes to the user faster, thus eliminating the need to make resounding changes right away... Agile development anticipates requirement changes, instead of ignoring it like past methodologies. Is it the best? Probably not... is it a step in the right direction? You bet your ass...
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
You're bang on with that assessment. The big issue though is that this type of thinking is near-impossible to sell to anyone, anytime, anywhere.
Re: (Score:3, Informative)
Dunno, I would think in that case you'd want a more heavy-weight process, with lots of QA and regression testing. I mean, it's not like there's a guy sitting in a doctor's office with a CAT-5 cable plugged into his chest, waiting for you to download PaceMaker 1.1-A...
Joel has capacity to speak his mind (Score:5, Insightful)
Aglie development works, but only if people can be trained. Training is something that is omitted when it is decided on whatever model you want to adhere to. Remember we are all just animals and the more training we get, the better we are at it.
Agile process is based on feedback, and therefore programmer must be trained to appreciate and nuruture feedback from his practices too. Programmers need candy too, for rewards, and that candy is a feedback from wroking code. Given, if you are writing a disk driver, feedback is limited, compared to game developer, writing graphics or sound enegines. What Agile brings, is that rewards come at a steady pace, therefore propping up motivation of developer from development side of things. Disk driver developer must find his way to recieve rewards from developing driver code, perhaps thats why compensation is higher for the driver developers, because work has no immediately accessible of stimuli and chances to get negative stimuli, like corrupt disk of the user, are quite high.
If you code not for the sake of itself, I pitiy those people. But then they aren't on the slashdot.
Re:Joel has capacity to speak his mind (Score:4, Interesting)
is to focus project leaders on stopping trivial interuptions of the
" who knows how to load paper " and " could you check over my presentation"
type which will happen 10 times a day if there was no rule.
Worse the avergage program will load the paper or check the presentation
thus reinforcing the "its ok to interupt these guys there only programmers"
attitude.
If you have a rule and a fancy methodoligy its easier for the project
leader to field interuptions without appearing rude and unhelpful.
I used to go to the secure telecoms room when I had serious stuff to do
as hardley anyone had access, nearly always got a chill from the AC though.
Parent
What universe did this come from? (Score:5, Funny)
Leakage from an alternate universe far from our own?
Okay, it's a universe very close to our own.
--Rob
Re: (Score:3, Interesting)
Where do you work, and where can I submit my resume??
Re: (Score:3, Informative)
Re: (Score:3, Funny)
At least we get to 512 or even 1 Gb of RAM most of the time, as we believe it's critical for developers (we usually buy memory upgrades to lengthen the life of most PCs).
I think we'll donate to you next time
I hope you're not in the US or Canada.
not Agile (Score:5, Insightful)
Also this aversion toward "context switching" isn't particularly Agile. The idea behind TDD, evolutionary design, and small time-boxed tasks is to work in small chunks. I would argue that the ability to "context switch" developers while still developing value incrementally is the whole point of the Agile approach.
Part of the ongoing feud with the Rails camp? (Score:3, Interesting)
Re: (Score:2)
Re: (Score:3, Insightful)
There are a lot of valid complaints about Ruby's speed (although Rails can do pretty intelligent caching); I'm not aware of anyone really attempting to push Rails' scalability to the level that Java can do. I'd disagree with the description of DHH's rants as "FUD," though, by and large. His response to Joel's critique of Rails was that, basically, "I don't think it will scale!" is in a certain sense always FUD -- unless you know of a syste
Not a black and white discussion.... (Score:3, Insightful)
Really what any organization should do is instill the resources and culture for proper QA and operational support for developers. If calling the original engineer is the _last_ resort, because QA didn't catch a bug and operations can't fix the problem, thats fine. All too many organizations, however, have an engineer getting called first for a problem that probably should have been caught by QA, or that should have been caught by the operations people. Engineers hunting down problems and finding a reproducible case constantly is really what kills productivity. If the culture is "don't worry, if its broken the engineer who made it can take time out of their current projects to fix it", then your organization is broken.
Context switching, aka, incompetence (Score:3, Insightful)
Why do I see Joel constantly talking about how disturbing it is to "context switch", when sysadmins like myself are expected to handle a dozen or more tasks, most of them "surprise" stuff, daily? Don't tell me "oh, programming is complex"- so are networks.
So, you get unlimited M&Ms, a 30" screen, aereon chair, and get all upset when you spend an unexpected 2 hours out of your 8 hour workday on an emergency, one a week or so. Meanwhile, I'm working on whatever was left in the IT supply room, have to carry a pager, work 10 hour days because I'm doing 2-3 people's jobs- and I've got a half dozen long term project goals...but I'm getting bugged HOURLY to fix the most trivial shit by programmers who can't be bothered to stick paper in a printer?
If Sarah was a sysadmin and had to waste a day collecting her thoughts after spending two hours fixing a mysql database, she'd be fired. You programmers need to stop behaving like prima donnas.
Re: (Score:2, Funny)
if anybody needs me, OR WANTS TO APOLOGIZE, i'll be in my trailer.
Re: (Score:2, Funny)
Re: (Score:2, Insightful)
Context switching considered harmful (Score:3, Interesting)
Used to be, there were generalists writing code. It was possible for one person to understand security, IO performance, database design. Not any more. Now, projects, even individual applications, are too complex to be understood by one person. This forces specialization. Back in the day, system administrators were often the in house generalists, accepted as relatively unproductive coders, but peers in the architecture process.
Nowadays system administrator
Re:Context switching, aka, incompetence (Score:5, Funny)
So why not become a programmer? Apparently, you'd work less hours, have better conditions, a better defined job, and not get interrupted all the time.
After all, I'm sure programmers' jobs are easy. Just make the switch.
In the meantime, junior, pipe down and fix the mail server.
Parent
Re: (Score:2, Insightful)
That's not to say that sysadmins don't have a lot on their plate. However, would you rath
Re: (Score:3, Funny)
Re: (Score:2)
You're a sysadmin. In case you forgot, that means you're supposed to administrate the system. (Since when was a printer not part of the network?) You are a suppor
Re: (Score:2, Funny)
Re: (Score:2, Funny)
Re: (Score:3, Insightful)
Simple solution really ... (Score:4, Insightful)
Then, find the developers who are good at maintenance programming. I hate working on long projects with the associated paperwork and spending long hours working with the customer trying to tweak a table. Even Scrum requires some process work outside of development. I prefer maintenance programming that gives me a chance to know many, many systems at a high level and then dig into them when there is a problem. This lets me contact Susie for a 5 minute discussion, and then her get back to her project. There are fewer processes because the fix is often smaller, and it has to be done now. It's amazing how many processes get circumvented when customers can't use an app.
The advantage is you get staff members who may not know the deep details of individual products, but have more information about multiple products and are not tied to specific resource timelines. Plus you get developers with timelines who get fewer interruptions. I agree that context switching is bad, whether you are a sys admin or developer. Finding ways to reduce it, even if the solutions means I spend four hours fixing it instead of two, can have other benefits. For instance, being able to say 'Hmm...we had a similar problem last month on this other application, I wonder if it is a similar problem.' then asking the developer a specific question.
It's a different mindset, and it's not for everyone. People who do it have to be able to juggle multiple priorities and handle context switching well. They also need to be able to 'see the big picture' more clearly and understand how product A works with product B in detail (since many issues often fall there and result in group A blaming group B and nothing getting fixed.)
They also have to contain their ego and find the challenges in maintenance programming that are just as rewarding as new development. I love being 'the hero' by solving production problems quickly when no one else can.
Harmful implication (Score:2)
For sure, you sometimes need to incur the penalty of "context switching" when customer needs (or any important situation) requires it. But I read that part as suggesting that any programmer who's paid well should expect to be yanked around on a regular basis, putting out one fire
Good, but not good enough... (Score:2)
It sounds like his criticism is that agile methodologies do not do enough to permit flexibility among the developers. The problem is that the waterfall model, or other traditional methodologies are even more rigid. Most of them delay the maintenence phase until either the end of the software life-cycle or until a team can be organized to tackle the issue, and are based on the idea that a small problem be fixed with a well-planned overhaul, as opposed to a minor tweak. Which do you think would be more likely
Description misleading (Score:3, Insightful)
In any case, the discussion between Joel and Dmitri has little or no relationship to the relative merits of Agile methods. Dmitri is just some relatively unknown consultant/guru and his individual opinion is just that. In fact, Joel didn't seem to be dissing Agile methods in general, at least not the way I read it. He is dissing Dmitri's doctrinaire approach.
Moreover, the whole discussion is far from illuminating since it is based on a totally hypothetical example. Give me a real world and specific example where we can get a concrete view of what the real priorities and politics of the situation are, and then we can form an opinion on how to behave. Dmitri in his response to Joel talks about
"trust." But if the customer involved is critical to the company, you can be sure as hell that the project manager would (justifiably) get his ass kicked if he ignored the sales request and got all touchy feely about "trust." On the other hand if this is some nundik sales person then it probably can and should be managed by the project manager.
Ultimately, Agile is all about human-centric. As such, you need to understand that organizational politics and behavior can be just as important to the success of a software project as the programming language you choose. Both Joel and Dmitri seem to be ignoring that.
Reposting my comment on Joel's forums (Score:3, Insightful)
And that sounds right to me. You don't context switch based on getting an email, and you make sure that project managers understand the implications of what they're asking for before you start working on it.
Opportunity Cost (Score:3, Informative)
Sounded nice (Score:4, Interesting)
Problem is his example leave his own "agile" slip showing a bit. His example is as follows:
MS released IE7
This broke a proxy server DLL thingy
Which in turn broke their own Copilot app for a few customers
Which meant he had to divert Ben from a 2 week release, fix the problem, patch the server and delay the release
And this interruption of their agile development was the right decision because it served the customer better
Setting aside the issue of an individual programmer (Ben) deploying fixes straight to production, here's the thing Agile-Ben should have asked: "how the hell did we let the big IE7 release come along, hoze some of our users, interrupt me and probably cause the next release to be delayed?"
Assuming it wasn't part of Ben's agile programming job to regression test and qualify major platform changes for released products, Ben should be saying, "screw this 'it was the right decision to interrupt you' idea. We shouldn't be in the this place to begin with."
Re: (Score:2)
Re:What friggin planet is he from.... (Score:4, Informative)
Of course, he's also a but picky about what he'll accept as a proper "programmer"
Parent