GK One-Line Question & Answer

Technical feasibility assesses whether proposed technical approaches can achieve required functionality within constraints (performance, cost, platform) — it should occur early (before significant design investment) and specifically target the highest-uncertainty aspects through prototypes or proof of concepts

MVP (Ries) is the version of a new product that allows maximum learning with minimum effort — its purpose is to test a specific business hypothesis; the most common misapplication is treating MVP as 'minimum features for launch' rather than as a learning instrument

Project management delivers a specific temporary endeavour (one system, one timeframe); program management coordinates multiple related projects to achieve strategic outcomes beyond what any individual project delivers — managing interdependencies, shared resources, and combined benefits realisation

Kano model (Noriaki Kano) categorises features as: Basic needs (absent = dissatisfied, present = neutral — hygiene factors), Performance needs (more = more satisfied, less = less satisfied — stated requirements), and Excitement needs (absent = neutral, present = delighted — unexpected differentiators)

DoR specifies criteria a backlog item must meet before entering a sprint (clear acceptance criteria, estimated, dependencies resolved, design mockups attached) — protecting the sprint planning investment by ensuring stories are sprint-ready, preventing half-understood stories from consuming sprint planning time

MMF is the smallest feature increment that delivers genuine market value and can be independently released to customers; MVP tests a hypothesis about whether to build; MMF is the smallest unit of buildable value assuming the decision to build has already been made and validated

A PoC is a small-scale technical investigation proving the feasibility of a critical architecture or algorithm before committing to full design — specifically mitigating the risk of discovering architectural infeasibility after expensive design work is completed

Low volatility projects (replacing a known system, implementing a known algorithm) allow complete upfront specification — Waterfall's assumption holds; innovative products require user feedback to shape requirements, which Waterfall's sequential phases prevent until it's too late to change

Phase gate reviews can produce: approve (proceed to next phase), conditional approval (proceed after addressing specific findings), return (redo current phase with corrections), hold (pause pending external information), or cancel (terminate the project) — multiple outcomes reflect varying risk levels

IV&V uses an independent third party to verify (checking the product meets specifications) and validate (checking the product meets user needs) — independence eliminates the conflict of interest where developers are reluctant to report problems in their own work

A software baseline is a formally reviewed and approved configuration item serving as a reference for future development — the three standard baselines: Functional Baseline (approved system requirements), Allocated Baseline (approved design specifications), Product Baseline (approved product at delivery)

SRR is a formal review assessing whether system requirements are complete, consistent, and testable — exit criteria: all requirements have unique IDs, are individually testable, no internal contradictions exist, regulatory requirements are traceable, and customer has formally accepted the SRS

RTM maintenance tracks which requirements are implemented by which code modules and tested by which test cases throughout implementation — it degrades when: code changes are not reflected in RTM updates, scope changes occur without updating traces, and maintenance is deprioritised under schedule pressure

Build and fix skips planning and specification — developers code until something works, then fix problems as they appear; it's a degenerate Waterfall because it omits the analysis and design phases that give Waterfall its structure, producing the ad-hoc development the software crisis highlighted

EVM integrates scope, schedule, and cost — key metrics: Planned Value (budgeted work), Earned Value (value of work completed), Actual Cost (money spent); Schedule Variance = EV-PV; Cost Variance = EV-AC — enabling objective project health assessment rather than subjective 'percent complete' estimates

CMP describes how configuration management will be practised: Configuration identification (what items are under CM), Configuration control (how changes are proposed, evaluated, approved), Status accounting (recording and reporting of CM information), and Configuration audits (verifying CM records match actual items)

Waterfall's most significant schedule risk is 'the first 90% takes 90% of the time; the last 10% takes the other 90%' — monitored by tracking planned vs actual milestone completion, design review findings (unresolved issues), and dependency completion status rather than subjective percent-complete estimates

Waterfall's upfront specification of complete requirements enables precise cost and schedule estimation before contract award — the contractual obligation (deliver X by date Y for $Z) maps directly to Waterfall's sequential phases with measurable phase-exit deliverables that can be contractually defined

Technical reviews come in three types: Management review (project status, resource allocation), Technical review (evaluating technical implementation against specifications), and Audit (verifying process compliance, configuration records) — each serves a different quality assurance function

Cycle objectives define what the current cycle aims to accomplish (e.g., 'prove the real-time processing algorithm meets latency requirements'); milestone objectives define the strategic gates for the overall project (LCO, LCA, IOC) that multiple cycles collectively work toward

Technical risk management plan documents: identified technical risks with probability and impact, risk reduction actions and prototypes planned, risk thresholds (when risk becomes unacceptable), monitoring indicators, and contingency plans — updated at the start of each Spiral cycle

