An independent study reference written by Dr Phuc V. Nguyen. It is not official subject material — for assessment requirements always follow your subject outline and vUWS.
Agile ways of working in analytics
The Agile Manifesto states four preferences: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. It says software because software practitioners wrote it. This atlas reads that item as usable analytical output. The right-hand items still have value, the sentence most often dropped. Scrum turns those preferences into a structure with three accountabilities, three artefacts and a fixed-length sprint containing planning, a daily re-plan, a review and a retrospective. Analytics needs one honest adjustment, because whether a useful result exists is often not knowable in advance.
Why it matters
Agile is mostly about how often you show your work to the person who asked for it. A long plan hides being wrong for months. A short cycle exposes it in a fortnight, when correcting course is still cheap. Everything else, the ceremonies, the boards, the vocabulary, exists to make that short cycle happen on purpose rather than by luck.
A stakeholder asks a team to commit at sprint start to a model that improves forecast accuracy by five per cent. What is the honest agile response?
Worked examples
A stakeholder asks a team to commit at the start of a sprint to delivering a forecasting model that improves accuracy by five per cent.
That commitment cannot be made honestly, because nobody knows yet whether a five per cent improvement exists in the data. The agile-compatible answer is a timeboxed investigation with a decision at the end. The team commits to spending a fixed period establishing whether the improvement is achievable and to reporting a clear recommendation, which is a deliverable it fully controls. Where analytics does commit to outcomes, they should be decision-usable ones, for instance that the depot manager can see yesterday's late deliveries by depot each morning, rather than a target movement in a metric.
An analytics team runs fortnightly sprints but takes most of its work as unplanned requests from three business units. Sprints are constantly interrupted and rarely finish as planned.
The cadence does not match the demand. Fixed sprints suit work that can be chosen in advance, while demand-driven request queues suit a pull system with an explicit limit on work in progress, which is the Kanban approach. Making the queue and its limit visible turns the real problem, which is that three units are issuing more requests than the team can absorb, into a conversation about priority instead of a series of missed sprints. The methodology did not fail, it was applied to the wrong demand pattern.
Common mistakes
- ✗Agile means no plan and no documentation. The manifesto expresses a preference between two things it values, and it says so explicitly. Plans and documents still exist, they are simply not what progress is measured by.
- ✗A sprint is a deadline designed to make people work faster. A sprint is a fixed inspection interval. Its purpose is frequent feedback on real output, not compressed effort, and shortening it does not increase capacity. What the developers commit to is the sprint goal. The sprint backlog beneath it is a forecast of the work, not a promise about it.
- ✗Agile is incompatible with a methodology such as CRISP-DM. They answer different questions. CRISP-DM says which steps an analytics problem requires, agile says how often you show work and re-plan. Teams commonly run CRISP-DM phases inside sprints without conflict.
- ✗The daily stand-up is a status report to a manager. The event exists so the team can re-plan its own next day. Once someone external is receiving updates and assigning work, it has become a status meeting under a different name and the re-planning it was meant to produce has stopped.
Revision bullets
- •Four manifesto preferences, with the right-hand items still valued; "working software" reads as usable analytical output here
- •Scrum: product owner, scrum master, developers; product backlog, sprint backlog, increment
- •Sprint contains planning, daily re-plan, review with stakeholders, retrospective on the process
- •Analytics uncertainty is handled by timeboxed investigation with a decision, not an outcome commitment
- •Commit to a sprint goal and a decision-usable increment, not to a metric movement
- •Unplanned demand suits a pull system with a work-in-progress limit rather than fixed sprints
Quick check
A stakeholder asks a team to commit at sprint start to a model that improves forecast accuracy by five per cent. What is the honest agile response?
A daily stand-up has become a round of updates directed at a manager, who then allocates the day's tasks. What has gone wrong?
Connected topics
More in How Analytics Gets Built
Sources
- Beck, K., et al. "Manifesto for Agile Software Development." 2001.The four value statements and the twelve supporting principles, including the clause that the right-hand items still have value.
- Schwaber, K., & Sutherland, J. The Scrum Guide: The Definitive Guide to Scrum. 2020.Defines the accountabilities, artefacts and events referred to here, including the sprint as a fixed-length container.
- Anderson (2010)Anderson, D. J. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.The pull-based alternative with explicit work-in-progress limits, better suited to demand-driven request queues.