What does a Sourcing Manager need to know about Scrum?

Regardless of whether you are a Key Account Manager preparing a quote, a Sourcing Manager preparing a tender, or a General Counsel defining standardized contracts, if you want to contract effectively for a Scrum project Qit is helpful if you understand the basics of how Scrum works, and how it is different from classical approaches.

Scrum is a simple, team-based framework for solving complex problems. Although it was initially modeled on successful patterns of developing products before software was a thing, Scrum was created for and is widely used for developing software products. You can use it for other complex endeavors.

Scrum was a founding member of a larger family of methodologies, known collectively as “Agile Frameworks”, which share common values and principles centered around learning, collaboration and purpose. These values are defined in the “Manifesto for Agile Software Development” and specifically reject the mindset of most modern companies, which values predictability, individual accountability and compliance.

Agile companies observe Steve Denning’s three “laws” of Agile: The law of the customer, the law of the network and the law of small teams. These companies are customer-centric, striving to delight the customer; information flows freely through the organization; and small, self-organizing teams solve problems to create value for customers and the company.

Since the contract defines the collaboration between two entities and reflects not just the project goals of the parties involved but also their values and mindset, contracting with an Agile partner will work best if both parties apply the Agile values and principles, and if the contract is compatible with those values and principles.

What are the key differences? Here is what you should know:

• A Scrum project strives to achieve a business goal, not to simply deliver a list of features. “Design a new printer that has the same performance as our current top of the line model, but only costs half as much to manufacture” would be a good mandate for a Scrum team.

• Scrum defines only three roles: The Development Team, the Scrum Master and the Product Owner. Together they are referred to as the Scrum Team. There are no context specific roles in a Scrum Team. Sometimes the word Team by itself will refer to the Development Team.

• The duties of a project manager are reapportioned among the three roles of the Scrum Team. A few of the duties are expressly forbidden under Scrum, such as assigning work to individual people. The Product Owner has most of the outward-facing or forward-looking responsibilities. 

• Just like a sports team that wins or loses together, the Scrum Team is one team that succeeds or fails together, not as individuals. 

About the Development Team

• The Development Team has all the skills necessary to solve the problem formulated by the Product Owner and organizes itself and deliver the solution requested. The Team is shielded from the noise of the organization while being responsible to the needs of the organization. No one inside or outside of the Development Team has command authority over the Team.

• The Development Team is dedicated to the project and only has one goal: to sucessfully create the desired product. The Development Team does not take instructions from anyone else but the Product Owner.

About the Product Owner

• The Product Owner’s financial duty is not merely to stay within the projected costs, but to maximize the value of the product created and ensure that the sponsors’ money is well spent. Sometimes spending more money can be in the customer’s interest.

• The Product Owner is the customer’s ambassador to the Scrum Team. If the customers or someone outside the project want something from the Team or need to know something about the state of the project, they talk to the Product Owner.

• A Product Owner has more decision-making authority than a typical project manager, including whether to cancel or continue development or to change the direction of the project. This job can only be filled by someone working for the customer.

• A Product Owner should never report to a project manager. Product Owners have the authority to make decisions whereas project managers generally do not.

About the Scrum Master

• The Scrum Master is the Development Team’s ambassador to the customer. If the Team needs to have an issue resolved to work more effectively, the Scrum Master will take ownership of the problem. It is essential that the Scrum Master have an independent line of communication to the customer. That person must feel responsible for quickly addressing the concerns of the Scrum Team. 

• The Scrum Master should not be an employee of the customer, due to the conflict of interest. 

About Requirements and Deliverables

• The product backlog contains a list of enhancements to the product, called product backlog items (PBIs), or Stories. This is the sole source of requirements for the Development Team. The backlog, except for those items forecast in the current sprint, can be changed, updated, or deleted at any time. This enables making decisions about the product at the last responsible moment.

• A Scrum project produces its result iteratively and incrementally. Each Sprint adds a small slice of functionality to the project (which can be measured in an acceptance test of some kind), called the product increment. 

• The latest product increment represents the current version of the product. Every sprint, the Scrum Team selects a small number of items from the product backlog for implementation which should be done by the end of the sprint (see the section on the sprint contract).

• A Scrum project must produce something that could be of value (“Potentially Shippable Increment”) to the customer every sprint, even the first one. This can be a challenge for new Scrum Teams. Whether to ship it or not is by default a Product Owner decision. It may be desirable to actually ship every sprint or perhaps even more often.

About Sprints and Sprint Events

• No project work is done outside of a sprint. Work before the first sprint planning should be kept to a minimum and should focus on creating the Scrum Team, the vision and the product backlog.

• Each sprint has the same duration, maximum one month, and must produce at least one potentially shippable product increment. If it is advantageous to deliver more often, this is permitted.

• Each sprint starts with a sprint planning, in which all members of the Scrum Team set the goal for the sprint and decide which backlog items will come into the sprint. This is the only mechanism for giving instructions to the Team.

• Each sprint concludes with a sprint review, in which the Scrum Team demonstrates the finished functionality.

• The sprint review is held for the stakeholders to get feedback on the product and identify possible changes to the product backlog.

• The sprint review is not for deciding whether individual backlog items are done. This decision has already been made by the Product Owner before the sprint review.

• The sprint review is not for evaluating the performance of the Development Team.

• At the end of each sprint, the Scrum Team holds a retrospective to review how they worked and define improvements which can be implemented in the next sprint. If the contract constrains their ability to implement improvements, it will also limit Team performance to a sub-optimal level.

About participating in Events and Activities

• The Product Owner must attend sprint planning, sprint review and backlog refinement and should be available when needed. 

• The Scrum Master should attend all Scrum events, but no event waits on the Scrum Master.

• The Development Team must attend all Scrum events. They should be present in the visioning and refinement process leading up to the first sprint planning. The Team members are 100% dedicated to the project.

• Stakeholders should attend the sprint review. Lackof stakeholders interest is a warning sign that the project is not valuable enough to justify its costs.

The text is excerpted from Ten Contracts For Your Next Agile Project, by Peter Stevens.
You can get the whole book now, or you can read it a chapter at a time as I publish it here under the label ten contracts. To download the e-book or pre-order the physical book visit https://saat-network.ch/ten