Please, for God’s sake, go with your gut. When you walk into a job interview, say “No, I’ve never heard of Scrum, but I’m pretty sure it’s just buzzwords and stuff.” Then the rest of us won’t have to deal with another clueless cowboy who has never worked a grownup job and craps all over things he doesn’t understand.
I’m not crapping all over anything. I understand now what this stuff is about and that I just haven’t been exposed to it. My lack of exposure led me to thinking that maybe it was just more buzzwords. You guys have set me straight.
This isn’t the pit people. I don’t understand why everyone is so hostile.
I came here for help on this. I wanted to know if I was somehow out of the loop, so I thought that the dope could answer that for me. It’s been answered, but damn people, I never expected it to be answered in such a hostile manner. WTF?
Now someone else will come along and dump on me some more. I’m done with this thread. Thanks for nothing.
You should. It is by the guy who ran the development of OS 360. It is fun to read, and a classic, and should convince you that people back then weren’t so hot. I was in grad school during the structured programming revolution, and thinking in another way about what we were doing made a hell of a difference.
If you read about them, you might find that you actually were using some of them, or perhaps bastardized versions of them. The benefit of reading about them is not that you will march lockstep to the drum of Scrum, but that you will see new and interesting ways of approaching problems you surely have. Then when someone asks you, you might be able to say that you kind of used development methodology X - which is plenty good enough.
Your OP contains definite signifiers of hostility toward the methodologies you’re asking about, so people who use them and like them naturally responded defensively.
davidm I wish you luck looking for a job, it is tough out there but I have feeling this year will be better than last year definitely more jobs about.
As to hostility well we are programmers arguing over minutiae and getting attached to methodologies or programming languages is just part of being a nerd. I remember having a 4 hour argument in my first job about CamelCase, good times.
If you are interested in expanding your coding knowledge and techniques, and I honestly think you will be a better programmer if you do, then take time to read Clean Codeby Bob Martin. This is the one book I give (well put on their Safari bookshelf anyway) to all my new employees on their first day.
Stop your whining and go back and read your posts. Even after it was explained to you, you kept looking down your nose at even the very concept of a methodology, because you’ve never had to know it before. Quite frankly what you need isn’t to go look at Wikipedia long enough to fool an interviewer, it’s a good dose of humility in the face of things you haven’t encountered, and an acceptance that the job market is pretty far ahead of you.
Somewhere around post #2 you should have just said “Wow, thanks guys, I’m still shocked that I’ve somehow missed these new developments from the previous century.” Two pages later and we get the same effect, except you kind of look less smart in spite of getting a free education (which you’re still complaining about… why?).
I largely agree. However, Waterfall SDLCs were, if well managed very front heavy as far as requirements gathering and business/functional design. Many man hours were typically spent hashing everything out before a single line of code was writ. Additional functionality was added as supplementary phased roll-outs. It was almost out of the question for small and mid size companies to devote that kind of time and money with only a promise of deliverables some 3/6/12 months down the road. I had the good fortune to work on very large mainframe projects starting out as a lowly developer.
Now I do Agile and Scrum and whatever else damn thing they come up with next. But I do this from a PM and senior consultant position. I mess with code only out of my own personal curiosity and need to say somewhat up to date with the latest development tools.
All this to say to the OP - Don’t lose heart!.. they may want to cut it out… and they’ll want to avoid a lengthy search. 
Except you found out that you already use this sort of methodology, you just didn’t know that all the cool kids nowadays called it “Agile”. Now when the pointy-haired boss asks if you’re familiar with agile methods, you can just say “yes”, and he can put a check mark next to that box, and that’s one less reason to pick the next guy instead of you.
So yes it is a “buzzword”, but all it is is describing the sort of methods that successful development requires. All standup meetings are is to get everyone in a room regularly for a really short meeting where everyone finds out what everyone is working on. Maybe you already did that at your company, except you didn’t have formal meetings, you just did it at lunch, or at the coffee stand, or whatever. Except lots of places didn’t do that kind of thing, and having a formal policy that this is the sort of thing you should do was helpful for them.
Oh I understand why. Because my experience with Agile/Scrum has been that a lot of the people that thing they’re doing it are almost literally fanatics. IE If they read that you do ‘X’ as part of Agile they do it religiously without understanding why they’re doing it. So you have all these rules and what not about what you’re supposed to do and how this is agile and yet they’re more of a straight-jacket.(And therefore drive me nuts.) Question anything that the dogma says well you can probably guess the rest.
So for example, co-location where everybody sits close enough together so you can talk face to face and get rid of issues quickly. Agile is really big on this. So why is this a problem? Well where I work I have people that instead of actually trying to figure something out they’ll abuse co-location by coming over and asking me or other people questions every 20 minutes.(I’m never allowed to get into the zone where I feel I do my best work because of this.) I mean I literally got stopped from doing what I was doing because one of my stupid co-workers couldn’t figure out how to correctly plug in a 3rd party USB device and get it working. (I would fight to get this stopped but then I’d either waste loads of time with the idiot or time bitching to a manager and most likely my only accomplishment would be to put me in a nasty mood.)
There’s other ones like this like continuous release. I literally had a manager, oh I’m sorry scrum master, say we had to do a new release because he had decided we were doing continuous release. The problem? There was no difference. We did a build on Friday. Then we got things ready for a demo and then actually did the demo. Then at the end of the day we had to timesheets and the day was over. So then Monday morning oh we need a release just because. No development had occured because after the “release” on Friday there was no time to do development. However the rules said we need a release so I made one.(I should point out releases are currently being done by hand so I wasted over an hour with a release that had no changes in it.) Yes QA asked me about and yes I told them it was a complete waste of time to upgrade to the new release. (Oh and that doesn’t even cover how the QA manager is apparently trying to kill off Agile/Scrum with great gusto yet my manager, sorry scummaster, doesn’t seem to notice.)
All this leads me to refer to bad agile as “Monkey’s Paw Development”. (IE things you as a developer would wish for yet are so horrendously corrupted that you’d regret it afterwards.) I guess I’m a little cynical. Not sure if anybody could notice.:rolleyes:
Yeah, this. If a prospect made a cogent argument for why they think something is bad, I might disagree but I’d at least know they understand it. When they dismiss something with a word or two, I’m going to assume they’re bluffing.
davidm, what kind of code do you write? Can you point to public examples, either here or in a PM?
That would depend on who did it (see below); also, since davidm wasn’t the PM, it’s possible that he’s had PMs who used a formal methodology minus the words.
The first version of ISO 9000 came out the year I graduated from college. A few years later someone recommended that I might want to get up to speed in it and loaned me the actual standard. When I finished it, I said “but, but, but… this is just what my college teachers called ‘doing things properly’! It’s what I’ve been doing for years, it’s how I always organize my work! What’s so fancy about it?” Turns out the first draft had been written - by three of my college teachers. So, I’d started training in ISO 9000 years before ISO 9000 got to print - we just called it “doing things properly”.
Do you honestly think he was going to say that during a job interview?
There’s a very good chance of shooting yourself in the foot if you don’t even know what a gun is. “What’s a design methodology? We just code.” Next.
Another “buzz word” you might want to check out is “Design Pattern” (if you aren’t familiar already.)
I remember being asked many times which design patterns I was familiar with and/or had used.
Another “buzzword” to know is kanban, which is an alternative to scrum. Not sure how popular it is…but the company I work for has moved to it, and as an internal customer & business owner the biggest change I see is moving from scheduled releases to releasing on a more ad-hoc basis. And smaller stories. I’m not a developer or PM so can’t tell you much more, maybe others here can.
I’ve been using some sort of variant of it for the past couple of years. Frankly, I find it a lot easier and more sane than Scrum (which I found, as others have said, to be a bit too formalised, requiring things to be done “just because”). It really did feel like it was common sense, planning when to do things and not taking too much on at once.
We used this website for our board:
I grew up with Waterfall in the 90s. Another reason I think it has fallen out of favor is that with modern software development tools, the boundaries between design, prototyping and development have blured. It’s almost as easy to simply play around building something in some development environments as it is to actually plan it out from scratch. Of course that’s a danger as well. People can get lulled into a false sense of how easy it is to develop and then code themselves into a corner.
That is true. Lot’s of software development is done now with no exact spec for the end product. All through the development cycle priorities are changing based on marketing, timing, and any other consideration that can be accomodated. All of these methodologies are fraught with danger if good sense isn’t a primary consideration.
I’m running with Kanban on some new projects and I’m finding the hardest part about it is explaining why I’m not using Scrum. “Because all that ceremonial and artifactual overhead is… um… basically unnecessary for most of what we do?”