Practice, principles, and process adaptation

The four moves under every process

Underneath every process model is the same problem-solving skeleton, set out by Polya for mathematics long before software existed: understand the problem, plan a solution, carry out the plan, examine the result. Mapped onto software engineering, those become communication and analysis, modelling and design, code generation, and testing with quality assurance. The value of the mapping is not the four words — it is that each one implies questions you can actually ask on a Monday morning.

Understand the problem: who has a stake in the solution, what are the unknowns, can the problem be partitioned into smaller ones, can it be represented in a way that makes it clearer? Plan a solution: have I seen this problem before, is there a similar problem with a known solution, can a subproblem be solved first? Carry out the plan: does the implementation conform to the design, and can each component be shown to be correct? Examine the result: can each part be tested, and do the results conform to the requirements? A candidate who can produce three of those questions under exam conditions has a way of filling a page when memory fails.

Principles: how to turn an assertion into an argument

The principle lists are easy to dismiss and easy to convert into marks. At the process level there are eight: be agile; focus on quality at every step; be ready to adapt; build an effective team; establish mechanisms for communication and coordination; manage change; assess risk; and create work products that provide value for others. At the practice level: divide and conquer, which is separation of concerns; understand the use of abstraction; strive for consistency; focus on the transfer of information; build software that exhibits effective modularity; look for patterns; and, where possible, represent the problem and its solution from several different perspectives.

Use them the way a strong answer uses them — never as a recited list, always as the justification for a decision you have already described. "We reviewed the design before baselining it" is an assertion. "We reviewed the design before baselining it, because the exit condition for every activity should be the quality of the work product it produced" is an argument, and arguments are what the thinking problem pays for.

Process adaptation — what varies, and what never does

The most commonly missed idea in this part of the course is that a process is not a rigid prescription to be followed dogmatically. Process adaptation is the deliberate choice — made for a particular problem, project, team and organisational culture — of how the framework will actually be executed. Two projects in the same company can adopt significantly different processes and both be right.

What does not vary is the skeleton: the five framework activities and the umbrella activities are still there in both. What varies is how they are carried out, and it is worth being able to name the dimensions: the overall flow of activities, actions and tasks and the interdependencies among them; the degree to which actions and tasks are defined within each framework activity; the degree to which work products are identified and required; the manner in which quality assurance activities are applied; the manner in which project tracking and control are applied; the overall detail and rigour with which the process itself is described; the degree to which customers and other stakeholders are involved; the level of autonomy given to the team; and the degree to which team organisation and roles are prescribed.

Here is the exam move that separates a 5 from a 9: never write "we would tailor the process to the project". Name a dimension, name the setting you chose, and name the project attribute that forced it. Three of those in a row beats a page of adjectives, because each one is a decision traceable to something real.

Worked example — BorrowBox two ways

BorrowBox as it actually is: three engineers in one room; one customer, the library coordinator, available daily; no regulator; one hard external dependency on a locker hardware vendor; and requirements everyone expects to move once members start using it.

The adapted process. Flow is iterative in two-week increments, because requirement volatility is the dominant attribute and a single pass would deliver the wrong system accurately. Definition of actions and tasks is deliberately light — the team agrees an action ("model the reservation flow") and lets members choose their own tasks, because three people in one room coordinate by talking rather than by documents. Required work products are four and only four: usage scenarios, one class-and-state model, the test specification, and a decision log. Quality assurance is a single sixty-minute walkthrough per increment with a recorder; a formal inspection with prepared reviewers would consume a fifth of the team's capacity for a defect yield this codebase does not justify. Stakeholder involvement is continuous rather than scheduled. But risk management is deliberately heavier than the project's size suggests, because the vendor dependency can stop the project dead and no amount of local agility repairs that.

Now change one attribute. The council procures BorrowBox under a contract carrying a public accessibility obligation. Requirements must now be traceable and signed, so specification and validation become required work products with sign-offs. The walkthrough becomes an inspection with an issues list that must be closed before a baseline. Stakeholder involvement becomes scheduled review meetings with named attendees rather than a coordinator who wanders in. Team autonomy drops, because the contract prescribes roles. The product is the same and the five activities are the same; the process is genuinely different, and every difference traces to one changed attribute. That traceability is the whole skill.