Talk:Scrum (development)

From Wikipedia, the free encyclopedia

	This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
???	This article has not yet received a rating on the quality scale.
???	This article has not yet received an rating on the importance scale.

OK, I started cleaning up the Scrum page. It is starting to make more sense, but definitely needs additional work. rnd 12:38 AM 7/01/07

Correct me if I'm wrong, but I believe the product owner is not a 'pig'. While invited to the daily scrum meetings, the product owner cannot speak, as the sprint has started and no changes are allowed. (I'm anonymous, but a ceritfied scrum master for over a year). —Preceding unsigned comment added by 208.102.57.190 (talk) 19:50, 12 April 2008 (UTC)

Contents 1 Confusing timeline 2 Object Oriented 3 Article misses the point 4 Talk:Scrum (management) 4.1 Living backlog 4.2 Removed a chunk of unsubstantiated, unencyclopaedic content 4.3 Removed link to the word "deliver": why? 4.4 Comment on simplified scrum description 4.5 Adaptive Project Management Comments 4.6 Please say more about the significance of 1 month 4.7 Merge with Scrum (development) 4.8 Advantages and Disadvantages 5 Inaccurate Link - please correct 6 NPOV and Cleanup tags 7 Scrum Background 8 "fundamentally empirical challenges" 9 Scrum and the rugby metaphore 10 External links 11 Solo Scrum 12 What is Scrum?

[edit] Confusing timeline

Second paragraph: Scrum was first applied in 1993 at Easel .... These principles later became some of the basics of Scrum. ... These projects were observed and the results were published ... (January-February 1986)

Something in that paragraph needs a change to clarify the timeline.

[edit] Object Oriented

I don't think Scrum specifies an object oriented approach. In fact, it leaves it up to the developers to decide the approach that best works for them. It's often used with XP, with Test Driven Development, which would lend itself to a highly modular (not necessarily OO) design, but I don't think it should be listed as a characteristic of Scrum.

Will remove if no one objects. Mutant 21:20, 21 September 2006 (UTC)

• Objection raised. Object orientated in this context refers to the processes described within the methodology. Each iterative item can be described as an object and thus doesn't in any way refer to the IT term. Instead the terms draws you to the implication which, in my understanding, means a semi-independent item within a whole. Maxwellvz 14:11, 25 September 2006 (UTC)

I haven't heard that term used in this context before. It also seems to me to be rather ambiguous. If that is the term in common use, then fair enough, but I think some sort of explanation (along the lines of what you've already given) is in order. Mutant 21:39, 26 September 2006 (UTC)

Ken Schwaber's SCRUM Development Process describes how an object orientated approach can be used with SCRUM. Maxwellvz

[edit] Article misses the point

This article, especially the bizarre diagrams, completely miss the point that Scrum is a simple framework. It's really just three roles (Product Owner, ScrumMaster, Team), four meetings (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), fixed (typically 30 day) iterations, and demonstrable increments every iteration (Sprint).

I suggest we overhaul this entire article, deleting most of it and bringing it up to date with the simple "Scrum Rules" appendix in Ken Schwaber's gray book.

--mj (ScrumMaster, Scrum Practitioner, and Scrum Trainer) Michael98101 17:30, 10 June 2007 (UTC)

Very much in agreement. This needs a total overhaul. The diagrams completely confuse the issue. - rnd (CSM, CSP, Agile Consultant)

Totally agreed. 201.9.41.169 12:57, 24 June 2007 (UTC)

I agree. This article is confusing and incomplete. It completely fails to explain agile principles and Scrum as a Framework. 81.171.156.97 14:42, 26 June 2007 (UTC)

Why was the content of this article removed? Gmazeroff 19:21, 10 June 2007 (UTC) gmazeroff

Strongly agree. I barely recognize the described process as Scrum. This article used to be clear and concise, but I think it was polluted during the merge of the Scrum development and business process articles. Runtime 08:16, 29 June 2007 (UTC)

Strongly agree. Perhaps I'm simply procrastinating here, but the part about standing for a scrum, not being able to speak and punishments for being late? Completely unfamiliar territory than I've ever experienced. Scottdavies (talk) 13:07, 30 April 2008 (UTC)

