Context: We try to limit work in process, but progress is uneven and unpredictable. The team can’t plan experimentation and process improvement. Testing takes a growing amount of time as our product grows in complexity. Stakeholders can’t schedule review and release activities.
Unpredictable delivery makes planning difficult…
Teams that try to limit work in process, but complete work items of varying sizes whenever they finish, often become oblivious to growing “technical debt,” such as insidiously increasing testing time, longer team meetings, etc. Stakeholders can’t predict when to expect the next delivery. Different teams can’t easily plan, coordinate, and integrate their combined efforts. Teams tend to neglect process improvement experiments.
Forces
Several forces make achieving a steady, predictable rhythm of value delivery and improvement difficult:
- Work items often vary in size and complexity, leading to an uneven flow of completed work over time. Large items cause lumpiness in throughput [conc2013], creating congestion or idleness among team members, or between teams in a large project.
- With no time-commitments, teams often defer testing, improvement experiments, and retrospectives “until later,” and then stakeholder pressure for results cause teams to limit or abandon that important work. Poor quality, inefficient processes, and unhappy team members and stakeholders result [derb2006].
- Teams can’t easily plan for stakeholder feedback when they don’t know when the next increment will be “done” [paet2003].
- Projects that involve multiple teams, each producing increments “when they’re done,” can’t easily plan for integration and system testing.
- Team members can lose focus and drive when the completion date is uncertain [moe2010].
…therefore, deliver incremental value in rhythmic timeboxes
Establish a steady rhythm of value delivery and improvement by working in fixed time periods, called timeboxes. Deliver at least one increment of customer value per timebox. Leverage the fixed endpoint to drive focus, testing, stakeholder coordination, and process improvement [jako2009].
Rhythmic timeboxes can provide powerful benefits:
- Timeboxing work to a fixed period naturally limits the amount of work the team can start, preventing overloading and providing work in process limits.
- Since the timebox has a known, fixed duration, the team can plan and commit to delivering at least one valuable increment to stakeholders on a predictable cadence.
- Stakeholders know when they can expect to see working software and provide feedback. The team can coordinate with stakeholders and other teams more easily.
- Teams know they will have a chance to inspect and adapt their process at the end of each timebox. They can schedule retrospectives reliably.
- Short timeboxes provide frequent opportunities for the team to pivot and change direction based on stakeholder/customer feedback. This reduces risk [alsh2005].
- The time pressure of an imminent timebox deadline motivates the team to focus, act expediently and defer non-essential work. They avoid Parkinson’s Law, “the duration of tasks expand to fill their allotted time.”
- A steady rhythm of timeboxes provides a “heartbeat” for the project, fostering a sense of flow, momentum and sustainable pace for the team.
Examples
Scrum Sprints – Scrum, the most popular agile framework, is built around fixed development timeboxes called Sprints. Sprints typically last 1 to 4 weeks. The team delivers at least one potentially shippable product increment by the end of each Sprint. Sprint Reviews allow stakeholders to provide feedback. Sprint Retrospectives provide a regular opportunity for the team to identify process improvements. The imminent Sprint deadline drives focus.
XP Iterations – Extreme Programming (XP) typical use 1 to 2 week timeboxed iterations to deliver working software. Like Scrum Sprints, XP iterations have a planning, review and retrospective rhythm. The short iterations promote stakeholder feedback and rotating pairs keeps the team cross-functional.
Resulting Context
Rhythmic timeboxes provide a predictable cadence for delivering value to stakeholders and reflecting on process improvements. The fixed capacity of the timebox naturally limits work in process. The regular heartbeat fosters team focus, sustainable pace, and adaptation based on feedback. However, teams need certain practices to reap the full benefits:
- The team must decompose work into small items that fit within a timebox. They may need some up-front or preparatory work.
- The team must clearly define “done” so they deliver usable value each timebox. They should avoid carrying over or spilling over work.
- Teams should keep timeboxes short, ideally 2-4 weeks, to promote focus and limit risk. Shorter timeboxes provide faster feedback.
- Teams should limit the timebox scope commitment to provide slack for unexpected issues, improvement work and creative thinking. They shouldn’t overload themselves.
- Teams should schedule explicit time for improvement experiments and retrospectives at the end of each timebox. They should make it a consistent practice.
- Because the majority of the world operates in weeks, with work and school activities occurring on specific days of the week, a fixed number of weeks is a good timebox.
When combined with other agile patterns, rhythmic timeboxes create a powerful cadence for delivering value and continuously improving as a team. Teams can run experiments frequently to optimize the process. Subsequent patterns, like the Sprint in Scrum, can build upon this foundational rhythm.
References
[alsh2005] Alshayeb, M., & Li, W. (2005). An empirical study of system design instability metric and design evolution in an agile software process. Journal of Systems and Software, 74(3), 269–274. https://doi.org/10.1016/j.jss.2003.05.008
[conc2013] Concas, G., Marchesi, M., Destefanis, G., & Tonelli, R. (2013). An Empirical Study of Software Metrics for Assessing the Phases of an Agile Project. International Journal of Software Engineering and Knowledge Engineering, 23(06), 797–821. https://doi.org/10.1142/S0218194013500228
[derb2006] Derby, E., & Larsen, D. (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf.
[jako2009] Jakobsen, C. R., & Sutherland, J. (2009). Scrum and CMMI Going from Good to Great. 2009 Agile Conference, 333–337. https://doi.org/10.1109/AGILE.2009.31
[moe2010] Moe, N. B., Dingsøyr, T., & Dybå, T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology, 52(5), 480–491. https://doi.org/10.1016/j.infsof.2009.11.004
[paet2003] Paetsch, F., Eberlein, A., & Maurer, F. (2003). Requirements engineering and agile software development. WET ICE 2003. Proceedings. Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003., 308–313. https://doi.org/10.1109/ENABL.2003.1231428
Authors
This pattern was a collaboration of Daniel R Greening and Claude 3 Opus.