I think not even having heard the terms scrum or agile would suggest that you haven’t programmed in a team recently. Which could be a bit of a no-no. Where I work I think we’ve officially abandoned ‘agile’ which was only used for small teams. But we still have morning stand-up scrums (stupid name for “a quick lightweight meeting”) which at least generates some communication within the team, and doesn’t waste much time.
When I was programming I think the methodology was basically waterfall. Which really did not work.
I’m baffled. I’m not a techie or coder, but I’ve had experience with Agile since maybe 2004 and even today (when I work with a decidedly non-tech NGO) it comes up now and then.
If I ran into someone who claimed to be an IT professional who wasn’t at least familiar with the basics, I’d really question their experience. If you haven’t picked up at least a background knowledge, I’d assume you aren’t reading trade magazines, talking shop, keeping up with what companies are doing, or otherwise actively engaging in the field. I’d probably guess that your background was a lot of mom and pop operations, and that you may not be a good fit for a more professional setting. Nobody wants the guy who learned a few skills in 1998 and has been coasting on that ever since. Sure, that may be all you need to write code. But it’s a competitive world out there, and employers aren’t looking for bodies to fill seats. They are looking for people who can make a substantial contribution, not just get the job done.
It may look like all of your managers have just held the principle of “be a good manager,” but that’s not actually a good way to run a company. Managers make all kinds of decisions. How are teams formed? How do teams communicate? How are tasks assigned? How is progress monitored? How are results measured? And if the manager is any good, they’ll have some reason for the choices they make other than “It seemed like a good idea at the time.” Even if that particular manager is right, that doesn’t help the company know what to do across departments or when that one insightful manager moves on.
Agile, et al. are just a coherent system for those decisions. It’s not magic, but it has been developed to address problems in the previous system. In this case, Agile addressed the fact that software development management systems, which had probably been designed in the punchcard era, was taking way too long because it wasn’t catching small problems until they became big problems.
I have to disagree here. I’ve done both and Agile does a much better job of scope creep and quality control. I’m a QA guy, so I see everything from the butt end.
When we were doing waterfall, it was, “We will have this entire project done by X date.” There was absolutely no room for scope creep. Agile says, “Eh. We didn’t get to it this iteration. We’ll put it at the top of our list to get done next iteration.”
With waterfall, the PMs got all of their specs into a nice bunch and handed them to Dev. Once they were done with them, QA got them and said, “Um, this requirement is untestable. Can you re-write it so that it is testable?” Then PM would re-write it and Dev would have to re-code.
Agile puts eveyone in the room at the beginning so stuff like that can be found right away without all of the re-work.
That is the gist of it, at least. How it is actually implemented is another story. I’ve worked at places that tries to merge waterfall and Agile to varying degrees of success.
From my experience Agile places a higher emphasis on quality at the beginning. In waterfall, dev just kinda throws whatever they have at code-complete over the wall to QA and we’re left to deal with whatever they gave us. With Agile we can start testing early and have a MUCH more stable build when dev hits code-complete.
I see a lot of people in this thread dogging on Agile. And poorly done Agile can be a buzzword hell.
But a well run team is going to have certain ways of doing thingss. Agile is just a way of codifying what should be good practice anyway.
Of course, if you have a micromanager, it doesn’t matter what method you use, work is going to suck. But if you have a good manager, might as well take some uncertainty out and use what works.
I have to agree with even sven. Not having been on a team that’s done Agile is one thing. Never having heard of it is another. It’s like the difference between “I haven’t used javascript but I’ve heard of it” and “What’s this Javascript thing? All I do is write webpages”.
You need to familiarize yourself with the methodologies that are commonly in use in the industry. Since you did not get this training with your previous jobs, you’ll need to do some continuous learning here, and inform yourself. They really are industry standards. This will help you get employment.
OR, you could take the advice of posters like Clothahump, and remain unemployed and uneducated while maintaining your ability to bitch about “kids these days and their stupid buzzwords”
Long-time big corporation software developer here.
When I have interviewed candidates for developer jobs, or helped design interview outlines, there have always been questions about development methodologies and SDLCs: what methodologies have you worked under, what do you think works best, that sort of thing. Software is designed, developed and tested by interactive teams, and ignorance of how that is generally done is going to be a big minus in an interview.
As you try to become conversant with this stuff, it won’t help you to think of it as just buzzwords, or stuff you don’t really need to know. If you continue to think that the stuff you quoted from Wikipedia in the OP is mental masturbation, you are missing some important stuff in there. The iterative development aspect of these methodologies is a key, and the various ways of putting words around that and putting it into practice are all aimed at standardizing how teams can be flexible, productive and fast.
I think it would help you to admit to yourself that you are completely out of touch with how software is developed in most shops today, and get about the business of getting up to speed.
That is about my assessment. The first, and almost last, time I heard those terms was in Project Management training. They were used to describe ways of developing software:
Spec it all out carefully and write it once.
Write part, test, then write some more.
Fuck around trying to figure out what people want and changing things until everyone is too exhausted to continue (my area’s current method.)
Somebody made up names for these methods that most of use already use to solve problems. I can never remember which name goes with which method but in the end, it never changed the screwed up ways we do project here.
Maybe, just maybe, if someone says “we are going to use a waterfall method to write this code” you might be able to better understand the overall approach. In my experience it is very unlikely that the manager who used the term knows what it means but it is very important to them.
This is actually sort of true, and is the reason why agile works as well as it does. The concept started from a study done of how truly effective organizations operated. They took what effective teams were doing and documented it and the result is agile.
A truly agile team that is firing on all cylinders using scrum methodology is a great thing to watch. Management doesn’t even need to get involved in anything except to remove blockers. The team self directs and manages itself. No one feels micromanaged because they are not, yet everyone is accountable in the daily stand up.
I agree with most of the posters here that this stuff is real, does in fact work, and you need to familiarize yourself with it to be taken seriously.
Also, there’s nothing wrong with not having agile experience. Plenty of people still work in Waterfall SDLC environments. However, there’s no excuse for not knowing the basics about what Agile is and how it works. I’d hire someone (and do) that didn’t have Agile experience to be on an agile team as long as they were eager and willing to try it.
Relax, it’s pretty simple stuff. It’s just part of the culture now. If you want to talk to people about modern music you have to know the names of a lot of bands and what they’re doing these days. It doesn’t mean you have to spend much time listening to every one of them. And even without a bunch of new management terms to worry about you’ll have to learn hundreds of new TLAs to communicate with the other programmers. It’s an opportunity to broaden your knowledge and skill set.
Extended Three Letter Acronyms, i.e. Four Letter Acronyms. My company had a glossary of TLAs, with an appendix for ETLAs. And yes, they really called them that in the appendix. I was never able to decide if it was intended as a joke or not.
What do you mean by team? And what deadlines did you meet?
I’ve met too many developers that considered “the team” to be development only and meeting the deadline as they were done with new feature code. To them, they were done. Deadline met.
They rarely looked at what QA had to do with that code. More often than not, it was unusable for the first 2 to 3 weeks. When the release date had to be pushed because it could not be released in the state it was in on the original release date, development would hold up their hands and say, “We met our deadline!”
I’m not saying your team was like that, I’m just saying that I’ve seen it in a bunch of the companies I’ve worked for over the years.
Okay, I’ve been reading Wikipedia.
As I understand it Waterfall is sort of “set in stone” development, where each step (requirements, design, implementation, verification, maintenance), should be finished and perfect before proceeding to the next, at which point all previous steps are set in stone.
From my experience, this way of doing things simply won’t work in the real world. For example, you may not realize that the requirements are incomplete or ambiguous until design or implementation, or the customer may decide to tweek their requirements after you’ve started. At which point you have to be agile (pun intended).
So in the real world, in anything other than the simplest projects, you end up having to be more flexible and therefore end up using something very close to agile, even if you intended Waterfall.
Agile sounds very similar to the way I’ve always done it. I guess Scrum is the closest to how our teams worked, expect for the cutesy names like scrummaster and sprints.
We also wrote the test plans and fixed the bugs. So when we were done it was ready to go out the door (or be downloaded as a patch). Of course, this was just the front end of a client / server system, but the backend had been more or less set in stone before I had even started working there.
Again, relax. It’s all just jargon. You’re stressed out because you’re looking for work, but there’s nothing for you to worry about. You’ve learned lots of technical terms in the past, and you’ll have no problem learning the new ones. And the people you’re talking to only learned them recently because they weren’t invented very long ago. You’ll find yourself unfamilar with the names, not the concepts. In a few months you’ll be immersed in the particulars of your new job and you can complain about stupid management decisions like the rest of us.