[edit] Talk:Scrum (management)

[edit] Living backlog

What is a living backlog? Is it just a master list of things to do which is updated regularily. If yes, what is special about this? Hasn't this been used all the time? --Hirzel 21:49 10 Jul 2003 (UTC)

It's nothing revolutionary, no. There are two backlogs, for the Sprint and Product. The Sprint backlog is the todo list of the current monthly iteration, and the Product backlog a list of everything anyone has requested.

Developers should update the Sprint backlog daily, with an estimate of how much work is remaining on each of their tasks. This is maybe what is meant by "living" - you always have an idea how much work is left to do, and as the backlog is essential to the scrum process, you can be sure it's going to be up to date.

Anyone (really, anyone) can add requests to the Product backlog. As such, it is the one place that captures all ideas about the product/project. Even stuff that might not be possible now - "I want a man on Mars!" can be added. Once a month, the business owner (product owner in scrum parlance) puts the list in order or priority to the business. Again, the fact that anyone can add to it, at any time and anyone can see it and the current priorities at any time make it a key document, and the focus of a lot of attention.

If you have a short term todo list (sprint backlog) and a long term todo list (product backlog), and review it frequently/daily with everyone involved in the project and are constantly keeping it up to date, and use these 2 documents as the central point to capture ALL requests, then you more or less have a backlog. Murray 20 Jan 2004

[edit] Removed a chunk of unsubstantiated, unencyclopaedic content

The following chunk was in the article, unreferenced, and with a very "how-to" feel to it. I've put it here in case someone can pull something useful out of it. -Kieran 10:29, 25 October 2005 (UTC)

Begin chunk:

---

In the recent times most of the managers have recognized the value of the people centric management practices against the process centric practices. In an environment of the constantly changing requirements & stakeholders, it is not logical to control the project on the process level. In simple terms "a rigid process cannot help in adopting to the customer's needs".

For the Software projects its is very meaningful to combine the SCRUM with Extreme Programming and Test-driven development. This helps to have a systematic and disciplined practices with respect to the management, code, and testing practices.

---

End chunk

[edit] Removed link to the word "deliver": why?

I removed the link to the word deliver because it links to page that defines the word in the traditional sense (e.g. trucks and warehouses) while the word is used on this page in the software sense of "completion". It didn't seem helpful to me to link from here to that page. Dave Menconi

[edit] Comment on simplified scrum description

Under "simplified Scrum" it says

   * Schedule a demo of the software with the customer/client a month from now

This sounds a lot like the horrible practice of picking dates out of thin air and then whipping the team to meet the date (I could tell you such stories...). It's not clear from this discussion how the scrum version would differ.

On the other hand, this is just an example of a way to implement a lite version of scrum and it might complicate this overmuch to explain how you pick the date.

Still if *I* had this reaction maybe others would too; if so Scrum would be painted with a negative reaction because of an example.

Dave Menconi

I think the main difference is that you plan a demo, but then the team decides on what the demo will include. In that way, managers or leaders aren't pushing irrational timelines on the team, as the team decides what can be done in that timeline. I think you're right in thinking that people will cringe at this. Regarding this section, I think we need to cite something directly here, I'm pretty sure that some of the official material on Scrum has examples of how Scrum can be "stealthily" applied to an existing process without crediting it to "one wiki writer"Endasil 15:59, 7 July 2007 (UTC)

[edit] Adaptive Project Management Comments

The paragraph at the top of this section is not crystal clear. It has a lot of good information but it's like a bunch of ideas are all jostling to be presented.

The rest of the section was good, imho

Dave Menconi

[edit] Please say more about the significance of 1 month

In two places it's mentioned that things are done monthly (here in the dicussion when explaining about backlogs and in the simplified scrum). Are sprints usually month long? Or is monthly just an example of a "short period of time".

