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
Best Scrum Software Every Project Needs
A powerful scrum software that supports scrum project management. It features scrum tools like user story map, product backlog management, sprint backlog management, task management, daily scrum meeting, sprint planning tool, sprint review tool, sprint retrospective tool, burndown, impediment, stakeholder and team management.
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 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.
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.
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.
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:
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
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.
Turn every software project into a successful one.