To get work done with Scrum, there needs to be a balance between flexibility and stability in the Scrum change practice. While the Scrum framework is extremely flexible, change in Scrum projects must remain stable. When flexibility is too severe, processes can become blocked and ineffective. Scrum uses several concepts to ensure that the balance between stability and flexibility is never too rigid, never too flexible, but somewhere right in the middle. The Scrum Framework enables flexibility through transparency, inspection and adaptation.

Scrum Change: Iterative Development

Scrum supports both an iterative and incremental development process. Changes can be incorporated at any time in the process, however stability is maintained by not permitting any changes to the Sprint backlog once an iteration begins. The Scrum Master ensures that the Scrum Team (Scrum Mater, Product Owner and Development Team) does not experience interferences while work is being done on the product increments. A trademark of Scrum is that it is very tolerant of change and adaptation. Agile Project plans are never created and finalized in advance. The Scrum framework is implemented with the idea that development work is predisposed to change. Change is embraced and successfully managed during the development of the product increments.

Scrum Change: Time Boxing

Time boxing is another practice that supports flexibility in Scrum. All Scrum ceremonies must not exceed the maximum amount of established time. For example, the Daily Scrum meeting is time-boxed to 15 minutes, and the Sprints are time-boxed from 1-6 weeks (typically 2-4 weeks). At the end of the time-boxed period, the ceremony stops and is continued during the next time-boxed period.

Time-boxing provides stability towards the achievement of meeting deadlines and achieving high levels of throughput. Sprints provide stability and consistency within a changing development environment. Time-boxed Sprints also allow for frequent evaluation of the progress being made on a consistent basis. Issues and/or problems can easily be addressed very quickly. Time-boxing also allows for the Scrum team to revisit estimation practices so that the process can be improved upon in subsequent sprints. A Sprint allows the team to achieve their goals for the final product on an incremental basis.

Cross Functional Teams

The Scrum team is cross-functional and self-directed. This team style is highly focused on the achievement of the Sprint goals. A cross-functional team is one that has the skills and knowledge needed to complete the development work in the Sprints. A self-organized team is one that is fully responsible for determining how to complete their own work without direction from outside of the team. Micromanagement and command-control leadership styles are not appropriate for Scrum teams.

Scrum Change: Customer Value-Based Prioritization

Requirements (user stories) prioritization is based on the amount of value that can be delivered to the customer. When a Scrum project starts, a Prioritized Product Backlog is created. As changes are requested and approved, requirements are then reprioritized. When new or modified requirements are placed into the Product Backlog, they are evaluated during the prioritization process.

If the requirement has a higher value then the existing requirements in the product backlog, it is placed relative to its perceived level of customer value. This way, flexibility is achieved based on the customer’s value-based prioritization needs. The Prioritized Product Backlog is where changes are integrated. To be clear, new requirements and changes to the Product Backlog can lower the priority of existing requirements. This activity will result in lower priority items to be implemented at later time frames. High value requirements should always be worked on earlier than those of lower value.

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

Continuous Integration

The Scrum Team uses continuous integration to add new and altered features into the product increment either at the end of a Sprint or when it is appropriate. Risks are minimized because only the most recent features of the product version are being modified. All Scrum Team members are basically safe from making unnecessary changes to the product. There are several benefits associated with continuous integration (CI):

• Risk Reduction –  The practice of integrating code results in a reduction of risk on the Scrum project. When the Scrum Team integrates work on a regular basis, this amounts to faster detection and correction of defects in the code. CI also reduces the disparity between the current condition of the product and the code in the developer’s possession.

• Reporting and Analysis – When the Scrum Team includes review and substantiation activities into the CI process, value is added for the both the delivery team and managers. Metrics can be extracted regarding project health which can be used for trend detection and historical data purposes. These types of data elements are available to support retrospectives after each Sprint and provide value to reinforce the project’s intended direction. Examples of product metric categories include but are not limited to: unit testing, dependencies and levels of complexity.

• Validating Assumptions – Continuous Integration and unit tests provide the opportunity to replace false hypotheses with real information. This will limit cross-platform errors that must not get past the development environment.

• Process Automation – We all know that manual processes are slow, prone to errors and are painstakingly repetitive. When automation is used, we get assurance that processes will execute in the same way, every single time. In addition, processes can be run under version control. Benefits that support process automation include: (1) less manpower used for repetitive processes which frees up team members to do more important work; (2) the ability to lessen resistance for other members of the team to implement improvements.

• Better Project Visibility – CI is a practice that permits the Scrum Team to detect trends and make informed decisions. It provides real time, relevant and current data to support decision making. Using CI results in less relevant data gathering for the team. Documentation can also be automated that can be used for architectural purposes.

• Better Software Confidence – CI practices have the capability to provide more confidence in the development of software. Each software build can provide assurance that coding standards are being satisfied and functional tests are executed. This means that the product has been functionally validated.