What is Scrum Process Change and what impact does it have on Agile Projects? Scrum has a clearly defined Process Framework, which makes its adoption simple and straightforward. As with all Processes, to Manage them effectively, there should be a Process Owner. The Process Owner understands the Processes well. Their Role is to ensure everybody adheres to the Processes and that they are followed. From this perspective, it is clear that the Scrum Master Functions as the Process Owner. The only difference in Scrum is that if Changes to the Process are Required, the Team must agree Democratically that this is desirable. The Scrum Master cannot impose Changes without the Team’s approval and Consent.

The question arises why, if all the Processes are described, why would they Require Change. To answer this, consider the “Estimate User Stories” Process. This is Conducted throughout the Sprint Planning Meeting. There are several Techniques that can be utilised to do this. If a particular Method, like “Planning Poker” was used, and the Estimations were incorrect, this could have an effect Downstream.

First of all this would affect the Committing of User Stories to the Sprint Backlog. It will then have further impact when performing the Work. If the Estimation was 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 completed prior to the Sprint End-Date (which is Time-Boxed). This is most likely to occur during the first Sprint. At this stage the estimation is likely to be at its most uncertain. The Process can then be improved in future planning meetings to avoid it recurring in the next Sprints.

Scrum Process Change: Processes that are Most Likely to Change.

Scrum is Iterative, but not all the Processes are Iterative. Where this is the case there is no Opportunity to Change the processes within a Project. The Learnings from the Project can 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” (where there is only a single product release) are not Iterative as they precede and follow the Sprints. “Plan and Estimate”, “Implement” and “Review and Retrospect” are Iterative. It is possible to Improve these Processes as the Project Progresses.

Scrum Process Change: 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. However, changes will only be considered at the end of a Sprint. A comparable approach needs to be taken with Process Change. Process Change must only be used prior to the start of the next Sprint. The exception here might be if there is a Roadblock that is interrupting the Process. This is something the Scrum Master Mitigates immediately, so that the Process Flow can resume.

The need to tweak a Process can be raised at any time. For instance during the Daily Stand-up Meeting, this is the ideal forum for discussing and ratifying the Change. Another opportunity is during the Sprint Retrospective. This is where all the activities that took place during the Sprint are Reviewed. They are reviewed to determine whether they went well or could be improved. Where an improvement is required, this is the Meeting where the Process Change can be discussed and agreed.

As mentioned previously, the Agile Scrum Master is the Process Owner. They must not enforce a Change. They can only recommend the Change on the basis of their Scrum Knowledge. This is when they will need to be diplomatic and win over the Team. They will need a reasoned explanation as to why the Change would be Beneficial. Once a consensus is reached on a Process Change, this is Documented in preparation for the next Sprint.

Retrospective Meeting and Process Change

There is another Retrospective Meeting held at the end of the Project, where Process Changes can also be recommended. These Changes need to be kept in mind for Application to the next Project.

When it comes to large Projects, there can be more than one Sprint Team. It is a good Practice to share all the Process Improvements that each Team applied. There is no formal Meeting in the Scrum Guide for doing this. A consolidated Retrospective where all Teams are involved could be used for this at the end of each Sprint and after the individual Sprint Retrospectives.

Determining the Improvement

If a Process is optimised, there needs to be a check and balance that the Change was an Improvement. This is why it is a good idea only to use Process Changes at the start of the next Sprint. If Changes are applied midway throughout a Sprint it is difficult to get a precise 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 could be Charted and put on the Project Wall. The metrics might likewise be Demonstrated in the Sprint Review, for the Benefit of Stakeholders who are attending.

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

An Additional Benefit of utilizing Scrum.

Not only does Scrum Produce a Quality Product in the quickest possible time, it teaches the Scrum Team (Agile Scrum Master, Scrum Product Owner and Scrum Development Team) members about Process Optimization and how to apply Continuous Improvement. This is the Highest Level of Process Maturity; the Entire Team has been exposed to how it Works and how to acknowledge where Change is Required. Improving the Process also teaches each Team member more about Scrum as a Framework.