Iterative Development and Cadence

2 posts · Jun 2017 – Nov 2022

What this trail covers

GitLab emphasizes iterative development, breaking down work into the smallest possible changes (MVCs) to accelerate value delivery, reduce risk, and enable faster learning. This approach is applied to both regular development and experiments, with a focus on shipping early and often to gather feedback and make evidence-based decisions. The MR Rate is used as a key performance indicator to measure engineering productivity, with strategies to increase it including improving iteration, setting KPIs

All GitLab trails

Nov 2022Cadence is everything: 10x engineering organizations for 10x engineersThis post introduces the concept of 'cadence' and 'iteration' as a fundamental principle for engineering organization productivity. It contrasts slow, monolithic development cycles with rapid, iterative approaches, using examples from aviation (Gossamer Condor) and spaceflight (SpaceX). It highlights the mathematical and human factors behind iterative improvement, referencing the DORA metrics from the 'Accelerate' book as scientific evidence for the correlation between short cycle times and high software development performance. The post advocates for an organizational structure that prioritizes short cycle times and embraces failure as a learning opportunity, aligning with the XP value of 'courage'.
Apr 2021Why iterative software development is criticalThis post details the importance of iterative software development and the MVC (minimal viable change) philosophy at GitLab. It uses the 'suggest a pipeline' experiment as a case study to illustrate the pitfalls of not iterating small enough and the benefits of shipping smaller, more frequent iterations. It also introduces the 'invite members' experiment as an example of applying these learnings through a painted door test.
Mar 2021Why small merge requests are key to a great reviewThis post elaborates on the iterative development philosophy by applying it to the code review process. It argues that smaller merge requests (MRs) are crucial for effective code reviews, reducing complexity, minimizing merge conflicts, and improving reviewer efficiency. It introduces the concept of 'DangerBot' for enforcing MR size limits and suggests strategies for handling large MRs, such as creating follow-up MRs. The post also provides practical tips for authors and reviewers regarding follow-up reviews and emphasizes the benefits of small MRs for both the author and the reviewer.
Aug 2020How we measure engineering productivity at GitLabThis post details GitLab's approach to measuring engineering productivity using Merge Request (MR) Rate as a Key Performance Indicator (KPI). It explains the MR Rate formula, its rationale for incentivizing iteration and faster feature delivery, and the challenges associated with using a single metric. The post outlines strategies to increase MR Rate, including improving iteration, setting KPIs and OKRs, and empowering teams. It also discusses the importance of balancing team vs. individual metrics to foster collaboration and avoid siloed behavior. The post introduces related metrics like Product MRs by Type and Say Do Ratio to provide a more holistic view of productivity.
Aug 2020Want to iterate faster? Choose boring solutionsThis post provides concrete examples of 'boring' technical decisions made at GitLab that contribute to faster iteration and reduced complexity. Examples include using issue labels for issue boards, using `curl` against API endpoints instead of building new UIs, using JSON Web Tokens for Vault authentication, adding small UI awareness features (e.g., security scanner enablement), choosing between dropdown types based on data, making issue titles sticky, and using SQL for the CI job queue. It also mentions the migration from Gitolite to a new solution when the former became a bottleneck, and the use of a checklist for the Azure to GCP migration.
Advertisement
May 2020Why iteration helps increase the merge request rateThis post elaborates on the concept of iterative development and its impact on increasing the merge request rate, drawing parallels to John Boyd's Law of Iteration ('speed of iteration beats quality of iteration'). It emphasizes fostering a team environment with a bias for action, accepting that 'all code is bad code' to overcome impostor syndrome and fear of failure, and the importance of writing things down to preserve knowledge and reduce communication overhead. It also highlights the need to tighten feedback loops by refining issues to be truly 'ready for development' to enable autonomous and asynchronous work.
Dec 2019Optimizing The Value Exchange: Reduce Waste To Increase FlowThis post details the application of waste reduction principles from the Toyota Production System (TPS) to improve flow in the value delivery system. It identifies 'waiting' as a significant source of waste, with work items spending ~85 days waiting between queues. The post describes an experiment with pair programming to eliminate the code review stage and reduce lead time, resulting in a 57% reduction. It also analyzes the financial impact of these changes and the shift in work item breakdown from features to defects and technical debt, emphasizing the need to address technical debt to enable faster feature delivery.
Apr 2019Why improving continuously speeds up deliveryThis post introduces the concept of continuous improvement through small changes (Kaizen) and relates it to DevOps principles (The Three Ways) and value stream management. It emphasizes identifying the slowest step in the value stream and making incremental improvements to reduce cycle time. Three suggestions are provided: simplify scope, empower teams, and measure the value stream.
Oct 201810 strategies for cycle time reductionThis post contributes strategies for reducing cycle time by focusing on: 1. Getting it right the first time through automation (CI, automating manual tasks), working with smaller iterative pieces, and using feature flags. 2. Differentiating helpful from unhelpful processes by measuring impact and experimenting. 3. Successfully working across teams via communication, automation, developing training programs, using project management tooling, and spreading triaging. 4. Making asynchronous communication work by having multiple items to work on.
Sep 20184 Examples of MVCs with big resultsThis post introduces four specific Minimally Viable Changes (MVCs) that delivered significant value: 1. Assignee lists and milestone lists for issue boards, enhancing team bandwidth monitoring and issue management. 2. Redesign of the merge request widget info and pipeline sections for better digestibility. 3. Addition of a groups dropdown to the top navigation for easier switching between groups. 4. A confidential issue quick action for marking issues as confidential directly from the comment field.
Jun 2017How to shorten the conversation cycleThis post introduces strategies for shortening the conversation cycle in software development. It advocates for measuring cycle time to identify delays, breaking down features into Minimum Viable Changes (MVCs) for faster iteration, involving stakeholders (gatekeepers) early in the process to prevent bottlenecks, and communicating the benefits of this approach to gain team buy-in. The core idea is to move towards smaller, more frequent releases to accelerate the time between idea conception and production deployment.
Jun 2017Workflow tips to ship faster without sacrificing security or qualityThis post details workflow tips for accelerating the development lifecycle without sacrificing security or quality. It emphasizes making security a first-class citizen by involving security experts early in the development process. Workflow best practices include making smaller changes and committing often, involving experts and reviewers early, getting code into staging or test environments earlier, and leveraging the community to spot and prioritize security issues and bugs faster through bug bounty programs.