Empirical Process Control vs Defined Process Control

Empirical process control expects the unexpected, while defined process control expect every piece of work to be completely understood in upfront.

What is Defined Process Control?

Defined process control is a process with a well-defined set of steps. When we are in an environment with relatively low volatility that can be easily predicted; given the same inputs, a defined process should produce the same output every time based on its repeatability and predictability nature. The defined process has the following characteristics:

• Common and Control
• Plan what you expect to happen
• Enforce the plan, sometimes regardless of change condition
• Use change control because change is expensive

What is Empirical Process Control?

In empirical process control, you expect the unexpected. With defined process control, every piece of work is understood. In Scrum, an empirical process is implemented where progress is based on observation and experimentation instead of detailed, upfront planning and defined processes. Using empirical process control is working in a fact-based, experience-based, and evidence-based manner that control is exercised through inspection, adaptation.  The Empirical Process Control has the following characteristics:

• Learn as we progress
• Expect and embrace change
• Inspect and adapt using short development cycles
• Estimates are indicative only and may not be accurate

Empirical Process Control in Scrum

In Scrum, the realization of empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Transparency

Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes. Not only must these aspects be transparent, but also what is being seen must be known. That is, when someone inspecting a process believes that something is done; it must be equivalent to their definition of done.

Inspection

The various aspects of the process must be inspected frequently enough so that unacceptable variances in the process can be detected. The frequency of inspection has to take into consideration that all processes are changed by the act of inspection. A conundrum occurs when the required frequency of inspection exceeds the tolerance to inspection of the process. Fortunately, this doesn’t seem to be true of software development. The other factor is the skill and diligence of the people inspecting the work results.

Adaptation

If the inspector determines from the inspection that one or more aspects of the process are outside acceptable limits, and that the resulting product will be unacceptable, the inspector must adjust the process or the material being processed. The adjustment must be made as quickly as possible to minimize further deviation.

The Three Pillars in Scrum Events

Now let us investigate how does Scrum embedded the 3 pillars as the best practices into the framework through various events and activities.

For example:

• The Daily Scrum meeting is used to inspect progress toward the Sprint goal, and to make adaptations that optimize the value of the next work day.
• In addition, the Sprint Review and Planning meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint.
• Finally, the Sprint Retrospective is used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling, and enjoyable.

The list summarizes the relationships between the Scrum events and 3 pillars as shown in the following:

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture. In Scrum, transparency is depicted through:

• Artifacts
  • Project Vision Statement
  • Prioritized Product Backlog
  • Release Planning Schedule
• Meetings
  • Sprint Review Meetings
  • Daily Standup Meetings
• Information Radiators
  • Burndown Chart
  • Scrum Task board

Inspection in Scrum is depicted through:

• Use of a common Scrum Task board and other information radiators
• Collection of feedback from the customer and other stakeholders during the Develop Epic(s), Create Prioritized Product Backlog, and Conduct Release Planning processes.
• Inspection and approval of the Deliverables by the Product Owner and the customer in the Demonstrate and Validate Sprint process.

Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. Adaptation in Scrum is depicted through:

• Daily Standup Meetings
• Constant Risk Identification
• Change Requests
• Scrum Guidance Body
• Retrospect Sprint Meeting

About Visual Paradigm

Visual Paradigm help organizations stay competitive and responsive to change faster and better in today’s fast changing environment. Our award-winning products are trusted by over 320,000 users in companies ranging from small business, consultants, to blue chip organizations, universities and government units across the globe. It enables organizations to improve business and IT agility and foster innovation through popular open standards and process frameworks.Visual Paradigm, a killer Agile feature in 2018, introduced Scrum Process Canvas for automating the way a Scrum team to create, manage and deploy software application that empowers the team to continuously improve their performance at unprecedented speed and scale. Manage the Entire Scrum Process in One Page Automate the Scrum Framework in a fun and enjoyable dashboard with eye-catching updated status. Manage Backlog, Multiple Sprints of different Scrum Roles with a single-page visually executable canvas Allow instantly access, review and generate scrum artifacts and related documents to be archived in the Shared Cabinet Automate the Scrum events and related activities with self-explanatory instructions, samples and required document templates.