Talk:Timeboxing/Archives/2012

Merging Time Boxing & timebox

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

I disagree. The timebox article is focused on the stricter entity from project management. Time Boxing gives allusion to the application in personal time management, and deserves expansion on that topic by Cheong or Pavlina (referenced authors.)—Preceding unsigned comment added by 148.87.1.170 (talk • contribs) 17:22, May 17, 2007

I am not in favour of merging: Users looking to read about 'personal timeboxing' will be put off by seeing an article on timebox that starts talking about project management. This article does need more content though. Paulbruton (talk) 10:14, 7 December 2007 (UTC)

I'm working through the backlog at Category:Articles to be merged since February 2007 and have decided to close this merge discussion with the consensus to keep the articles separate. Thanks — alex.muller (talk • edits) 17:56, 14 January 2008 (UTC)

Merge proposal

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)

Requested move

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)

Question About Completeness of Underlying Assumptions

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

Timeboxing is a time management technique. It has been ignored by most orthodox schools of project management but has been adopted extensively in a minority, which have grown in popularity in recent years. So, it is hard to source reliable criticism until majority opinion starts to embrace or refute this technique. Including original research or unreliable primary sources to provide a balancing critique would (I think) misrepresent the orthodox majority. RobertBurrellDonkin (talk) 09:17, 3 November 2011 (UTC)

Care with use of technical terms

"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)

This means Agile Software Development has ended up in a list of methodologies. This is unfortunate, since it is a philosophical movement advocating lightweight, humanist development methods rather than a methodology. Agile has been influential in the adoption of timeboxing, together with other advocacy groups such as proponents of Iterative development methods. In the short term, I'll relocate to a "See also" but perhaps a subsection addressing arguments for wider adopting might be a good idea. RobertBurrellDonkin (talk) 11:24, 5 November 2011 (UTC)

Questionable opinions without sources

"Timeboxing is a planning technique common in planning projects (typically for software development), where the schedule is divided into a number of separate time periods (timeboxes, normally two to six weeks long), with each part having its own deliverables, deadline and budget."

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)

Adoption Amongst The Largest Class Of Projects

"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)