Agile — Iterative Development Principles

Agile is a mindset and set of principles for software (and increasingly hardware) development, defined in the 2001 Agile Manifesto. It values individuals over processes, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

One-page infographic

Visual summary of Agile — Iterative Development Principles · Free PDF

Download PDF

Why companies use it

·Responds effectively to changing requirements, which is inevitable in complex product development
·Reduces the risk of building the wrong product by delivering value in small, verifiable increments
·Improves team engagement by giving engineers ownership over how work is executed
·Faster time-to-market compared to traditional waterfall approaches for uncertain, complex work

What hiring managers look for

·Agile is the default operating model at the majority of technology companies — it is a baseline expectation
·Candidates who can articulate the why behind agile principles (not just the ceremonies) show genuine understanding
·Understanding which agile framework to use (Scrum, Kanban, SAFe) in a given context shows judgment
·Engineers who thrive in agile environments are self-directed, collaborative, and comfortable with change — these traits are what hiring managers are screening for

Typical interview questions

What are the four values of the Agile Manifesto?

What is the difference between agile and waterfall development? When would you prefer each?

How do you handle a situation in an agile team where the requirements change fundamentally after two sprints of work?

What does "working software" mean as a primary measure of progress in agile?

Have you worked in an agile environment that was not working well? What was wrong and what would you have changed?

Common mistakes

·Confusing agile with "no planning" — agile still requires planning, it just happens continuously and at shorter horizons
·Implementing agile ceremonies without the underlying culture — daily standups and retrospectives are meaningless without trust and psychological safety
·Using agile for work that is actually repeatable and well-understood — a production process does not benefit from sprints
·Treating the Agile Manifesto as a prescriptive process rather than a set of values that inform judgment
·Measuring team velocity as a performance metric and using it for cross-team comparison

Real engineering example

A systems engineering team developing control software for a lithography tool adopted agile after a 2-year waterfall project delivered a system that no longer matched the evolved machine specification. By switching to 3-week sprints with a fixed demo to hardware and software stakeholders, they identified specification mismatches within weeks rather than months, avoiding the 8-month integration crisis of the previous programme.

Topics covered

agileAgile Manifestoiterativesoftware developmentsprintwaterfall

Related interview guides

Software Engineer →Embedded Software Engineer →Firmware Engineer →Project Leader High Tech →Technical Product Manager →Systems Engineer →