This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
They appear to be discussing the exact same topic with redundant information; they should be merged.—Preceding unsigned comment added by 66.93.60.41 ( talk • contribs) 13:11, March 6, 2007
Reviewing the two articles Timebox and Time boxing, it is clear that they are dealing with the same topic. Although strictly speaking the Timebox is the object which is used by the technique of Time boxing, the two are inseparable. Given that the content of each is light and Timebox has been flagged with request to expand since June 2008, I would like to propose that if the Timebox article is not significantly expanded by April 2009, we move to merge the two articles. Greyskinnedboy ( talk) 22:15, 25 February 2009 (UTC)
The term most commonly used is Timeboxing (without the space). This should be an uncontroversial move, but as the current redirect at Timeboxing has a history it cannot be done automatically, so we have to follow the Move request protocol. Greyskinnedboy ( talk) 22:15, 5 March 2009 (UTC)
Move confirmed and completed. Many thanks. Greyskinnedboy ( talk) 22:38, 5 March 2009 (UTC)
This question may lie outside the realm of those reporting on this methodology. This article asserts a limited set of possible causes of failure; it seems to glaringly ignore other possibilities such as externalities. For instance, a project can easily be delayed due to encountering latent defects in an API/library provided by a 3rd party, particularly ones discovered late in the SDLC (I have had firsthand experience with this several times).
Another possibility is a scrum team leader who, due to unethical reasons or outright incompetence or even simple inexperience, makes unrealistic time estimates. Just because someone believes they themselves could complete a task in a set amount of time does not mean that another team member would necessarily do likewise; and this does not even begin to account for variations in the quality, maintainability, or supportability of the delivered product, aspects which I have found to be more costly over the support period of the product than other issues in software development.
It seems to me that timeboxing could be flawed in its underlying assumption that a set time constraint should be able to be completed by anyone on the team in the same manner in the same period of time. However, it is not my intent to question the methodology itself here, really, but rather to point out a gap in the potential set of reasons for mission failure as covered by this article. BTW, this is an interesting topic I have encountered in the SDLC outside any formalized definition of deadlines such as timeboxing. 98.167.146.11 ( talk) 08:52, 28 May 2011 (UTC)halgol60 on over at gmail
"rapid application development (RAD) software development processes such as dynamic systems development method (DSDM) and agile software development[citation needed]." may lead to confusion between the concept of rapid application development (methods of efficient software production) and the specific methodology of rapid application development. It is perhaps best to assume that the reader has some familiarity with orthodox management techniques but is not capable of guessing by context whether a term should be judged technical or not. I think it best to break out methodologies into peers in a list whilst pulling in most context. RobertBurrellDonkin ( talk) 09:08, 5 November 2011 (UTC)
"Timeboxing is a planning technique common citation needed in planning projects (typically citation needed for software development), where the schedule is divided into a number of separate time periods (timeboxes, normally citation needed two to six weeks long citation needed), with each part having its own deliverables, deadline and budget citation needed."
I think these claims too strong and too general to be able to locate supporting evidence for. I think the best approach is to source more specific claims then add them to the relevant sections.
RobertBurrellDonkin ( talk) 15:59, 5 November 2011 (UTC)
"There is little evidence for strong adoption amongst the largest class of projects"
Not happen with the wording of this sentence. Capers is a good independent source for figures. (Most statistical claims for Agile related techniques in text books for Agile. Capers has a long term independent interest in summarising software best practice) Capers makes the point generally that Agile techniques (including timeboxing) are very strongly correlated with success in small projects but that - for the largest class of projects - adoption rates are too small to learn whether it works. This evidence supports the consensus that where suitable, timeboxing is very successful. Suitability is controversial, and so seems safer to use personal attribution. Like many software topics, this approach is likely to prove controversial amongst whose who feel that a NPOV means that an article should be balanced with criticism even when the majority of reliable sources are positive. RobertBurrellDonkin ( talk) 11:50, 6 November 2011 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
They appear to be discussing the exact same topic with redundant information; they should be merged.—Preceding unsigned comment added by 66.93.60.41 ( talk • contribs) 13:11, March 6, 2007
Reviewing the two articles Timebox and Time boxing, it is clear that they are dealing with the same topic. Although strictly speaking the Timebox is the object which is used by the technique of Time boxing, the two are inseparable. Given that the content of each is light and Timebox has been flagged with request to expand since June 2008, I would like to propose that if the Timebox article is not significantly expanded by April 2009, we move to merge the two articles. Greyskinnedboy ( talk) 22:15, 25 February 2009 (UTC)
The term most commonly used is Timeboxing (without the space). This should be an uncontroversial move, but as the current redirect at Timeboxing has a history it cannot be done automatically, so we have to follow the Move request protocol. Greyskinnedboy ( talk) 22:15, 5 March 2009 (UTC)
Move confirmed and completed. Many thanks. Greyskinnedboy ( talk) 22:38, 5 March 2009 (UTC)
This question may lie outside the realm of those reporting on this methodology. This article asserts a limited set of possible causes of failure; it seems to glaringly ignore other possibilities such as externalities. For instance, a project can easily be delayed due to encountering latent defects in an API/library provided by a 3rd party, particularly ones discovered late in the SDLC (I have had firsthand experience with this several times).
Another possibility is a scrum team leader who, due to unethical reasons or outright incompetence or even simple inexperience, makes unrealistic time estimates. Just because someone believes they themselves could complete a task in a set amount of time does not mean that another team member would necessarily do likewise; and this does not even begin to account for variations in the quality, maintainability, or supportability of the delivered product, aspects which I have found to be more costly over the support period of the product than other issues in software development.
It seems to me that timeboxing could be flawed in its underlying assumption that a set time constraint should be able to be completed by anyone on the team in the same manner in the same period of time. However, it is not my intent to question the methodology itself here, really, but rather to point out a gap in the potential set of reasons for mission failure as covered by this article. BTW, this is an interesting topic I have encountered in the SDLC outside any formalized definition of deadlines such as timeboxing. 98.167.146.11 ( talk) 08:52, 28 May 2011 (UTC)halgol60 on over at gmail
"rapid application development (RAD) software development processes such as dynamic systems development method (DSDM) and agile software development[citation needed]." may lead to confusion between the concept of rapid application development (methods of efficient software production) and the specific methodology of rapid application development. It is perhaps best to assume that the reader has some familiarity with orthodox management techniques but is not capable of guessing by context whether a term should be judged technical or not. I think it best to break out methodologies into peers in a list whilst pulling in most context. RobertBurrellDonkin ( talk) 09:08, 5 November 2011 (UTC)
"Timeboxing is a planning technique common citation needed in planning projects (typically citation needed for software development), where the schedule is divided into a number of separate time periods (timeboxes, normally citation needed two to six weeks long citation needed), with each part having its own deliverables, deadline and budget citation needed."
I think these claims too strong and too general to be able to locate supporting evidence for. I think the best approach is to source more specific claims then add them to the relevant sections.
RobertBurrellDonkin ( talk) 15:59, 5 November 2011 (UTC)
"There is little evidence for strong adoption amongst the largest class of projects"
Not happen with the wording of this sentence. Capers is a good independent source for figures. (Most statistical claims for Agile related techniques in text books for Agile. Capers has a long term independent interest in summarising software best practice) Capers makes the point generally that Agile techniques (including timeboxing) are very strongly correlated with success in small projects but that - for the largest class of projects - adoption rates are too small to learn whether it works. This evidence supports the consensus that where suitable, timeboxing is very successful. Suitability is controversial, and so seems safer to use personal attribution. Like many software topics, this approach is likely to prove controversial amongst whose who feel that a NPOV means that an article should be balanced with criticism even when the majority of reliable sources are positive. RobertBurrellDonkin ( talk) 11:50, 6 November 2011 (UTC)