8

I have been using SCRUM in three different projects over the last four years. One of SCRUM's advantages seems to be its flexibility and adaptability, e.g. wrt to changing customer requirements. Another advantage is that management can easily track the progress of a project.

SCRUM's flexibility can be an advantage e.g. when implementing a web application, where the requirements change very fast and the customers really understand what they want after they've seen a prototype.

On the other hand there are other kinds of software projects (e.g. in aerospace industry) where the requirements are pretty fixed: you get a requirement specification document and you have to come back six months later with working software and complete documentation. For this kinds of projects I doubt that the flexibility offered by SCRUM is needed (in the sense that you do not need to build prototypes and show them to the customer to get feedback on the requirements): you rather need a very structured and systematic approach, which is probably repeated over and over again for each project with little room for surprise.

So is SCRUM considered by its proponents a general-purpose software development methodology or is it considered especially suited for certain categories of projects or application areas?

For example, I recently looked at the website of a company producing software for the aerospace industry and noticed that they are using the V-model. Would a SCRUM proponent say that SCRUM is less suited for this kind of projects or rather suggest that this company should try switching to SCRUM?

Note that I am not asking for the opinion of the readers of this forum, but I want to know what is the established opinion among SCRUM proposers: is SCRUM considered general-purpose or rather suitable for certain classes of projects only? In the latter cases, for what kinds of projects?

Improve this question
4
  • See stackoverflow.com/questions/596916/when-should-you-not-scrum and eweek.com/c/a/IT-Management/…
    – jfrankcarr
    Commented Jun 22, 2012 at 15:09
  • 1
    That "get a requirement specification document and you have to come back six months later with working software" thing is a myth. Even when you build something like a compiler for a formally defined language (where the functional requirements seem to be really clear and fixed), you have to decide and prioritize the things to implement, there are non-functional requirements to be discussed with the user, and you have several degrees of freedom for one has to decide how to solve things. So an agile approach makes even sense for such kinds of projects.
    – Doc Brown
    Commented Nov 11, 2012 at 13:52
  • "So an agile approach makes even sense for such kinds of projects.": While agile may be more flexible, others methods are flexible as well. May be other methods are flexible enough, and agile is too flexible for certain projects. Just brainstorming here.
    – Giorgio
    Commented Nov 11, 2012 at 14:18
  • 2
    "That "get a requirement specification document and you have to come back six months later with working software" thing is a myth.": I don't think so. While you can quickly change the label of a button on a web page because the customers have changed their mind after looking at it, you cannot as easily change a critical part of an avionic software that controls a moving part of an aeroplane. Maybe late changes will be needed, but I wonder if an agile method is the right way to manage them, or if you need a more complex iteration of another method (e.g. the V-model).
    – Giorgio
    Commented Nov 11, 2012 at 14:38

4 Answers 4

Reset to default
5

SCRUM is a general purpose methodology that can work well for most projects and team sizes, but is less useful for large teams that do very large projects. The sheer number of people involved on some projects makes any agile methodology extremely difficult to near impossible because a more rigid structure is required to keep order. The aerospace industry is a good example of an industry that tends to have huge projects where agile approaches aren't always feasible.

Improve this answer
7
  • Is there any information as to when a project is considered too large to be done with SCRUM? Consider e.g. a 18 month project for a team of 15 people: would such a team profit from SCRUM or would another model like the V-model be suited as well. The reason why I am asking is that over 18 months the requirements and implementation have enough time to ripe and stabilize and maybe the flexibility provided by SCRUM is not really needed. Rather, a more middle- to long-term approach is suitable here. Is there any literature on this?
    – Giorgio
    Commented Jun 23, 2012 at 8:24
  • @Giorgio time of the project doesn't really matter, but 15 people is enough that you would benefit from making multiple scrum groups, but its still in the manageable range for SCRUM. when communication management starts to become a full time job for your team its time to start looking at a V-model
    – Ryathal
    Commented Jun 25, 2012 at 12:25
  • 1
    Are you serious? We were using a V-model before and switched to SCRUM. Actually we have the feeling that we've gotten slower for exactly this reason: too much bookkeeping.
    – Giorgio
    Commented Jun 25, 2012 at 16:40
  • @Giorgio that would be true for any switch, you are going to feel slower at first because its new, like Pierre 303 said you get a better idea after a few sprints.
    – Ryathal
    Commented Jun 25, 2012 at 17:17
  • 1
    @Giorgio - that's true, lots of "agile" methodologies are more heavyweight than the heavy processes they're supposed to replace! Obviously this means they're wrong - agile is supposed to be light and free, and appear chaotic to outsiders. It does mean your team has to be very organised and disciplined, but that's generally a benefit. Try Crystal from Alistair Cockburn (one of the founders of Agile) instead.
    – gbjbaanb
    Commented May 28, 2013 at 18:08
8

Any type of project! It works well for both large and small projects.

People have used it for planning weddings, moving house etc. So, not even just software projects.

I'm a firm believer that there are many business operations which could benefit from a Scrum-like approach.

Improve this answer
2
  • Is your own opinion shared by SCRUM proposers, i.e. by authors who have codified and promoted SCRUM?
    – Giorgio
    Commented Jun 23, 2012 at 8:18
  • Yes - it was recently said by Cheryl Hammond (blog.bsktcase.com), an ALM Consultant with Northwest Cadence on a talk she gave titled "A Scrum Masters Day In The Life: The New Visual Studio". You can watch it here: msevents.microsoft.com/CUI/…
    – Tom Morgan
    Commented Jul 2, 2012 at 16:12
5

Please note that Scrum is not a methodology, but a framework.

Scrum will work best in a cross-functional team from 5 to 9 developers working on a medium to large size project (from 4 months to multiple years). If your project is larger, you can scale with Scrum of Scrums.

I will not discuss the cross-functional thing here, but here are what the official Scrum Guide is telling for the team size:

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work. Fewer than three Development Team members decreases interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog

A sprint is about one month.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

I think it doesn't make sense to use a framework based on an iterative process with projects smaller than 4 months. 4 months = 4 sprints. You must also consider that you get a more accurate velocity after 3 sprints.

That said, I personally use a limited version of Scrum for smaller projects. But you can't really call it Scrum then. In that particular case, you are using some core principles of Scrum in your own implementation of the framework.

Improve this answer
1

for starters, think of SCRUM as just one set of guidelines for implementing agile practices. Don't ever think of it as a 'holy book' of how to do projects. For many projects where a steady flow of tasks is required, Kanbam is more appropriate, for example.

Agile projects tend to fall down where you're doing projects that require a fixed end date, or a fixed cost. Whilst you can still do these projects using Agile methods, the need to plan everything up front to determine if you're likely to hit the target is not the usual agile way - in agile you tend to keep doing work until you run out of stuff to do, or run out of time to do it in. For most projects this is ok as the requirements change anyway during the project.

Improve this answer
2
  • The way we do agile in our team is to let the customer set a priority on stories (from most to least important), we estimate user stories using poker cards, and plan as many stories as we can implement until the dead line. If we turn out to be faster, we schedule more stories, according to what come next in the priority list.
    – Giorgio
    Commented Nov 11, 2012 at 15:00
  • I read your answer again after a few months and it is actually really enlightening. +1
    – Giorgio
    Commented May 28, 2013 at 13:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.