This is kind of significant because having monthly deliverables (if indeed that's one of the features) would be one of the most obvious and significant difference between scrum and other more traditional software development methodologies (the other big one, I think, is the daily meeting). Many of the features look, at first glance the same -- for example, I've always done software iteratively(in 3-18 month iterations) and we always have a list of tasks (controlled by the leader) and so on -- but take on a different tone when the time scale of things is taken into account.

Stephiee01 19:42, 16 August 2006 (UTC) Sprints/interations ideally should not be more that 1 month in duration without reconvening with stakeholders and product sponsors to review the sprint accomplishments in the event that changes should be made, or priorities have changed. With longer iterations, teams typically loose focus of their sprint deliverables, and the "pressure" to get the job done is eased quite a bit. In other instances, there is the concept of mini-sprints, which are shorter interations, usually a week to 2 weeks in duration. Also, typical 30 sprints can be broken down into "mini sprints" with weekly/semi goals to reach the end of sprint goals identified at during sprint planning.

Please keep in mind that following scrum to the letter does not determine success. Rather, scrum is a practice that should be altered to fit your best business practices and own processes and procedures. Scrum should be used as a framework and adapted within current successful practices. As more project are developed using the scrum methodology, you will begin to see what aspect(s) fit and which ones don't, and you can begin to build around the key principles of scrum.

[edit] Advantages and Disadvantages

This article practically tells us the advantages of SCRUM. Wouldn't it be nice to have some disadvantages of SCRUM listed or at least some negative opinions of SCRUM? SCRUM can't be all good right? —Preceding unsigned comment added by 12.160.172.2 (talk • contribs) 20:30, January 24, 2007

[edit] Inaccurate Link - please correct

The link title "Agile Values" links to the Agile Alliance. These are two different things, and should probably both be represented:

Agile Values and Principles: www.agilemanifesto.org Agile Alliance: www.agilealliance.org

thanks, Deborah Hartmann deborah.hartmann.net

[edit] NPOV and Cleanup tags

The article uses first-person pronouns in a few points, and as such doesn't have the proper tone. Additionally, the feeling I got from reading the article is that Scrum is the best methodology for developing software, with no flaws. Unless it really is the holy grail, there are probably are some flaws, so I've added the NPOV tag. Obonicus 20:55, 3 July 2007 (UTC)

I would agree. Flaws I can think of include: (1) potentially messy code due to unplanned features layered over prior code that wasn't flexible enough to allow elegant extension. And messy code can lead to more bugs, etc. (2) Higher initial number of bugs due to an insufficient time frame for testing and/or inadequate specifications from the user.

This is of course not to say that the advantages of Scrum don't outweigh these potential disadvantages (I think Scrum or Agile development in general is a good idea for many projects). Just my two cents. -pgentry 198.81.125.18 16:35, 2 August 2007 (UTC)

I believe that Scrum/Agile is the way to go for for experimental projects with less clearly defined requirements and technology while more traditional methods work best when the domain is well understood and predictable. -Jesse

I've wrote down a few known (or alleged) disadvantages, so that there are now less reason for NPOV tag. -Humu —Preceding unsigned comment added by Humu (talk • contribs) 12:37, August 27, 2007 (UTC)

[edit] Scrum Background

I think some of the part about the OOPSLA paper might be incorrect. I checked the ACM Digital library, they have the proceedings for the OOPSLA conference, and there is no _paper_ listed by Jeff and Ken. There is a mention of Jeff being on a _panel_ discussion. Also thats for OOPSLA '95 not '96. Also the scrumalliance.org web page that has Jeff's profile says that he worked with Ken to formalize scrum. It does not say he presented a paper there.

---

Ken presented the paper at the OOPSLA'95 Business Object and Design Workshop. Workshop summaries are published in the OOPSLA addendum. The full text of the article was published in the proceedings from the 1995 workshop in a 1997 book by Springer:

K. Schwaber, "Scrum Development Process," in OOPSLA Business Object Design and Implementation Workshop, J. Sutherland, D. Patel, C. Casanave, J. Miller, and G. Hollowell, Eds. London: Springer, 1997. —Preceding unsigned comment added by Jeffsutherland (talk • contribs) 20:32, 7 October 2007 (UTC)

[edit] "fundamentally empirical challenges"

A key principle of Scrum is its recognition that fundamentally empirical challenges cannot be addressed successfully in a traditional predictive or planned manner.

The statement is problematic in a few ways. It's an unsourced assertion, and it's possibly an unverifiable assertion.

What is a "fundamentally empirical challenge?" Are there other kinds of empirical challenges for which a "traditional predictive or planned manner" is supposed to be suitable after all? Or are all development efforts assumed to be fundamentally empirical challenges? If so, what are the sources for such an assertion (that aren't just restatements of the assertion)?

Is there really a black-and-white distinction between challenges that can be approached with a Scrum method and challenges that cannot? The use of "cannot" in the quoted statement is a very strong claim. Saying a method works well for particular classes of problems is still a strong statement, but easier to justify. Saying one method works better than other methods for certain classes of problems is a stronger statement, and needs verification in comparative studies. Saying that one method works and other widely used methods "cannot" work is highly questionable.

--Jim Becker 22:48, 12 October 2007 (UTC)

Bang to rights, my friend. (I appreciate this isn't the most helpful addition, but really, the whole article could do with the help of a gallon of napalm, a box of matches, and a couple of oxygen cylinders. When I tell a customer he's a chicken (or a pig), I'll know it's time to go and listen out for that tree falling in the woods.) —Preceding unsigned comment added by 193.129.10.246 (talk) 10:09, 21 November 2007 (UTC)

[edit] Scrum and the rugby metaphore

I rephrased the section claiming that Takeuchi and Nonaka compared the high-performing teams to the scrum formation. It is wrong! Here is what they say in "The New New Product Development Game":

In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method—as in rugby, the ball gets passed within the team as it moves as a unit up the field.

First of all: They don't mention scrum and you can't pass a ball within scrum, its OK within a team. Then, there are plenty of ways to move up a team; rucks, mauls, open play, chase a kick. Scrum is mentionned in the article, but seldom as a descriptive term. "Rugby approach" is mentionned a lot more.

I really like Scrum as name for the development framework, but saying it reminds of a rugby scrum is really weak. Comparing it to a rugby team is so much better, especially if you know the game.

--Eirik.midttun (talk) 21:42, 12 December 2007 (UTC)

Wait...you can't mention a joke about a pig and a chicken and then not tell the joke....that's just wrong. —Preceding unsigned comment added by 70.115.240.66 (talk) 04:02, 7 March 2008 (UTC)

[edit] External links

1. As I saw comment "NoMoreLinks" in “External links” section, therefore I suggest here one more useful link http://www.mountaingoatsoftware.com/scrum and suggest remove duplicate video link: http://video.google.co.uk/videoplay?docid=-7230144396191025011 Prusac (talk) 11:47, 25 March 2008 (UTC)
   1. Please reply here ...

[edit] Solo Scrum

I think there should be something in the references or links to justify the 'Solo Scrum' section. I did a Google on Solo Scrum, and didn't find anything official, just various posts by people saying they were going to try to do scrum in a team of one. —Preceding unsigned comment added by 82.163.39.121 (talk) 21:59, 2 April 2008 (UTC)

Strongly agree. Solo Scrum is nothing official, just an article on somobody's blog. It doesn't deserve a separate section on Wikipedia. —Preceding unsigned comment added by 81.219.244.145 (talk) 07:33, 20 May 2008 (UTC)

[edit] What is Scrum?

The first paragraph should answer this question. Some quotations from the Web:

Scrum is an Agile process that can be used to manage and control complex software and product development using iterative, incremental practices.

- (Company where Ken Scwaber works www.controlchaos.com)

SCRUM is a loose set of guidelines that govern the development process of a product, from its design stages to its completion.

- (Marc Clifton, J. Dunlap) http://www.codeproject.com/KB/architecture/scrum.aspx

Scrum is a simple set of practices and rules that encompasses the transparency, inspection, and adaptation requirements inherent in empirical process control.

- (Ken Schwaber) http://www.scrumalliance.org/system/resource/file/275/whatIsScrum.pdf

Scrum, an Agile approach, is an iterative, incremental process for developing products and managing projects.

- Conchago http://www.scrum-master.com/agile/whatisscrum.asp

Scrum is an Agile Software Development Process

- Jeff Sutherland http://jeffsutherland.com/scrum/index.html

Scrum is an agile methodology that focuses on a subset of project management and requirements management.

- Scott W. Ambler http://www.ddj.com/architect/207100381

Faller (talk) 09:11, 10 April 2008 (UTC)