As with all Processes and Process Changes, to Manage them effectively, there needs to be a Process Owner. The Process Owner understands the Processes. Their Role is to ensure everyone adheres to the Processes and the processes are followed.

The question emerges why, if all the Processes are described, why would the Require Change? To answer this, think about the “Estimate User Stories” Process. This process is Conducted during the Sprint Planning Meeting. There are several Techniques that can be used to do this. If a particular Method, like “Planning Poker” was utilized, but the Estimations were incorrect, this would have an impact Downstream. First of all the impact would be observed when Committing User Stories to the Sprint Backlog. It will again impact the team when they begin executing the Work.

Process Change Example

Where Estimation is too low, the Sprint will run out of time prior to the Sprint Backlog being completed. If there was an Overestimation, the Work will be finished before the Sprint End-Date (which is Time-Boxed). This is more than likely to happen throughout the first Sprint. The Process is then enhanced to prevent it recurring in the next Sprints.

Processes that are Most Likely to Change.

Although Scrum is Iterative, not all the Processes are Iterative. Not all processes have the Opportunity to Change within the Agile Project. Learnings from the Project may only be taken and used in any subsequent Projects. The Iterative Processes can be subject to Change and Improvement as the Project Progresses. Let’s take a look at the High Level Process/Value Chain.

” Initiate” and “Release” are not Iterative as they precede and follow the Sprints. “Plan and Estimate”, “Implement” and “Review and Retrospect” are Iterative. It is therefore possible to Improve these Processes as the Agile Project Progresses.

When Can a Process Change be Identified?

In an Agile Project, and Scrum as an Agile Framework, Change is welcomed, but at the right time. Changes to a Product can be Requested at any Time by a Stakeholder. But will only be considered at the end of a Sprint. A similar approach should be taken with Process Change. It should only be used prior to beginning the next Sprint. The exception here might be if there is a Roadblock of some event that is disrupting the Process. This might not always be a Process Change, but it could be.

The need to tweak a Process can be raised at any time. For instance throughout the Daily Standup Meeting. There is an ideal forum for discussing and ratifying the Change, and that is the Sprint Retrospective. This is where all the activities that occurred during the Sprint are Reviewed. The Scrum Team discuss whether the processes worked out or could be enhanced. Where an improvement is needed, this is the Meeting where the Process Change can be talked about and agreed.

Process Owner

The Scrum Master is the Process Owner (not the Product Owner). The Scrum Master must not impose a Change. They may only promote a Change on the basis of their Scrum Knowledge. This is when they will be require to be diplomatic. The Scrum Master must win over the Development Team with a reasoned description regarding why the Change would be Beneficial. Once a consensus is reached that a Change to the Process should be used, this is Documented in preparation for the next Sprint.

There is another Retrospective Meeting held at the end of the Project and product release. These meetings can also be used to advise on Process Changes. These Changes ought to be kept in mind for Application to the next Agile Project.

It is an good Practice to share all the Process Improvements that each Team used. There is no official Meeting in the Scrum Guide for doing this, but a consolidated Retrospective where all Teams are involved might be utilized for this. This would occur at the end of each Sprint and after the specific Sprint Retrospectives.

We found these books great for finding out more information on Agile Scrum:

Process Change – Measuring the Improvement

If a Process is optimised, there needs to be a check to ensure that the Change was an Improvement. This is why it is recommended only to use Process Changes at the start of the next Sprint; if Changes are applied midway through a Sprint it is hard to get an accurate Assessment of the Improvement. Some possible Measures are:-.

-‘ Improvement in Quality’ – Percentage of Work Completed During a Sprint.
-‘ Improvement in Throughput’ – Did the Sprint Velocity Improve?

These Metrics might be Charted and placed on the Project Wall. The metrics can also be Demonstrated during each Sprint Review, for the Benefit of the Stakeholders.

An Additional Benefit of using Scrum.

Scrum does not only Produce a Quality Product in the shortest possible time, it teaches Team members about Process Optimization and how to use Continuous Improvement. This is the Highest Level of Process Maturity; the Entire Team has actually been exposed to how it Works and how to recognise where Change is Required. Improving the Process likewise teaches each Team member more about Scrum as a Framework.