As successive cycles resolve risks, remaining work becomes more certain and manageable — early cycles are exploratory and slow (high uncertainty); later cycles become more efficient as the architecture stabilises, requirements are validated, and teams can focus on productive construction without risk interruptions

Risk-driven testing allocates testing effort proportional to the probability and impact of failure in each area — high-risk components (safety-critical, performance-critical, complex algorithms) receive disproportionately more testing than low-risk CRUD operations; requirements-driven testing covers all requirements equally regardless of risk

Scrumfall describes organisations using Scrum terminology (sprints, standups) while retaining Waterfall's underlying structure (big upfront design, phase gates, no real iteration) — typically caused by organisational resistance to genuine agile transformation, where teams adopt ceremonies without changing fundamental practices

When management sets velocity targets ('the team must achieve 50 points per sprint'), teams respond by inflating story point estimates rather than delivering more actual value — converting a useful forecasting metric into a gamed number that loses its predictive value (Goodhart's Law in action)

'Money for Nothing, Change for Free' (Jeff Sutherland) contracts allow the customer to terminate early (paying only for completed work plus a fee, since remaining low-priority backlog has less value) or substitute new requirements for unbuilt ones of equal estimated size at no extra cost — aligning contract terms with agile's iterative value delivery

The Agile Fluency Model (Shore, Larsen) describes four zones: Focusing (team works as a unit on business priorities, visible progress), Delivering (team produces low-defect releasable software on demand), Optimising (team optimises for business value and market response), Strengthening (organisation-wide agile capability) — each zone requires different investment and provides different benefits

Dark scrum occurs when Scrum ceremonies become tools for surveillance and control rather than collaboration — symptoms include: daily standups becoming status reports to managers (not peer coordination), retrospectives where no real issues are raised for fear of repercussions, and velocity used to compare/punish individuals

Feature toggles wrap new code behind a runtime switch, allowing code to be merged and deployed to production while remaining invisible/inactive to users — mitigating the risk of long-lived feature branches (merge conflicts, integration hell) while still enabling controlled, gradual feature rollout

Q1 (technology-facing, supports team — unit/component tests automating internal quality) is the opposite corner from Q4 (business-facing, critiques product — exploratory testing, usability testing, UAT evaluating whether the right product was built) — together the four quadrants ensure both internal quality and external value are tested

A self-organising team determines how to accomplish its work without being directed by management on the specifics of task assignment — research (Hackman's team effectiveness model) shows this requires management to provide clear direction (what/why), adequate resources, and explicit boundaries while deliberately not controlling the how — a balance many managers find difficult

In R&D projects, early Spiral cycles focus on feasibility research (evaluating alternative approaches, building proof-of-concepts) with small teams and low investment; as risks resolve and feasibility is proven, later cycles scale up the team and investment for full development

The architecture baseline (corresponding to LCA milestone) is the point where architecture is stable and validated — it enables reliable cost/schedule estimation for remaining construction, concurrent development by multiple teams, and confident contractual commitments about deliverables

Spiral prototypes specifically resolve identified risk items (technical feasibility, performance, integration complexity) — the prototype's purpose is determined by the risk it must resolve; RAD prototypes are UI/workflow demonstrations built to elicit and validate user requirements

Risk-adjusted return accounts for the probability of project success: if a project has $10M expected value but 30% probability of technical failure, the risk-adjusted return is $7M — this guides Spiral decisions by making low-probability-of-success projects less attractive even if their upside is large

Spiral explicitly addresses: business viability risks (is the product worth building?), requirement volatility risks (will requirements change?), and technology feasibility risks (can we build it?) — V-model assumes these are resolved upfront and only addresses product verification/validation risks

New requirements discovered during implementation are recorded as potential scope for future cycles rather than disrupting the current cycle — the cycle's objective is maintained; new requirements go through risk analysis in the next cycle to determine priority and feasibility

Concurrent engineering overlaps development phases (design and implementation proceed simultaneously across subsystems) to reduce total calendar time — it relates to Spiral by requiring resolved architecture risks first (LCA milestone), after which concurrent construction of validated subsystems is safe

Spiral estimates costs cycle by cycle with increasing accuracy as risks resolve — early cycles have wide estimate ranges (4x uncertainty); by LCA the range narrows to 1.25x; total project cost emerges as a cumulative sum, unlike Waterfall's single upfront estimate that assumes requirements are complete and stable

Prototype fidelity is determined by the minimum fidelity needed to answer the specific risk question — a paper prototype answers 'do users understand this workflow?'; a performance benchmark answers 'can this algorithm meet latency requirements?'; high fidelity is only used when lower fidelity cannot resolve the uncertainty