The Empirical Nature of Scrum
Does this sound familiar?
I 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 what was learned as an input for the improvement for 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.
More about Scrum
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.
Transparency
Significant aspects of the process must be visible to those responsible for the outcome.
Inspection
Scrum users must frequently inspect Scrum artifacts and progress toward a goal to detect undesirable variances.
Adaptation
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
Writing tests:
- 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.
Oh…and by the way. I found that the lean startup model fits right in with our approach: https://www.youtube.com/watch?v=fEvKo90qBns
Some other Empirical outcomes
Organisational:
- Move towards agile focussed governance processes increasing overall organisational efficiency
- Cross organisation synchronisation (education on organisational as well as technical levels)
- Step-by-step movement toward cultural change enforced by Agile practices
- Greater team collaboration, where the business and development team owns the outcome
- Greater team satisfaction scores
- Improved staff retention
Operational:
- Deliverable increment every sprint cycle
- Clear transparency into team impediments
- Clear metrics for productivity evaluation
- Short turn-around times on product changes and improvements
- Clearly defined steps for process improvement
- Well structured process limiting need for meetings
- Team capability transparency and development roadmaps
