Does this sound familiar?
We think that the best approach a team can take is to use empirical feedback to learn about the system and its use, and then apply that learning back to the system. A team needs repeated cycles of activity. In each cycle it adds new features and gets feedback about the quantity and quality of the work already done. The team members split the work into time boxes, within which they analyse, design, implement, and deploy as many features as they can.
Deploying completed work to some kind of environment at each cycle is critical. Every time a team deploys, its members have an opportunity to check their assumptions against reality. They can measure how much progress they’re really making, detect and correct any errors, and adapt the current plan in response to what they’ve learned. Without deployment, the feedback is not complete.
Sounds like scrum to me.
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimise predictability and control risk.
Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
Significant aspects of the process must be visible to those responsible for the outcome.
Scrum users must frequently inspect Scrum artifacts and progress toward a goal to detect undesirable variances.
If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted.
Some interesting observations
- makes us clarify the acceptance criteria for the next piece of work—we have to ask ourselves how we can tell when we’re done (design);
- encourages us to write loosely coupled components, so they can easily be tested in isolation and, at higher levels, combined together (design);
- adds an executable description of what the code does (design); and,
- adds to a complete regression suite (implementation);
Acceptance criteria is a crucial part of every story. In TDD we use the test writing process as an input for clarifying the acceptance criteria. Scrum can benefit from this.
So the inner loop of the TDD process can deal directly with the input towards daily planning meetings in scrum. The developer team can review tests, determine the acceptance criteria and renegotiate based on the design accompanied with the discovery of the implication of the story.
TDD states the following. External quality is how well the system meets the needs of its customers and users (is it functional, reliable, available, responsive, etc.), and internal quality is how well it meets the needs of its developers and administrators (is it easy to understand, easy to change, etc.). Everyone can understand the point of external quality; it’s usually part of the contract to build. The case for internal quality is equally important but is often harder to make. Internal quality is what lets us cope with continual and unanticipated change.
In scrum the focus, again, aligns beautifully. We don’t only want to make sure that the Product Owner is happy, the dev team needs to feel in control. The scrum master needs to enable the dev team to reach their goals of internal quality. Scrum ensures that there is a healthy balance between external and internal quality. TDD thus do not only provide a benefit to the organisation by ensuring high quality, well thought out and designed software, it has the intrinsic value of creating an environment where internal quality is assured. A win, win I would say.
Best practise would be to setup a walking skeleton in iteration zero. Iteration Zero: In most Agile projects, there’s a first stage where the team is doing initial analysis, setting up its physical and technical environments, and otherwise getting started. The team isn’t adding much visible functionality since almost all the work is infra- structure, so it might not make sense to count this as a conventional iteration for scheduling purposes. A common practice is to call this step iteration zero: “iteration” because the team still needs to time-box its activities and “zero” because it’s before functional development starts in iteration one. One important task for iteration zero is to use the walking skeleton to test-drive the initial architecture.
Oh…and by the way. We found that the lean startup model fit right in with our approach: https://www.youtube.com/watch?