Agile Transformation Guide and Resources

Table of Contents:

Purpose & Journey

In October 2025, we completed a 3-month Agile Transformation to move from traditional waterfall process to a lightweight Agile-inspired framework.

Goals of Engagement

We had several goals in mind, shown here roughly in order of priority:

• Eliminate design escapes
• Improve cross-functional awareness and alignment
• Increase confidence in functionality of tape out
• Enable systematic backward planning from GTM goals
• Promote knowledge capture and clarity through docs & demos
• Reduce meetings and ad hoc updates

Progress and Accomplishments

We established a firm foundation in Agile processes. The team has established a bi-weekly sprint cadence, created high-level framework to align with Go To Market (GTM) and tape-out milestones, wrote its definition of done, crafted examples of well-written stories, and put the rituals and tracking mechanisms in place to ensure execution and continuous improvement. Here is a recap of what we’ve accomplished:

✅ Define framework that aligns GTM milestones, tapeouts, and sprints

This provides an orientation to “where we are” for every person in the company and connects daily work with the big picture

✅ Establish bi-weekly staggered sprint cadence

✅ Leverage “Sprint Quality Checklist” as clear definition of done for each sprint

✅ Utilize “Sprint Quality Scorecard” to monitor ongoing quality and frame continuous improvement conversation

✅ Definition of done per story — “Minimal Viable Done”

✅ Craft example sprint-ready stories

We crafted sprint-ready stories for specific personas and value propositions. Each story aims for a “Minimum Viable Value Proposition” that can ideally be implemented in the span of a single sprint. Short of this, it is okay for the sprint goal to advance the story a single step on the Kanban board — e.g. to move from “Design” to “Verification”. If this is not achievable in a single sprint, try to articulate a smaller story and if that’s not possible create “Tasks” within the story that can be completed independently. (Text of top-voted stories below.)

✅ Define “done” at a story level

Creating a workable minimal-viable checklist to consider a story complete to incorporate above the Kanban board.

Further Reading and Detail

Ongoing Change Management

Transforming from Waterfall to Agile is not a one-and-done process. The spirit of agile is regular improvement.

Here is a TCGen primer on the overall process:

And a couple of pointers:

• Our overall approach of sprints within tape-outs aligns with the “nested sprints” outline provided in the article:

  

Agile with a small “a” consists of three things:

1. Sprints or iterations of a fixed length
2. A demo or other artifact at the end of each sprint indicating the status of the project
3. A transparent tracking mechanism for projects

Sprint-Ready Stories

There’s lots of advice on how to write good user stories that will need some adaption to a semiconductor. However, there are three frameworks that will be largely applicable:

Best Practice Example

A well-written story will generally follow this format:

“As a [persona who will benefit], I want to [capability to create], so that [value proposition].”

It should aim for a minimal value proposition — i.e. the smallest increment of work that still delivers value to a customer.

Team-Written Examples — Top Votes

Here are examples written by the team that follow best practices. Each one emphasizes a specific capability of a specific persona, grounding it not in a feature or a spec but in a concrete value proposition.

• “As a IC designer, I would like the chip to have NVM memory to enable chip customization such as chipID and circuit process calibrations so that the chip can be identified and so that its performance can be tuned in to meet requirements.”
• “As a systems lead, I would like to have a fan-out substrate available for testing the A0 and A1 ASIC so that we can get early test data and de-risk customer sample delivery in Q2/Q3 2026.”
• “As an analog/PM IC design, I want to design an automatic deadtime circuit that can adjust the deadtime automatically according to the load current such that the PMIC can deliver optimal power efficiency for the customers.”

Three Cs

We discussed the “three C’s” as an easy mnemonic to cover the basics of a good story.

• Card — a concise physical or digital representation of the story, with a summary of the problem to be solved. Basically puts a handle on the idea for tracking.
• Conversation — this covers the who, what, when, and how, and could be thought of as a shorthand for the story being both valuable and feasible in a single sprint.
• Confirmation — shorthand for the idea that the team agrees that the story is both reasonably understood and testable.

Transparent Tracking Mechanism: Kanban Board

Conceptually, a Kanban Board visually tracks “stories” as they move from “ready” to doing to done. (Expand each toggle below to see examples.)

Simplest “Kanban” is just a list of Sprint-Ready stories at outset and Completed stories at the end

Agile emphasizes “sprint-ready” over “plan”. It’s valuable at outset to share what you hope to get done, but the emphasis is on getting as many stories as possible fully done each sprint, rather than trying to accurately predict at the outset. This can be visually emphasized by adding a “Doing” column to indicate once a story has started.

Kanban boards can expand to manage multiple steps that a story goes through in the journey, for example:

⚠️ Note that Agile emphasizes the steps a story goes through rather than “who owns each step.” Notice the way in which this diagram emphasizes team ownership rather than the progression of the story. Avoid this.

💡Conceptually, Kanban boards are meant to help visualize and limit “WIP” at each step along the way to eliminate bottlenecks. The goal is to move one story through to the next stage prior to taking on the next one. This diagram illustrates the idea that each step has WIP and Done, where Done is synonymous with “Ready for next step.” I don’t recommend modeling this level of complexity, but think it’s helpful to illustrate the mental model.

