Choosing Iteration Length and Defining Team Practices in Agile Software Development
The article discusses how a software team selects an appropriate iteration cycle, establishes clear work agreements for each sprint, adopts single‑piece development with immediate testing, and introduces continuous integration to improve quality and efficiency in an agile environment.
Although the team has become familiar with the new working model, the start of the first iteration feels both exciting and uneasy, similar to a child beginning a new adventure.
1. How long should an iteration be? Should the cycle be variable? While many teams use a two‑week sprint, the author prefers a one‑week cycle, using a lake‑water analogy: a higher water level (longer iteration) hides problems, whereas lowering the level (shorter iteration) reveals issues sooner, enabling timely fixes.
The team ultimately chose the common two‑week iteration length.
2. Work agreements for each iteration – Consensus is essential for a high‑performing team. After the planning meeting, the team studied agile concepts and defined a workflow that includes daily stand‑ups at 10:00, weekly risk reviews on Friday mornings, mid‑sprint requirement grooming on Wednesday, a brief planning/review meeting on Friday afternoons (≤20 minutes), and a weekly retrospective (≤40 minutes).
3. Agreements for each requirement – After a feature is developed, it is handed to testers immediately, a practice called “single‑piece development, immediate testing.” This contrasts large‑scale production (high assumed defect‑free rate) with small‑batch delivery, aligning with Deming’s “Build Quality In” principle that quality should be embedded from the start, not achieved through mass inspection.
Because smaller requirements increase integration frequency, the team introduced continuous integration (CI). Previously CI was seen only as an automated packaging tool at the end of development, but true CI involves developers and testers integrating their work multiple times per day, with automated builds and tests to detect errors early.
Continuous Integration is a software development practice where team members frequently integrate their work—at least once per day—triggering automated builds and tests to quickly discover integration errors.
The article concludes that many specific challenges remain, which will be addressed in the next installment.
Continuous Delivery 2.0
Tech and case studies on organizational management, team management, and engineering efficiency
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.