License

This work is licensed under the Creative Commons Attribution 3.0 Unported License.

Attribution

Based on http://opentalkware.googlecode.com/svn/talk/Timeboxing/ by OpenTalkWare The original source available from OpenTalkWare is licensed under the Creative Commons Attribution 3.0 Unported License. The original uses S5 which is public domain. Please see the credits for information about all the wonderful and talented contributors to S5!

Summary

Introduces the concept of timeboxing in the context of Agile development.

Abstract

TODO:

What is a time box? A time box fixes the time allowed for an activity. Examples: A lightning talk timeboxed to 10 minutes. A retrospective might be to 1 hour. An iteration to 1 week. A sprint to 3 months. When the time allows for more

Software Economics Conventional constraint triangle. Reasons: in software, the consequences in terms of throughput when changing resources, quality and time are unpredicatable and non-linear. * Labour is not interchangable * Communication drag often increases faster than output when adding developers, and this cost is paid by everyone. Productivity scales poorly with increased team size. * The relationship between human resources and output is non-linear. In some cases, adding resources reduces output. * Low quality software has a complex relationship with costs. When production quality is too low, future productivity will be effected by the need to rework by fixing bugs.

Software Economics Conventional constraint triangle. Reasons: in software, the consequences in terms of throughput when changing resources, quality and time are unpredicatable and non-linear. * Labour is not interchangable * Communication drag often increases faster than output when adding developers, and this cost is paid by everyone. Productivity scales poorly with increased team size. * The relationship between human resources and output is non-linear. In some cases, adding resources reduces output. * Low quality software has a complex relationship with costs. When production quality is too low, future productivity will be effected by the need to rework by fixing bugs.

Agile triangle.

Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

Principles behind the Agile Manifesto We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

TODO: Foo bar blah

Timeboxing plans a project as a sequence of time boxes, setting a rhythmic beat. Timeboxing separately control, review, reflection, performance, training and so on is beneficial for flow and ensures that activities conducive to the long term health of a project are not sacrificed for short term gain. Example: think about the drummer in a band, or the conductor in an orchestra. This rythym organically facilitates creativity without micromanagement

Software productivity is complex and non-linear. Labour is not interchangable, and the relationship between individual and team productivity is complex. Blending a team is an unpredictable art.

Orthodox estimation techniques used in project planning typically break down a complex project into a series of small tasks. Given high variance but unbiased estimates (in a statistical sense) over a long project estimation errors will balance to zero.

Unfortunately, these statistical qualities are unusual in software estimates. The statistics required to plan software projects goes beyond hoping errors sun to zero.

For example, estimates are provisional on the current state of knowledge, which is almost always incomplete. If missing information impacts a project, it is almost always in highly negative way. So, to model software estimates Guassians must be skewed or estimates will be biased.

Timeboxing allows an empirical alternative: velocity. For each iteration, measure progress. Every iteration, use this data to estimate future progress.

Keep Iterations Short Inductive learning is powerful: people find it fun and easy to learn this way[1]. [1] Providing that the culture is right. A positive culture of continuous improvement, driving quality and customer satisifaction ever higher. If you have a negative culture "the blame game", that weaker individuals will be targeted and blamed for poor performance. So when dealing. Group psychology has it's down side, as well. Remember this: often the rate of improvement is highest in the early days of learning a new skill. Progressing from compedency to mastery is a long and difficult road. If performance is judged on a team basis then it is in the best interests of masters to work with apprentices.

TODO: Foo bar blah

OpenTalkWare contributors to Timeboxing: An Introduction include Robert Burrell Donkin http://robertburrelldonkin.name