What is your experience or your opinion of the Scrum agile software development methodology?

Never heard of it, but if I understand correctly it seems pretty obvious.
Isn’t it just assigning a leader, creating an adversary and planning ahead?

No, there’s more to it, but project managers seem to be divided when it comes to feasibility and adding value. Some are strong supporters especially for applications for which the requirements change during the implementation. Others are more skeptical pointing out that a more thorough analysis and good documentation of the design is the better approach, especially for larger projects and higher complexity.

Searching for scrum software development experience gives me 4 million results. I wasn’t aware that the methodology is quite widespread, so I figured there must be some Fluther users who could share their assessment with me.

Many companies I have developed for work on an “Agile” development method rather than a traditional SDLC. If you are doing short sprints of programming and actually doing some planning while trying to maintain the scope of the project it sometimes can workout. However I have seen in many situations where executives/clients simply want results, and to them planning is not a result. This leads to bad/worthless programs.

In my opinion, it should be taken with a grain of salt. I cant tell you how much useless code I have written because projects fail to deliver due to bad planning, and had it topped off with poor execution and implementation. But whatever, its not my loss, I still got paid. I would just warn executives/clients the liabilities of not doing proper planning.

We definitely talked about scrum and agile development in school as a fairly widespread methodology. In the end though, I believe the success of a project boils down to how committed the stakeholders are. Planning is an essential part of any software development project, whether the methodology be waterfall, scrum, agile, or some hybrid. The really important things to have are 1) committed stakeholders 2) limited scope creep 3) a mission statement (which may change). My professor, a 30 year veteran project manager at IBM stressed these points to no end. He also said whatever you do, make sure your project is delivered on time, on budget, and within the requirements.

@camertron What do you mean by your 2? “limited scope creep”?
seems like some sound advice, I just don’t understand that part.

@Zyx scope creep is the danger of letting your ideas spiral out of control. Let’s say you’re an employee at a peanut butter factory and you’re tasked with upgrading the machinery. You start out by asking the other factory workers what they want. They tell you they want a specific machinery brand, but the new system will require you to revamp the ventilation system too. “Well,” you think, “that’s not so bad. And it’ll mean we’ll have really good machinery.” You go ahead and start to make the changes. In the middle of installing the new ventilation system, you realize you’re required by health and labor laws to put in filters to protect the workers. In addition, the heating and air conditioning system has to be upgraded. An employee suggests you look into geo-thermal heating/cooling while you’re at it, so you start to do some research…

This scenario is a good example of scope creep. It shows how a seemingly single-purpose project can grow and mutate until it’s so large and complicated that, when it’s finally done, it probably won’t meet the need it was originally started for. It’s entirely possible that the new machinery will be outdated by the time the project is done. That’s scope creep.

Thanks @camertron !