Here is an example of a near-term board with a reasonable balance of simplicity and visual capability. It illustrates clarity of stage, estimate of complexity (low, medium, high), a concise story title and brief description. All packaged into an easily digestible tracking mechanism. (Link in caption to full board.)

Example Kanban Board for Chip Design

End of Sprint Artifact: “Always One Sprint Away From Tape Out”

Ralph Hofman & Davar Azarmi capture the spirit of Agile software deploying to production while recognizing the reality that actually taping out every sprint is ridiculous. But its spirit shifts emphasis toward functional prototypes instead of design documentation. Here’s what they say about it:

This “always one sprint from tape-out” mindset breaks through traditional boundaries by:

1. Encouraging continuous integration and testing, reducing the risk of late-stage issues
2. Promoting modular design approaches that allow for easier updates and modifications
3. Requiring improved collaboration between design, verification and manufacturing teams
4. Introducing a more continuous compliance process, replacing explicit time-consuming stage gates with ongoing conformity checks. This approach integrates compliance and regulatory considerations throughout the development cycle, rather than treating them as separate, discrete phases
5. Driving the adoption of advanced simulation and emulation tools for frequent “virtual tape-outs”

Full article here:

Highberg | Applying Agile and Lean practices to Semiconductor…Discover how Agile and Lean practices transform semiconductor development. Learn how iterative prototyping, cross-functional teams, and automation cut…highberg.com

Measurement / Metrics

A North Star Metric provides focus and direction to what good looks like. “Stories Completed” will be a pretty good starting point.

Stories Completed — North Star

At a high level, it frames the conversation between customers, the team, and management. Each story completed (if it was well-written) delivers a tangible value to a specific person. Measuring the number of stories complete gives the team a good way to summarize each sprint and follow up with detail on each story that will be valuable in touting progress.

It also creates incentives to reduce scope and make smaller stories — both of which are good if not taken to extremes. Delivering 10 small stories is better for an Agile mindset than 5 medium ones, even if the amount of theoretical value created is the same. This metric naturally incentivizes the team to create more smaller stories than fewer larger ones.

Paired with solid definitions of done for stories and a Quality Checklist for a sprint, this will be a solid top-level metric.

Sprint Quality Scorecard

The Sprint Quality Scorecard is the best top-level metric for process improvement — it encompasses your definition of success and provides a natural moment of reflection and alignment among the team.

Further enhancement — DORA Metrics

Many Agile teams use some version of DORA Metrics to bring measure a balance of throughput and stability: Deployment Frequency, Lead Time to Change, Change Failure Rate, Mean Time To Recovery. In a semiconductor process, these might look something like…

• Deployment frequency ≈ how often a design revision is integrated/tested (not taped out).
• Lead time ≈ time from design commit to verified block/system integration.
• Change failure rate ≈ proportion of revisions that fail regression/coverage goals.
• MTTR ≈ how quickly a broken build or test bench is fixed.

These can be incorporated into the Sprint Quality Checklist when needed — e.g. “Reviewed metrics and discussed highlights / lowlights.”

References

Leveraging Agile in Semiconductor Development

SemiconductorSemiconductor - Nov/Dec 2024magazine.semiconductordigest.com

• Key Highlights:
  • Automate Compliance Checks
  • Continuous Documentation
  • Shift-left testing for reliability

Highberg | Applying Agile and Lean practices to Semiconductor…Discover how Agile and Lean practices transform semiconductor development. Learn how iterative prototyping, cross-functional teams, and automation cut…highberg.com

1. Functional Prototypes Instead of Comprehensive Complete Designs
   1. ⇒ “Always one sprint away from tape-out” — North Star for end-of-sprint goal
2. Multi-specialization Teams over Mono-specialization Teams
3. Advancing Tools and Generators over Refining Instances
4. Responding to Change over Following a Plan

Roles and Responsibilities — Examples

Product Manager (PM)

• Translate customer and market needs — from OEMs, system integrators, and design partners — into clear, prioritized product objectives that align with the silicon and design roadmap.
• Balance technical feasibility with commercial urgency by sequencing work around learnings, prototypes, and validation milestones.
• Maintain a continuously groomed backlog that connects near-term experiments to long-term differentiation and tapeout timelines.
• Define success metrics tied to performance, yield, and customer adoption, and use them to guide trade-offs between speed and de-risking technical approaches.

Delivery Manager / Execution Lead 

Pulls on best practices from Scrum Mater and Technical Program Manager (TPM).

• Orchestrate bi-weekly sprints that integrate hardware design, verification, and firmware workstreams into a cohesive cadence of learning and delivery.
• Anticipate and remove blockers caused by cross-discipline dependencies (EDA tools, foundry schedules, IP integration) to keep progress flowing.
• Promote agile discipline adapted for high-variance engineering—short feedback loops, rapid experiment closure, and visible progress metrics.
• Foster a culture of accountability and continuous improvement across distributed teams, ensuring decisions stay data-driven even under uncertainty.