I saw this on LinkedIn and it resonated so much with me I had to steal it.
Resignation Triggers Graphic
Lead Time to Value: The Metric That Actually Matters
Introduction
In the relentless pursuit of faster delivery, many engineering organisations obsess over velocity, sprint completion rates, and deployment frequency. Yet teams often find themselves moving faster whilst delivering less value. The critical metric that bridges this gap is Lead Time to Value (LTTV) – the elapsed time from when work is requested until it delivers measurable value to customers or the business.
Unlike traditional metrics that measure activity, LTTV measures outcomes. It forces us to confront an uncomfortable truth: shipping features quickly means nothing if those features sit unused, solve the wrong problem, or take months to generate their intended impact.
Understanding Lead Time to Value
Lead Time to Value encompasses the entire journey from idea to realised benefit:
Most teams measure only the middle portion (work started to deployed), but LTTV forces us to track the entire value stream, including:
- Discovery time: From idea to validated requirement
- Development time: From work started to code complete
- Deployment time: From code complete to production
- Adoption time: From production to meaningful user engagement
- Value realisation time: From deployment to measurable business impact
The Hidden Costs: Common Pitfalls
1. The ‘Deployed but Dormant’ Trap
The Problem: Teams celebrate deployment as done, whilst features languish unused.
A financial services company deployed a new mobile payment feature, hit their deployment target, and moved on. Six months later, usage data revealed only 3% adoption. The feature had been buried four menus deep, had no onboarding, and solved a problem users didn’t actually have. The true lead time to value? Effectively infinite.
Warning Signs:
- Feature flags left permanently enabled without usage tracking
- No post-deployment monitoring beyond error rates
- Success defined by “shipped” rather than “used”
- Product and engineering celebrating different dates
2. Optimising the Wrong Bottleneck
The Problem: Teams focus on development speed whilst ignoring longer delays elsewhere.
Many teams optimise their 10-day development cycle whilst 90+ days of waste exist in requirements, deployment queues, and post-deployment validation.
3. The Batch Size Blindspot
The Problem: Large batch sizes create inventory that delays value realisation.
Consider two scenarios delivering the same scope:
Scenario A (Large Batches):
- 10 features bundled into one quarterly release
- First feature waits 3 months for the last feature
- Average LTTV: 6-8 months
Scenario B (Small Batches):
- 10 features deployed independently over 3 months
- Each feature delivers value immediately upon completion
- Average LTTV: 2-3 months
Same scope, radically different value delivery.
4. Measurement Theatre
The Problem: Teams measure proxies instead of actual value.
Common proxy traps:
- “We deployed 47 features” – How many are used? Which delivered ROI?
- “Our cycle time is 5 days” – From where to where? What about the 60 days before and after?
- “We achieved 95% sprint commitment” – Did those features create the expected value?
5. The Handoff Tax
The Problem: Each handoff adds delay and information loss.
In organisations with siloed teams, work spends more time waiting between teams than being actively worked on. The handoff tax compounds, with each transition adding queue time, context switching, and requirement re-clarification.
Strategies to Reduce Lead Time to Value
1. Make Value Visible Throughout the Workflow
Action: Extend your definition of done beyond deployment.
Create a value realisation checklist:
- [ ] Feature deployed to production
- [ ] Monitoring and analytics instrumented
- [ ] Users can discover the feature
- [ ] User adoption tracked (target: X users in Y days)
- [ ] Business metric impact measured
- [ ] Learning documented and shared
Implementation:
Story Status: Deployed ✓ | Adopted ⏳ (12% of target) | Value Measured ✗
Time in Production: 8 days | Target Adoption: 14 days | Value Metric: Not yet significant
2. Implement Continuous Discovery
Action: Eliminate large upfront requirements phases.
Instead of:
- 6-week requirement gathering phase
- Hand specifications to engineering
- Begin development
Do:
- Lightweight hypothesis definition (1-2 days)
- Rapid prototyping or experiments
- Build smallest testable increment
- Measure and iterate
This transforms requirements from a phase into a flow, reducing the discovery component of LTTV from weeks to days.
3. Decompose Work Ruthlessly
Action: Challenge every story to be smaller.
Ask:
- Can this be split by user workflow steps?
- Can we deliver a manual/wizard version first?
- Can we expose this to 5% of users before 100%?
- What’s the smallest thing that could prove or disprove our hypothesis?
Example Decomposition:
Original story: “As a user, I want advanced search with filters for date, category, price, and ratings”
Decomposed:
- Basic keyword search (validates search need)
- Single most-requested filter (validates filtering)
- Remaining filters (completes capability)
Each increment delivers value faster and provides learning to guide subsequent work.
4. Eliminate Deployment Friction
Action: Make deployment routine, not an event.
Deploy:
- Multiple times per day, not per sprint
- Automatically, not via change requests
- Behind feature flags for progressive rollout
- With automatic rollback on failure
A deployment should be easier than pushing to a git branch. If it isn’t, that friction is directly extending your LTTV.
5. Build Value Tracking into Your Workflow
Action: Instrument features for value measurement before development starts.
Define upfront:
- What user behaviour indicates adoption?
- What business metric should improve?
- By how much and in what timeframe?
- How will we measure it?
Implement tracking as part of acceptance criteria, not as an afterthought.
6. Create Full-Stack Flow
Action: Organise teams around value streams, not technical layers.
Instead of:
- Frontend team → Backend team → Data team → Platform team
Create:
- Cross-functional team owning entire customer journey
- Team responsible for delivery AND value realisation
- Minimal handoffs between ticket creation and value measurement
7. Limit Work in Progress (WIP)
Action: Finish work before starting more.
With high WIP, everything takes longer and nothing delivers value. With strict WIP limits, work flows faster and value is realised sooner.
8. Run Value Retrospectives
Action: After features launch, conduct value retrospectives.
Review:
- What was our predicted value and timeline?
- What was the actual adoption and impact?
- How long did it take to achieve target value?
- What delayed value realisation?
- What would we do differently?
This creates a learning loop that improves estimation and reveals systemic LTTV bottlenecks.
Measuring Lead Time to Value
Start simple:
Basic LTTV: Date value realised – Date work requested
Component Breakdown:
LTTV = Discovery Time + Development Time + Deployment Time + Adoption Time
Instrumentation:
- Start timestamp: When work enters your backlog or discovery begins
- Development milestones: Track state transitions (ready → in progress → review → done)
- Deployment timestamp: When code reaches production
- Adoption metrics: First meaningful user engagement (logged in, completed workflow, etc.)
- Value metric: When business KPI shows significant change
Sample Dashboard:
Feature: Advanced Search
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Requested: 2025-01-15
Started: 2025-02-03 (19 days wait)
Deployed: 2025-02-17 (14 days dev)
10% Adoption: 2025-02-24 (7 days to adoption)
Value Target Met: 2025-03-08 (12 days to value)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Total LTTV: 52 days
Breakdown:
Queue time: 19 days (37%)
Development: 14 days (27%)
Time to adoption: 7 days (13%)
Time to value: 12 days (23%)
Getting Started: A Practical Approach
Week 1: Select three recent features. Reconstruct their journey from request to measurable value. Calculate LTTV and identify the longest delays.
Week 2: For new work, define value metrics upfront. Track them through delivery.
Week 3: Run a team workshop. Map your value stream. Identify the top three bottlenecks.
Week 4: Implement one change to address your largest bottleneck. Measure the impact.
Ongoing: Make LTTV visible. Include it in team retrospectives. Celebrate reductions in LTTV, not just deployment frequency.
Conclusion
Lead Time to Value forces uncomfortable questions: Are we building the right things? Are users adopting what we build? Is our work generating the expected impact? These questions lead to better outcomes than simply asking “are we moving fast?”
The teams that excel at LTTV share common characteristics:
- They measure outcomes, not output
- They optimise for learning, not prediction
- They deploy continuously, not periodically
- They own value realisation, not just code delivery
- They inspect their process relentlessly
Start measuring LTTV today. You’ll quickly discover that the path to faster value delivery looks quite different from the path to faster feature delivery. And in the end, value is what matters.
Remember: Every day a feature waits to deliver value is a day your organisation pays for work it hasn’t yet benefited from. Make the invisible visible, and optimise for what truly matters.
Cycle Time: A Complete Guide for Agile Teams
What is Cycle Time?
Cycle Time is one of the most critical metrics in agile software development, representing the elapsed time from when work begins on a feature, user story, or task until it’s completed and delivered to the customer. Unlike Lead Time, which measures from the moment work is requested, Cycle Time focuses specifically on active development time.
Think of it as the heartbeat of your delivery process – it tells you how quickly your team can transform ideas into working software once they commit to the work.
Understanding the Measurement
The Basic Formula
Cycle Time = End Date - Start Date
However, the devil is in the details. Teams must clearly define:
- Start Point: When does work actually begin? (e.g., when moved to “In Progress”, “Development Started”)
- End Point: When is work truly complete? (e.g., “Done”, “Released to Production”, “Accepted by Customer”)
Common Measurement Approaches
Story-Level Cycle Time Measures individual user stories or features from start to completion. This provides granular insights into delivery patterns.
Epic-Level Cycle Time Tracks larger pieces of work, useful for understanding delivery of substantial features or initiatives.
Defect Cycle Time Specifically measures how quickly bugs are resolved, often tracked separately from feature development.
Workflow States Diagram
The diagram below illustrates a typical development workflow and shows exactly where cycle time measurement begins and ends:
This visual representation helps teams understand that cycle time specifically measures active development time, excluding time spent waiting in queues before work begins.
How Teams Can Improve Cycle Time
1. Identify and Eliminate Bottlenecks
Use cumulative flow diagrams to spot where work queues up. Common bottlenecks include:
- Code review processes taking too long
- Testing phases creating delays
- Deployment processes that are manual or unreliable
- Dependencies on external teams or systems
2. Reduce Work in Progress (WIP)
Implementing WIP limits forces teams to focus on completing work rather than starting new items. This reduces context switching and helps identify blockers more quickly.
3. Break Down Large Work Items
Smaller stories flow through the system faster and provide earlier feedback. Aim for stories that can be completed within a few days rather than weeks.
4. Automate Repetitive Tasks
Investment in automation pays dividends in cycle time reduction:
- Automated testing pipelines
- Continuous integration and deployment
- Automated code quality checks
- Environment provisioning
5. Improve Handoff Processes
Smooth transitions between team members or stages reduce delays:
- Clear definition of done for each stage
- Standardised handoff procedures
- Good documentation and communication practices
6. Address Technical Debt
Technical debt slows down development over time. Regular investment in code quality, refactoring, and infrastructure improvements maintains healthy cycle times.
Understanding Cycle Time Distribution
Rather than focusing solely on averages, teams should examine the full distribution of their cycle times:
Cycle Time Histogram Example
Cycle Time Distribution (Days)
0-2 days: ████████████████████ (40%)
3-5 days: ████████████████ (32%)
6-10 days: ██████████ (20%)
11-20 days: ████ (8%)
20+ days: ▓ (<1%)
Average: 4.2 days
85th Percentile: 8 days
95th Percentile: 15 days
The 85th percentile is often more meaningful than the average, as it represents predictable delivery for most work items whilst excluding outliers.
Risks and Anti-Patterns
The Gaming Problem
When cycle time becomes a primary target, teams may game the system:
Clock Stopping: Moving items back to earlier stages to reset timers Cherry Picking: Only taking on easy, quick tasks to improve metrics
Scope Creep in Reverse: Reducing quality or cutting corners to hit time targets Definition Manipulation: Changing start/end definitions to show improvement
Quality Degradation
Pressure to reduce cycle time can lead to:
- Skipping proper testing procedures
- Inadequate code reviews
- Technical debt accumulation
- Poor documentation
Inappropriate Comparisons
Comparing cycle times across different types of work or teams can be misleading:
- Bug fixes vs new features
- Simple CRUD operations vs complex algorithm development
- Teams with different skill levels or domain expertise
- Work requiring external dependencies vs self-contained tasks
Preventing Gamification
1. Use Multiple Metrics
Balance cycle time with:
- Quality metrics: Defect rates, customer satisfaction
- Throughput: Number of items completed
- Predictability: Variance in delivery estimates
- Value delivery: Business outcome metrics
2. Focus on Trends, Not Absolutes
Look for sustained improvement over time rather than hitting specific targets. Celebrate progress whilst investigating anomalies.
3. Understand Context
Always consider:
- Complexity of work being delivered
- External factors affecting the team
- Changes in team composition or skills
- Infrastructure or tooling changes
4. Involve the Team in Analysis
Teams should own their metrics and drive improvement initiatives. This reduces the likelihood of gaming and increases buy-in for genuine improvements.
Cycle Time in Different Contexts
Kanban Teams
Cycle time is a core metric, often displayed on cumulative flow diagrams and used for probabilistic forecasting.
Scrum Teams
While sprint-based, tracking cycle time within sprints helps identify process inefficiencies and supports continuous improvement.
Support Teams
Cycle time for incident resolution provides insights into operational effectiveness and customer impact.
Advanced Cycle Time Analysis
Cycle Time Breakdown
Understanding where time is spent within the cycle:
Average 8-day Cycle Time Breakdown:
Development: 3 days (37.5%)
Code Review: 1 day (12.5%)
Testing: 2 days (25%)
Deployment: 0.5 days (6.25%)
Waiting/Blocked: 1.5 days (18.75%)
This analysis reveals that nearly 19% of cycle time is wait time – a clear improvement opportunity.
Seasonal and Trend Analysis
Cycle times may vary based on:
- Team capacity (holidays, training periods)
- External factors (compliance deadlines, market events)
- Technical factors (infrastructure changes, major releases)
Tracking these patterns helps with planning and expectation setting.
Tools and Implementation
Popular Tools for Cycle Time Tracking
- Jira: Built-in cycle time reports and custom dashboards
- Azure DevOps: Analytics and custom queries
- Linear: Native cycle time tracking and insights
- GitHub: Third-party analytics tools and API integrations
Getting Started
- Define your workflow stages clearly
- Establish consistent start and end points
- Collect baseline data for 4-6 weeks
- Analyse patterns and identify improvement opportunities
- Implement changes incrementally
- Monitor impact and adjust
Conclusion
Cycle time is a powerful metric for understanding and improving delivery performance, but it must be used thoughtfully. When balanced with quality metrics and understood in proper context, it provides valuable insights into team effectiveness and process health.
The goal isn’t simply to reduce cycle time at any cost, but to create a sustainable, predictable delivery process that consistently provides value to customers. By focusing on genuine process improvements rather than metric manipulation, teams can achieve faster delivery whilst maintaining high standards.
Remember: the best cycle time metric is one that drives the right behaviours and helps your team deliver better outcomes for your customers.
Kanban vs Scrum: Choosing the Right Agile Framework for Your Team
Agile methodologies have revolutionised software development and project management, offering flexible approaches to delivering value incrementally. Among the most popular frameworks are Kanban and Scrum, each with distinct philosophies and practices. Understanding their differences, strengths, and weaknesses is crucial for teams seeking to optimise their workflow and productivity.
Understanding Kanban
Kanban, derived from the Japanese word for “visual signal,” originated in Toyota’s manufacturing system before being adapted for knowledge work. It emphasises continuous flow and visual management, focusing on limiting work in progress (WIP) to improve efficiency.
Core Principles of Kanban
Kanban operates on four fundamental principles: start with existing processes, pursue incremental change, respect current roles and responsibilities, and encourage leadership at all levels. The method doesn’t prescribe specific roles or ceremonies, instead providing a framework for continuous improvement.
Key Characteristics
The Kanban board serves as the central tool, typically divided into columns representing different stages of work such as “To Do,” “In Progress,” and “Done.” Work items flow through these columns, with WIP limits preventing bottlenecks. Teams pull work when capacity becomes available, rather than having work pushed onto them.
Understanding Scrum
Scrum is a structured framework that organises work into fixed-length iterations called sprints, typically lasting one to four weeks. It emphasises empirical process control through inspection, adaptation, and transparency.
Core Components of Scrum
Scrum defines specific roles: the Product Owner manages the product backlog and stakeholder requirements, the Scrum Master facilitates the process and removes impediments, and the Development Team delivers working software increments. The framework includes ceremonies such as sprint planning, daily standups, sprint reviews, and retrospectives.
Key Characteristics
Work is organised into sprints with defined goals and deliverables. The team commits to completing specific items from the product backlog during each sprint. Regular ceremonies provide rhythm and structure, ensuring continuous communication and improvement opportunities.
Visual Comparison
Advantages of Kanban
Flexibility and Adaptability
Kanban’s greatest strength lies in its adaptability. Teams can easily adjust priorities and accommodate urgent requests without disrupting predetermined sprint commitments. This flexibility makes it particularly suitable for support teams, maintenance work, or projects with frequently changing requirements.
Visual Management
The visual nature of Kanban boards provides immediate transparency into work status and bottlenecks. Team members can quickly identify where work is accumulating and take corrective action. This visual feedback loop promotes self-organisation and continuous improvement.
Continuous Delivery
Without fixed iterations, teams can deliver value as soon as work is completed. This approach reduces lead times and enables faster response to customer needs or market changes.
Reduced Overhead
Kanban requires minimal ceremonies and meetings compared to Scrum. Teams spend less time in planning sessions and more time delivering value, making it attractive for organisations seeking to minimise process overhead.
Disadvantages of Kanban
Lack of Structure
The flexibility that makes Kanban attractive can also be its weakness. Without defined roles, ceremonies, or timeboxes, some teams may struggle with accountability and direction. New agile teams particularly benefit from the structure that Scrum provides.
Measurement Challenges
Whilst Kanban focuses on flow metrics like lead time and cycle time, it can be more difficult to predict delivery dates or plan capacity compared to Scrum’s velocity-based approach.
Potential for Scope Creep
The continuous nature of Kanban can lead to endless work streams without clear boundaries or completion criteria. Teams may find it challenging to maintain focus without sprint goals.
Advantages of Scrum
Structured Framework
Scrum provides clear roles, responsibilities, and ceremonies that help teams establish productive working patterns. The framework is particularly valuable for new agile teams or organisations transitioning from traditional project management approaches.
Predictable Delivery
Sprint-based planning enables teams to make commitments and provide stakeholders with predictable delivery timelines. Velocity tracking helps improve estimation accuracy over time.
Regular Inspection and Adaptation
Scrum’s ceremonies create built-in opportunities for reflection and improvement. Sprint reviews gather stakeholder feedback, whilst retrospectives focus on process improvements.
Goal-Oriented Approach
Sprint goals provide focus and prevent teams from being overwhelmed by endless backlogs. The time-boxed nature ensures regular completion of work increments.
Disadvantages of Scrum
Rigid Structure
The prescribed ceremonies and roles can feel constraining for experienced teams or those working in environments requiring high flexibility. Some organisations struggle with the overhead of multiple meetings.
Difficulty with Urgent Changes
Once a sprint has begun, changes are discouraged to maintain team focus. This can be problematic in environments where urgent issues frequently arise.
Potential for Burnout
The sprint-based approach with regular commitments can create pressure and stress, particularly if teams consistently over-commit or face unrealistic expectations.
Planning Overhead
Sprint planning, reviews, and retrospectives require significant time investment. For some teams, this ceremony overhead may outweigh the benefits.
When to Choose Kanban
Operational and Support Teams
Teams handling incidents, bug fixes, or customer support benefit from Kanban’s flexibility and continuous flow. The ability to prioritise urgent items without disrupting planned work is crucial in these environments.
Mature, Self-Organising Teams
Experienced teams with strong self-management capabilities can leverage Kanban’s minimal structure whilst maintaining productivity and focus.
Unpredictable Work Patterns
When work arrives irregularly or priorities change frequently, Kanban’s pull-based system provides the necessary adaptability without the constraints of fixed iterations.
Continuous Delivery Environments
Teams practising continuous integration and deployment can benefit from Kanban’s support for continuous delivery without artificial sprint boundaries.
When to Choose Scrum
New Agile Teams
Teams new to agile methodologies benefit from Scrum’s structured approach, defined roles, and regular ceremonies that establish good working patterns.
Product Development
When building new products or features with defined requirements and deadlines, Scrum’s sprint-based planning provides structure and predictability.
Stakeholder Engagement
Regular sprint reviews and demonstrations help maintain stakeholder engagement and gather valuable feedback for product development.
Teams Requiring Structure
Some teams perform better with clear boundaries, defined roles, and regular ceremonies. Scrum provides this structure whilst maintaining agile principles.
Hybrid Approaches and Other Frameworks
Many organisations adopt hybrid approaches, combining elements of both frameworks. “Scrumban” incorporates Scrum’s ceremonies with Kanban’s flow-based approach, providing structure whilst maintaining flexibility.
Other relevant agile frameworks include Extreme Programming (XP), which emphasises technical practices like pair programming and test-driven development, and the Scaled Agile Framework (SAFe), designed for large enterprise environments. Lean methodology, focusing on waste elimination and value stream optimisation, also influences many agile implementations.
Making the Right Choice
The decision between Kanban and Scrum shouldn’t be based solely on theoretical advantages. Consider your team’s maturity, work patterns, organisational culture, and stakeholder needs. Many successful teams start with one approach and evolve their practices over time.
Assessment Criteria
Evaluate your team’s need for structure versus flexibility, the predictability of your work patterns, stakeholder expectations for delivery timelines, and the team’s experience with agile methodologies.
Experimentation and Adaptation
Consider starting with a time-boxed trial of your chosen approach. Both frameworks emphasise continuous improvement, so be prepared to adapt your practices based on what you learn.
The choice between Kanban and Scrum isn’t permanent. As teams mature and circumstances change, you may find that different approaches serve your needs better. The key is selecting the framework that best supports your team’s ability to deliver value whilst maintaining sustainable working practices.
Both Kanban and Scrum have proven successful across countless teams and organisations. The right choice depends on your specific context, team characteristics, and organisational needs. By understanding the strengths and limitations of each approach, you can make an informed decision that sets your team up for success in their agile journey.
Performance Reviews – Forcing a Bell Curve?
Forcing a bell curve in performance reviews creates several significant problems:
Artificial scarcity of high performance – A bell curve assumes that only a fixed percentage of employees can be top performers, regardless of actual performance levels. If you have a strong team where most people are genuinely performing well, you’re forced to artificially label some as “average” or “below average.”
Destroys collaboration – When employees know they’re competing against each other for limited “high performer” slots, it incentivises hoarding information, avoiding knowledge sharing, and even sabotaging colleagues. This is particularly damaging in roles that require teamwork.
Punishes small teams disproportionately – In a team of 5 people, forcing one person into the bottom 20% means someone gets labelled as underperforming even if all five are actually doing brilliant work. The statistical assumption breaks down with small sample sizes.
Ignores actual performance data – Performance isn’t naturally distributed in a bell curve across teams. Some teams might genuinely have mostly strong performers (especially after good recruitment and development), whilst others might have more improvement needs. Forcing a predetermined distribution ignores reality.
Creates unfair outcomes – High performers might be rated as “average” simply because there are too many good people on their team, whilst average performers on weaker teams might be rated as “high performers.” This destroys the credibility of the entire review process.
Demotivates good employees – Nothing kills morale faster than being told you’re “bottom 10%” when you know you’re doing solid work, just because someone had to fill that slot.
The alternative is to evaluate people against clear performance standards and role expectations, not against each other. This allows for more accurate feedback and fairer treatment whilst still maintaining accountability.
Why Annual Performance Reviews Are Failing Software Engineers and Scrum Teams
Annual performance reviews have become a corporate ritual that many organisations cling to, despite mounting evidence that they’re particularly ill-suited to the world of software development. For software engineers and scrum teams, these yearly assessments create more problems than they solve, undermining the very principles of agility, continuous improvement, and collaborative development that drive successful software projects.
The Fundamental Mismatch
Software development operates on principles that are fundamentally at odds with annual review cycles. Modern software engineering embraces rapid iteration, continuous feedback, and adaptive planning. Annual reviews, by contrast, are rigid, retrospective, and often disconnected from the day-to-day realities of software development.
The Agile Contradiction
Agile methodologies, which most software teams have adopted, are built around short feedback loops and continuous adaptation. Teams work in sprints lasting 1-4 weeks, with regular retrospectives and adjustments. The idea of waiting an entire year to provide meaningful feedback about performance contradicts everything agile stands for.
Consider a typical agile team’s feedback cycle:
- Daily standups for immediate coordination
- Sprint reviews every 2-4 weeks
- Sprint retrospectives for continuous improvement
- Regular one-to-ones between team members and leads
Now contrast this with an annual review that attempts to summarise 12 months of work in a single meeting. The disconnect is glaring.
The Memory Problem
Software development projects are complex, with countless decisions, trade-offs, and collaborative efforts happening throughout the year. By the time an annual review comes around, both managers and engineers struggle to remember the specifics of what happened months ago.
What Gets Lost
- Context of decisions: Why certain technical choices were made
- Collaborative contributions: Who helped whom solve difficult problems
- Learning moments: Specific instances of growth and skill development
- Project challenges: The real obstacles faced and overcome
This memory decay leads to reviews that focus on the most recent work or the most memorable incidents—neither of which provides a fair or comprehensive picture of annual performance.
The Individual vs Team Performance Paradox
Software development is inherently collaborative. Modern applications are far too complex for any single developer to build alone. Yet annual reviews typically focus on individual performance, creating a fundamental mismatch with how software is actually created.
The Collaborative Reality
In a typical software project:
- Pair programming makes it impossible to attribute code to individuals
- Code reviews mean multiple people contribute to every feature
- Cross-functional teams require constant collaboration between developers, designers, and product owners
- Knowledge sharing is essential for team resilience and growth
Annual reviews that attempt to rate individual contributions often miss these collaborative dynamics entirely, potentially rewarding the wrong behaviours and undermining team cohesion.
The Innovation Killer
Software engineering requires experimentation, risk-taking, and learning from failure. Annual reviews, however, often penalise these essential activities, particularly when they don’t lead to immediate, measurable success.
The Risk Aversion Effect
When engineers know their annual review will focus on completed deliverables and measurable outcomes, they tend to:
- Avoid experimental approaches that might fail
- Stick to familiar technologies rather than exploring new solutions
- Focus on individual achievements rather than team learning
- Resist taking on challenging problems that might not have clear solutions
This risk aversion is particularly damaging in software development, where innovation and technical evolution are crucial for long-term success.
The Scrum Team Disruption
Scrum teams are designed to be self-organising and continuously improving. Annual reviews can disrupt this natural rhythm by imposing external judgements that may not align with team dynamics or goals.
Undermining Self-Organisation
Scrum teams work best when they can:
- Collectively decide how to approach problems
- Adapt their processes based on what they learn
- Support each other’s growth and development
- Focus on delivering value to customers
Annual reviews often undermine these principles by:
- Imposing individual performance metrics that may conflict with team goals
- Creating hierarchical judgements that disrupt team equality
- Focusing on past performance rather than future improvement
- Diverting energy from delivery to performance theatre
The Feedback Timing Problem
In software development, feedback is most valuable when it’s immediate and actionable. A bug found during development is much easier to fix than one discovered months later. The same principle applies to performance feedback.
Why Timing Matters
- Technical skills: Feedback on coding practices is most useful when given during code reviews or pair programming sessions
- Collaboration: Issues with team dynamics need addressing immediately, not months later
- Learning opportunities: Guidance on new technologies or approaches is most valuable when someone is actively working with them
- Career development: Discussions about growth and advancement are most productive when they happen in real-time
Annual reviews, by their very nature, provide feedback that is often too late to be genuinely useful for improvement.
The Metrics Trap
Annual reviews often rely on metrics that are poorly suited to software development. Lines of code, number of commits, or tickets closed may seem objective, but they can actively encourage counterproductive behaviour.
Misleading Measurements
Common metrics used in annual reviews include:
- Lines of code: More code isn’t necessarily better code
- Number of commits: Encourages frequent, small commits that may not add value
- Tickets closed: Rewards quantity over quality and complexity
- Bug count: May discourage working on challenging or experimental features
These metrics can lead to gaming behaviours that actually harm software quality and team dynamics.
Better Alternatives for Software Teams
Rather than abandoning performance management altogether, software teams need approaches that align with their working methods and values.
Continuous Feedback Models
Regular One-to-Ones: Weekly or bi-weekly conversations between team members and leads, focusing on current challenges and growth opportunities.
Sprint Retrospectives: Team-wide discussions about what’s working well and what could be improved, with immediate action items.
Peer Feedback: Regular, informal feedback between team members during code reviews, pair programming, and collaborative work.
360-Degree Reviews: Quarterly or semi-annual reviews that include feedback from multiple team members, stakeholders, and customers.
Growth-Focused Approaches
Individual Development Plans: Ongoing conversations about career goals, learning objectives, and skill development, reviewed and updated regularly.
Skill Matrices: Visual representations of team capabilities and individual growth areas, updated continuously as skills develop.
Learning Goals: Setting and tracking progress on specific learning objectives, with regular check-ins and adjustments.
Project Retrospectives: Detailed reviews of completed projects, focusing on what was learned and how to apply those lessons to future work.
The Path Forward
Moving away from annual reviews requires a cultural shift that many organisations find challenging. However, the benefits for software teams are substantial:
Immediate Benefits
- Improved team dynamics: Regular feedback reduces conflicts and improves collaboration
- Better technical outcomes: Continuous improvement leads to higher quality software
- Enhanced job satisfaction: Engineers feel more supported and valued
- Increased innovation: Reduced risk aversion encourages experimentation
Long-term Advantages
- Stronger team culture: Continuous feedback builds trust and psychological safety
- Better retention: Engineers are more likely to stay with organisations that invest in their ongoing development
- Improved delivery: Teams that communicate well and support each other deliver better results
- Organisational agility: Companies can adapt more quickly to changing market conditions
Conclusion
Annual performance reviews represent an outdated approach to performance management that is fundamentally incompatible with modern software development practices. For software engineers and scrum teams, these yearly assessments create artificial barriers to the continuous improvement, collaboration, and innovation that drive successful software projects.
The solution isn’t to abandon performance management altogether, but rather to adopt approaches that align with the principles and practices that make software teams successful. By embracing continuous feedback, collaborative growth, and team-focused development, organisations can create environments where software engineers thrive and deliver exceptional results.
The future of performance management in software development lies not in annual judgements, but in ongoing conversations, continuous learning, and collective success. It’s time to leave the annual review behind and embrace performance management approaches that actually work for the way software is built today.
Distributed Agile Teams Discussion
This is quite a useful discussion/presentation to watch if you’ve got remote members in your agile teams or you’ve got multiple agile teams spread across different geographies.
It’s by Professional Scrum Trainer Punit Doshi.
The main presentation starts at 8:07 so I’d skip to there if I were you.
It discusses non-collocated teams and teams with members across global demographics.
Highlights that it’s preferable to have the scrum master in the same time zone as the majority of the team, ideally collocated.
It describes anti-patterns to look out for within teams that are an indicator that things are going, or will go, wrong.
It also lists key things to do with distributed teams to make it work; team members must feel and work like one team.
The Daily Scrum
The Daily Scrum is a vital part of the agile framework. It is an opportunity for the development team to review progress and highlight issues or impediments that are preventing them from progressing effectively.
Who attends the Daily Scrum?
The only mandatory attendees are the development team; this is important to remember as it helps enforce that team autonomy and self-managing mentality it needs. The Scrum Master’s role is to ensure that the ceremony happens and that the team know what needs to happen but their attendance is not essential. It can be useful to have the Product Owner present if there are queries about the stories the team are working on.
What happens in the Daily Scrum?
The Daily Scrum is a key ceremony to share information about progress on the current sprint. It is important that it doesn’t turn into a major time-sink for the team and for that reason member’s updates should be concise and not verbose and the whole ceremony should be time-boxed to 15 minutes.
Generally, in order to give member’s a prompt, there are three key questions that each member can answer:
1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments or obstacles in your way?
This gives the rest of the team a clear update on progress. It’s where potential clashes can be identified and resolved and also provides a platform where risks can be raised within the team or to the Scrum Master for resolution.
In my Experience
When first implementing Scrum it can be difficult for the team to understand the purpose of the Daily Scrum, however it’s one of the ceremonies that is so important. One of Scrum’s core values is transparency, not just outside but inside the team. A symptom of smaller, non-agile teams is that team members are often siloed into verticals – areas of expertise within technology or functionality and this ultimately causes bottlenecks in the development cycle. If the team has a detailed view and understanding of their colleague’s workloads and issues then they should feel more inclined to assist in offering a solution, this can lead to a smooth organic adoption of pair programming.
Managers and Scrum Masters should continuously enforce the principal that the team are responsible for the success or failure of the sprint; it should not fall onto one individual within the team. We succeed as a team and we fail as a team. I’ll go into developing a team mindset in a later blog post.
Some team members will obviously be more outspoken than others so as a Scrum Master try and encourage each team member to give a useful update. Keep an eye on the current sprint and if someone is still on the same story as they were yesterday then gently nudge them to explain why; it could be they need assistance but are too insecure to ask for it.
Conversely if some discussions are beginning to become too verbose then introduce a method of timeboxing updates. I’ve used tactics such as a red card – if team members feel that one or more members are discussing an item in too much detail then they can hold up the red card to stop the discussion and encourage it to be taken out of the Daily Scrum to be discussed later.