Does Scrum help with procurement?

Scrum is frequently used in software or technology companies. So, many people categorize this way of working as a software development method or as a project management approach. To show how Scrum helps to solve complex problems, let's take a look at purchasing processes.

Scrum gives us a structure that helps (or supports, or maybe forces) us to do something. We want to do something because we (or others) are not satisfied with the results or the process. Let's understand first what is procurement and what are typical problems.

What is procurement?

In bigger companies, there is typically a dedicated purchasing or procurement department. At some point in the history of a company, all departments agreed to centralize the selection of suppliers, the management of contracts and the actual purchasing of goods and services. Especially in a mass business, there is a business advantage to standardize and streamline processes. If you are new to purchasing, you maybe you want to take a look at a Wikipedia article, the Handels-H-Modell (in German language) or the SCOR reference model.

What are the problems with central procurement?

People in central departments tend to be frustrated. The main reason is that the other departments do not remember their commitment from the past to centralize some processes. There is no real collaboration anymore. That means: procurement people are constantly on a chase:

• Are we involved in the purchasing processes early enough so that we can help? Are we really aware of all critical purchasing activities?
  
• Does everybody respect the purchasing processes that we agreed on so that there are no problems with the deliveries?
• Are people using the right contracts and right products?

Instead of looking at overall quality and cost, they are often measured by financial savings. Moreover, there always more to do than expected.

On the other hand, people in production and elsewhere are frustrated with central functions:

• The once agreed processes do not match the reality. Processes and tools are too rigid. They are to slow.
  
• Purchasing people do not really understand, what to buy.
• Instead of selecting good suppliers, purchasing always selects the cheapest one.

The reader might add his or her own complaints. How can Scrum help?

What is Scrum actually?

Scrum is a framework for solving complex problems. (If you want to learn more about Scrum, read the article "How do you familiarize yourself with Scrum and agility?" here in this blog.)

The basic idea is not to copy the Scrum Guide. The idea is to create some kind of structure that helps to improve regularly. In that sense, Scrum can offer two things:

• A Product Owner perspective would focus on happy (internal) users of the purchasing department. The elements of Scrum can be used to improve the services. The Product Owner would create a list of characteristics of a good purchasing department. He or she will regularly meet with internal customers and suppliers to find out what to improve. He or she will establish some rhythm like a week or a month to select things to work on. Normally, a Product Owner is one of the senior leaders of the purchasing department.
  
• A Scrum Master perspective would focus on happy employees in the purchasing department. The elements of Scrum can be used to improve the (internal) processes. Good processes will lead to happy internal customers, too. The people who are doing the work (the developers) will select a strong Scrum Master. He or she will guide the developers through an improvement journey. He or she will establish some rhythm like a day or a week to improve in small steps. A Scrum Master is comparable to a team leader. And my first recommendation is to ask team leaders to live their role more like a Scrum Master.

How to start to improve the Purchasing Services?

Let's assume that we still want to have a central function for procurement in our company. (In some cases, specialized silos of activity create many problems. One solution might be to distribute the specialists to the teams where they are needed.)

The Product Owner needs to define the services of the department. The first questions are: If the purchasing department were an independent agency: 

• What services would it offer? 
• What are the special features of each service? 
• At what price do we offer them? 
• What quantities are we expected to deliver? 
• How quickly do we need to deliver results?

The Product Owner would meet different stakeholders. Piece by piece, he or she will create an image in the head what good services will look like.

The Product will create a list of services. That is the Product Backlog. In intervals, the Scrum Team will work on the different services until it meets the needs of the internal customers, and until the services are profitable.

How to start to improve the purchasing processes?

In Scrum terms, improving the processes is the business of the developers and the Scrum Master. We know that multi-skilled, small and dedicated teams are much more productive than large teams who could not really focus.

That's why we want to form small and stable teams as quick as possible. This needs to be supported by a strategy for transferring and distributing the right knowledge to the team members. Initially, we may have a team of 20 people because we have a high degree of specialization. The team members create a table with the necessary skills and information about the experience level of each team member. This is the basis for knowledge transfer activities each week. After a while, the team can be split into two teams of 10 people. Even later, the teams can be split again into teams of 5. Now we have 4 teams with the capabilities.

Parallel to these team formations, the Scrum Master takes care of a broader picture of the expectations of the processes:

• What are the things or classes of work that we deliver?
• What is the arrival rate of requests? How long do we need to deliver?
• What is the quality of the results? How stable is the process?

There are different types of processes with different challenges. Together, the developers decide which processes to improve first.

 The difficulties in this step lie in the very concrete definition of the problems. Initially, the problems are defined too broad. That paralyzes the developers. A good Scrum Master can ask very specific questions which spark creativity.

The developers need to agree on a structure for collaboration. E.g. they agree on meeting every day in a Daily Scrum and on improving something every day. There are two good books about small improvements:

• Maurer, R. (2014). One small step can change your life: The kaizen way. Workman Publishing Company.
  
• Rother, M. (2009). Toyota kata. New York, NY: McGraw-Hill Professional Publishing, see https://public.websites.umich.edu/~mrother/Homepage.html

Does it help? Yes. Mirko Kleiner has recently published a book about Lean Agile Procurement. There, you will find some interesting case studies.