Direkt zum Hauptbereich

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:

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


Kommentare

Beliebte Posts aus diesem Blog

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Teamleitungen gesucht

Was macht Teams erfolgreich? Kann man das lernen? Ab Herbst starten unsere Kurse für aktuelle und künftige Teamleitungen. Jetzt gibt es die Gelegenheit, den Kurs zu testen.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Microsoft Copilot - Notebook, Pages, Agents und mehr

Es tut sich sehr viel an der Copilot Front. Gefühlt entwickelt Microsoft mit aller Kraft die KI-Anwendung weiter. Mit dem letzten Update hat sich die Microsoft-Startseite stark verändert. Hier zeige ich, was sich hinter all den Begrifflichkeiten verbirgt und was davon alltagstauglich ist.

Nachschau zum Lean Coffee-Spezial "Agil einfach machen" (Interaktive Buchvorstellung)

Bei unserem Lean Coffee-Spezial Ende Mai waren wir von Lean Coffee Karlsruhe/Frankfurt Zeugen einer Buchvorstellung, doch nicht nur das – natürlich gab es auch einen nicht unbeträchtlichen Anteil an eigener Aktion, denn bei unseren Spezialterminen ist traditionell „Teilgabe“ angesagt. Das Autorenduo Christian Baron und Janick Oswald zeigte uns, was es mit „Agil einfach machen“ auf sich hat.  

Wenn es mal gerade etwas schwierig bei Kund:innen wird… Zwei Fragen, die uns helfen, unsere Strategie mit unseren Kund:innen abzusprechen.

Seit 2024 organisieren Bob Galen und ich eine Masterclass für agile Coaches. Wir möchten die Ausbildung von agilen Coaches verbessern und ihnen Techniken mitgeben, mit denen sie bei ihren Kund:innen etwas einfacher haben. Bisher haben wir in vier Durchgängen mit jeweils 14 Modulen ungefähr 70 Extraordinarily Badass Agile Coaches ausgebildet (/1/). In diesem Blogpost möchte ich ein paar Erfahrungen und simple Techniken aus der Masterclass teilen, wie wir unsere Strategie besser abstimmen können. Sie beschränken sich nicht auf agiles Coaching – das ist nur das Setting.

Kleine Organisationsveränderungen, die direktes Feedback erzeugen

Große Veränderungen sind in einer Organisation schwer zu messen. Oft liegt zwischen Ursache und Wirkung ein langer Zeitraum, sodass die Umsetzer:innen nicht wissen, was genau gewirkt hat. Hier ist eine Liste mit kleinen Maßnahmen, die schnell etwas zurückmelden.

Schätzungen sind schätzungsweise überschätzte Schätze

"Wer viel misst, misst viel Mist." Zumindest ist diese Gefahr gegeben. Entweder misst man z. B. Mist, weil man zu früh zu KPIs zur Messung von Ergebnissen greift, oder aber man greift zu den falschen KPIs, die gar nicht das messen, was man wissen möchte. Einst war agiles Arbeiten der alternative Ansatz, aber inzwischen gibt es auch für einige Details dessen, was in Konzernen als "agil" praktiziert wird, einleuchtende alternative Ideen, die bis heute noch nicht so richtig auf die große Bühne vorgedrungen zu sein scheinen. 

Agil sein heißt nicht, unternehmerisch zu denken

 Die Diskussion, ob Agilität ein „Hype“ war, der nun vorüber ist. Ob wir schon im „Post-agilen Zeitalter“ leben. Und wenn ja, wer dafür verantwortlich ist: diese Diskussion nehme ich jetzt schon seit etwa anderthalb Jahren wahr, und sie geht auch aktuell weiter. In meiner Branche wird Agilität weiter gebraucht Ich bin in der speziellen Situation, dass ich beruflich aus dem öffentlichen Dienst komme und auch seit meinem Ausscheiden vor 15 Jahren weiterhin vor allem Kunden im öffentlichen Bereich berate. Also auf einem Parkett, das normalerweise nicht mit den Anliegen des Agilen Manifests verbunden wird: der Produktion von Software für gewerbliche Kunden in einem unsicheren Umfeld. Auf diesem scheinbar „exotischen“ Feld hat sich in den vergangenen sechs bis acht Jahren bei vielen Verwaltungen die Erkenntnis verbreitet, dass agile Vorgehensweisen bei den anstehenden Transformationen für sie sinnvoll sein können. Denn auch Projekte z.B. die „Digitalisierung der Verwaltung“ (ein völlig ...