This book presents a radically different approach to managing the systems development process. Scrum implements an empirical approach based in process control theory. The empirical approach reintroduces flexibility, adaptability, and productivity into systems development. I say “reintroduces” because much of this has been lost of the last 20 years.
from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle (page 1!)
empirical (adjective)
Based on, concerned with, or verifiable by observation or experience rather than theory or pure logic e.g. “they provided considerable empirical evidence to support their argument”
from http://www.oxforddictionaries.com
Empirical process is fundamental to a Scrum and Agile approach, it is one of the hardest concepts to get across to people who are new to Agile.
Why is it so hard? Because empirical process is a lot of hard work, and not physical work. Empirical requires a lot of thinking, discussion, trial, and yes, unfortunately, error! When I work with a team – or with senior stakeholders who are sponsoring an Agile transformation, they tend to look to me and my Agile coaching colleagues to tell them exactly what they need to do to make sure that their project is a success. Very often I am asked, by management, and by members of the team “What’s the best practice? Or what is the Company way of doing this? Can you point us to some documentation (or a ‘toolkit’) that tells us exactly what we need to do?”
And I always feel slightly bad, and somehow deficient when I say – “no.” There isn’t a book that tells you exactly how to do it. There certainly isn’t a document that tells you what the way to do it that is specific to this company is. But the good news is that there is a framework that can, over time give you answers to these questions for this particular project.
Scrum is explicitly not a methodology, it is a framework, an iterative framework. And the entire purpose of that framework is to discover through actual experience – empirically – what the methodology should be for each individual project.
Why do we have to do this? Because so many things can be different on different projects. I’ll list just a few here.
1) Access to the business/client
In some organisations a member of the client organisation will sit with the team and access to Subject Matter Experts - “SME’s” who can answer detailed questions on how the application should work and how the work is currently done is easy to come by. On other projects, the product owner is only available for crucial Scrum meetings and access to subject matter experts is the limiting factor on the speed of development.
2) Demand
When is the software needed? Is there a deadline? Does the organisation that you’re writing this software have a “quiet period” and a “crazy period” during the year, maybe even during the month? Does the software need to be released yearly, monthly, weekly or daily?
3) Capability of the team
Does the team have the right technical abilities to deliver the solution. Do they need outside help? Does learning the right technical skills have to be explicitly part of the work of the project?
4) Distribution of the team
Can the team all sit together? Or are they on several sites (or as with one project I worked on, working from home in cities across Europe).
5) The nature of the technical solution
Is this a “greenfield” solution or is it an update to an existing system, or is it a set of modifications to a third party application.
6) The nature of the data
With some datasets, a small sub-sample is never going to be anything like the “real thing”.
7) The security and sensitivity of the solution
How do you release the software? And to which environment? What kind of testing is going to go on after its released?
When you’ve understood these features of your project – and probably a dozen more that might only be important to your particular project, and also understood how these features need to change your project approach, you will have yourself an empirical process.