What do you think about scrum metodology in company with 9 peoples? Can we use SCRUM for making websites? It is possible to work with scrum with more than 10 people and how it is look like.

It can help organize your people, help them self-monitor project progress. But it's not for every team. Most teams that adopt scrum do it in their own way; using the sprints idea only, or sprints and daily scrums, but without all the role playing... they adopt some part of scrum and adapt it to their working style. 

7 hours ago, cmpt said:

What do you think about scrum metodology

SCRUM is not a metodology of software engineering at all. It is kind of woodoo-programming. It is violate the basic rule of software engineering - key to success is a deep research of task field, code implementation is a final part of development, that can not be started until researches of field  complete finished.  Really wishes of any customer can be figured out by short phrase - "automation of his business/industrial process". But customer is not able to figure out how to automate a process. He just have not enought knowledge to make researches of field. It work have to be done by software engineers, not by customer.

2 hours ago, Fulcrum.013 said:

It is violate the basic rule of software engineering - key to success is a deep research of task field, code implementation is a final part of development, that can not be started until researches of field  complete finished. 

Speaking from experience, this is not (generally) the case in game development. Oftentimes you don't know what you need to build until you build it. Designers often have ideas that simply cannot be implemented without being prototyped in code. "Big design up front" might work with tiny, highly-derivative game jam games, but you could bet that for the last few years, AAA blockbuster games and smash hit indies alike have all had prototyping phases throughout the development cycle where designers propose a feature in the vaguest of terms, developers implement it, and then the designers tweak it and ask the programmer for more code changes until the feature is totally different from the original request.

1 hour ago, Oberon_Command said:

Oftentimes you don't know what you need to build until you build it.

You can not build anything until you exactly know how to compute it. It have no any sence to start coding until you make a book called "mathematical description of a task" where complete described mathemathical background of any feature that have to be implemented. Especially it is actually into such higlhy mathematically loaded field as game and gaming engine development.

2 hours ago, Oberon_Command said:

"Big design up front" might work with tiny

Than bigest project than better "Big design up front" works.  It allow to see a high level abstractions that can be implemented by tiny piece of code and than make a 99% of other work, by declarative adjusting, in some cases  by 100% data-driven way. Also it alow a whole coding cycle optimization by determining order of implementation that allow avoid "waiting of dependences implementation". SCRUM/AGILE and other "flexible methodologies" violates a superposition concept of development lifecycle optimization, and also better way to produce tons of garbage code and complete non-flexible software, it just produces tons of partial variants of solution where common solution exists, so is complete overingeeniring.

2 hours ago, Oberon_Command said:

but you could bet that for the last few years, AAA blockbuster games

I has seen only 3 games since millenium, that can pretend to be called "AAA blockbuster". It is "IL-2 Sturmovik", "Lock On: Modern Air Combats" and "S.T.A.L.K.E.R" trilogy. All those games have own engine that firstly been coded by tiny 2-4 teams of extrime high level professionals with very deep knowledge of field (especially air simulators) and only then level designers has been involved to development. Only of those games that has takes years of engine development is a S.T.A.L.K.E.R, just becouse deveopers has try to implement game on free opensources engines that become outdated just before thay has been released, and only then shortly created x-ray engine, that utilize all features of  modern at time versions of DX.

2 hours ago, Oberon_Command said:

alike have all had prototyping phases throughout the development cycle where designers propose a feature in the vaguest of terms, developers implement it, and then the designers tweak it and ask the programmer for more code changes until the feature is totally different from the original request.

It is why they produces a complete garbage not worthy to spend time to play.

Let's please try to keep this thread on the original question - SCRUM. Thanks!

13 hours ago, cmpt said:

What do you think about scrum metodology in company with 9 peoples? Can we use SCRUM for making websites? It is possible to work with scrum with more than 10 people and how it is look like.

It is suggested to have less than 12 people in a SCRUM team. Larger than that, you might want to split them in to multiple teams. 

The reason is, with SCRUM, everyday the team hold a SCRUM meeting which everyone has at most 15 minutes to speak. SCRUM meeting usually needs everyone to stand up during the meeting, to discorage people from spending too long on their agenda. If you have, says, 10 people in the room, and each of them takes 15 mins, then we will end up having everyone has somekind of leg pain  (and no, you don't want to let any of them to sit down in the meeting). It just taking too long. 

1 minute ago, mr_tawan said:

It is suggested to have less than 12 people in a SCRUM team

 Regardless of methodology used or kind of activity, teams over 10-12 persons can not be productively managed without subdevision.

2 hours ago, Fulcrum.013 said:

You can not build anything until you exactly know how to compute it. It have no any sence to start coding until you make a book called "mathematical description of a task" where complete described mathemathical background of any feature that have to be implemented. Especially it is actually into such higlhy mathematically loaded field as game and gaming engine development.

I'm afraid that again, speaking from experience as a gameplay programmer, this is not what happens in practice. Maybe this is true if you're writing a simulation, but if you're working on the next first-person shooter of the year, or the next big indie game, there's no way you'll be forming a precise mathematical description of a task. That would mean working far too slowly for the designers (and project managers) breathing down your neck, waiting for the next cool gameplay toy that you're building for them.

"Big design up front" of the sort you're suggesting simply does not play nicely with the needs of game designers and especially the needs of gameplay designers. In pre-production especially they usually want to be able to propose an idea for a gameplay feature and have a prototype working by the end of the week (if you're in a big AAA project) or the next morning (small team). If you stopped and redesigned your entire system or spent that week doing research to figure out exactly what you're going to build for every game designer request like that, you would never ship anything, never mind get the designer the tools they need to figure out whether you're going to implement a feature "for real."

Of course, one could argue that pre-production is itself kind of a research phase where you hack around looking to figure out what kind of game you're going to build. But there's no such thing as a "mathematical description of a task" in game development, at least in the gameplay world.

Nonetheless, I assert that agile may be often derided, but iterative workflows like scrum seem very well tailored to a gameplay team.

32 minutes ago, Fulcrum.013 said:

Regardless of methodology used or kind of activity, teams over 10-12 persons can not be productively managed without subdevision.

I would largely agree with this statement, though I would add to it that "subdivision" doesn't necessarily mean "hierarchy." It could be as simple as having subdivisions into artists, programmers, and designers.

7 minutes ago, Oberon_Command said:

Maybe this is true if you're writing a simulation, but if you're working on the next first-person shooter of the year,

You can made a logical engine of DooM - like "tonel" shooter on a week and it will never expire. It just require basic knowledge of analitical geometry and very basic level of knowledge of theory of automation control.  Anything else that that you need is to keep graphics updated according to hardware news and level design of addons.