Agile working is here to stay (and that's a good thing).
External parties are indispensable (and that is often a good thing).
Frequent patterns that I have come across mean that these two important components of cooperation unfortunately do not fit together.
I would therefore like to make a plea for two old acquaintances. When brought together, they ensure that excellent, agile collaboration can develop.
This article is a transcript of the presentation I gave at the Lean-Agile-Scrum conference in Zurich on June 23, 2022.
Why is this topic important?
This day alone shows that agile working is important. I am almost no longer surprised who in my circle of friends has heard of agility as an organizational idea.
The cello player? Yes.
The cabinet maker? Also.
What continues to surprise me, however, is the extent of cross-company collaboration. I have hardly seen any companies that have not collaborated in some way with people from other companies, the "externals". On the contrary, I even see this cooperation in the areas of core competence of some companies, in their research and development.
It seems difficult to find reliable statistics on this. Arbitrary categorizations, a lack of representativeness (reliability), data that is ten or more years old, all this and more simply does not allow any representative, up-to-date statements to be made. We therefore have to rely on empirical values and I would like to ask: Who knows a company whose IT or R&D work does not involve external parties? The answer, here, added in writing: Only three people (out of around 60 present) came forward!
I was very surprised by this research, which suggests an average collaboration period of around four years in Austria, Switzerland and Germany!
That is certainly a period of time that many a "team" would be proud to be able to stay together. It therefore makes sense to look at how collaboration can be improved.
Two dynamics come together - and now?
Let's briefly summarize what we have found out so far:
- Agile methods are relevant. It is about more than the necessarily distorted perception of the participants at an agile conference.
- Collaboration with external parties is relevant. Although the proportion of the Swiss economy as a whole cannot be reliably quantified, the joint search for the black swan during the presentation showed a clear trend: only three people knew of a company that did not work with external partners; and that was out of around 60 people present!
The duration of these cooperation agreements, averaging around four years, justifies investing in an organizational framework. - From the first two points, we can draw the probable conclusion that agile collaboration with external parties is also relevant.
Short answers to almost everything
Before I jump into the topic with all my might, it's worth pausing for a moment. Agility is used so often that it seems advisable to me to provide a brief definition. When supporting clients, I use this minimal definition to make a lasting impression in just a few seconds.
Accordingly, agile working is characterized by three "I "s:
- Interaction
This means that agile working is always also collaboration. The team is generally the smallest unit. - Iteration
This collaboration takes place in closed feedback loops. Assumptions can be checked and corrected in these loops. The one- to four-week sprint in Scrum is the prime example of this. - Increment
For feedback to provide useful information, the result of an iteration must be potentially usable. At least to the extent that feedback is realistic and provides useful impulses for the next increment.
Continue in the text.
Why is self-organization important for agile working?
Self-organization is a key element of agility. On a personal and corporate level. For a team, this self-organization means at least designing and implementing its own work content, monitoring the success of its implementation and deriving future measures from this. I wrote more about this in this article under the heading "Decentralization" and in it I also go into Hackman's logic of self-organization in.
The agile manifesto provides three concrete, exciting arguments for how self-organization shapes results:
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
principle #2, https://agilemanifesto.org/principles.html
If changes are to be possible at short notice, a team must be able to act quickly and flexibly. If a change request has to be filled out every time, which is then escalated to a committee, "late in development" will probably become "too late in development".
Secondly:
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
principle #5, https://agilemanifesto.org/principles.html
Everyone involved needs a basis that enables the team to work together excellently. We will see in a moment that a clear (economic) basis is also important for the client in the case of cross-company collaboration.
And third, but not least:
The best architectures, requirements, and designs
emerge from self-organizing teams.
principle #11, https://agilemanifesto.org/principles.html
In hardly any case is the entire competence available to one person or one committee. New, ground-breaking ideas often emerge through creative collaboration. One thing leads to another. Agile collaboration with external parties therefore requires the space for this self-organization.
The challenges of the law
Anyone who has practical experience now will probably have a big BUT in their head. All well and good, but how can this be reconciled with the limited right to issue instructions to third parties?
The Swiss regulatory law on this in a nutshell, in § 321d OR:
V. Compliance with orders and instructions
(1) The employer may issue general instructions concerning the performance of work and the conduct of employees in the workplace or household and give them specific instructions.
(2) The employee shall comply in good faith with the employer's general instructions and the specific instructions given to him.
https://www.arbeitgeberweisungen.ch/gesetzliche-grundlage
Incidentally, the legal basis in Germany is similar and the principle is transferable. According to the law, no instructions may be given, neither about general orders nor about the execution of the work!
Temporary workers are a special case in this regard, as they are integrated into the company's right to issue instructions by virtue of the temporary employment contract and are subject to the formal superior.
However, whenever the right to issue instructions does not apply, the question is: How can direction be determined without issuing instructions?
Giving direction with an inspiring vision
Most of the solution is so simple at first glance that I hardly dare to present it here. Fortunately for me, it is only so simple at first glance.
Talking or writing about visions sometimes causes my counterparts to wave me off, telling me "we've already done it". Or that it's too banal to actually be a solution. Sometimes I get an enthusiastic response, followed by long, silent moments of searching before presenting a one-liner.
And quite honestly, most visions are simply not lived. And to be clear now: I mean these one-liners, they are a waste of time.
Vision - concrete and sexy - even in the SAP environment!
Who would have thought that I could combine SAP and sexy in one sentence?
[A surprising number of people laughed at this point.]
What I mean are the headlines that inspire, that are shared in the first 30 seconds of a new conversation and preferably with conviction. If you're thinking "sure, I'll be fine if I work at SpaceX", I'd like to explain this example to you:
With the introduction of SAP P21PS, we are enabling all employees worldwide to be reliably rewarded with a bonus for outstanding performance.
team of a customer who were at the beginning of an SAP implementation.
P21PS is not as exciting as a rocket launch - is it?
And yet this one sentence contributed significantly to the team - of course they were all external, only the product owner was an internal employee - standing behind the goal with conviction.
So what makes a good target description? There is no one right answer, but there are all the more possibilities. I am basing this on a description that can be traced back to the Scrum Guide and that we use in our training courses.
From the vision to the topics of implementation
The individual arguments in the picture hardly need to be supplemented; instead, I will focus on showing how it worked with the vision mentioned above.
First of all: This "P21PS" vision was developed in a workshop with the team members, the PO, internal architects, HR members, an SAP consultant and the division manager, around 20 people in total. The whole thing took less than two hours, in fact we were finished after about 90 minutes.
P21PS is a so-called SAP package that mainly concerns the extras in payroll accounting. So if someone receives a bonus, this is processed in this additional payroll module.
The P21PS vision has sparked an interesting ethos. The team was proud to help ensure that exceptional performance was rewarded.
Key topics for implementation can also be derived from the aforementioned vision:
- This is a new introduction, not an integration with existing solutions.
- The entire SAP package is introduced.
- It will be introduced worldwide for all employees.
- Definitions for outstanding services (or the input and calculation option) are taken into account.
- It is reliable, a word that could later be easily translated into a quantification.
- The recipients were de facto remunerated, so the goal was the real payment into an account.
Is man good?
All well and good, such a vision. But what happens when things get critical?
Let us inwardly answer the following question:
An airplane has to make an emergency landing. It breaks up on landing and the cabin fills with smoke. What happens now?
A
The occupants ask each other if they are all right. People who need help are given priority. People are prepared to sacrifice their lives, even for strangers.
B
Everyone fights for themselves. Total panic breaks out. People are kicked and pushed. Children, elderly people and people with disabilities are trampled on.
And how do you answer the question for yourself?
The result is curious. Most people assume that alternative B will happen. In fact, analyses of similar disasters show that alternative A prevails. In addition, alternative A is always reinforced when people are in direct contact with each other. The cover picture of this article is an excerpt from a book advertisement.
The author of the book, Rutger Bregman, describes this example and refers to the studies of Tom Postmes, among others. I have selected a key article on the subject, which can be viewed after registering with Research Gate.
Burn all contracts! Or not?
If it is the case that the majority of people act in the interests of the community, why should there be contracts at all?
Two reasons:
- Contracts provide a common basis. They provide clarity because criteria have to be discussed and described. They are used for control purposes.
- Contracts offer a safeguard. Although the majority of people act with the greater good in mind, not everyone does and not always. They serve as a safeguard here.
So there will also have to be contracts in agile collaboration with external parties.
In agile working, costs and deadlines are fixed. Of course: I can describe the end date for each iteration. Assuming that the main cost factor is working time, this can also be predicted for each iteration. The scope is negotiated each time for planning and checked in retrospect, so it is an estimate.
The two other triangles in the picture above already show that the current contracts do not fit this way of working.
In a fixed-price contract [when asked, no one needed an explanation for this, only the joke was made that the purchasing department in the relevant company prefers to fix deadlines at the same time], costs and scope are fixed, often in elaborate service descriptions. In any case, this type of contract is not suitable because it does not take into account the cadence of agile working, with the many fixed deadlines and the resulting data points.
With contract types based on "Time & Material" (T&M), only the scope is fixed; costs and time are flexible. However, a fixed scope in turn leads to the aforementioned problems of complex service descriptions. T&M can be designed in such a way that deadlines are fixed and scopes are estimated, thus coming closer to the requirements of agile working, but never with the safeguarding of costs. The less regulated handling of performance results in T&M contracts results in critical risks, especially in sensitive areas (R&D, IP).
The great strength of the agile fixed-price contract
This plea, as I mentioned at the beginning, is about old acquaintances. According to my archaeological research, the agile fixed price contract (abbr. agile FPV) is at least twenty years old. Some of the authors of the agile manifesto (Alistair Cockburn, Martin Fowler) and some of the veterans of the field (Mike Cohn) have worked on the topic. The agile FPV is based on the fixed price contract, but fixes costs - initially as a cap - and deadlines as delivery dates for completing iterations. Accordingly, the scope becomes an estimate.
I have used all my drawing skills to visualize the agile FPV and would now like to explain it using the picture:
First part of an agile fixed-price contract
At the beginning, and this is a bridge to the vision, the goal and criteria that are relevant in terms of time are described. An initial scope is derived from these, which contains the most important topics that are to be achieved as a result. At this point, by the way, I recommend aligning this with quantifiable indicators; the design would go beyond the scope of this document, but I am happy to discuss this with you.
The maximum costs after which the contract is terminated are also specified.
The risk share describes which party ("internal" vs. "external") bears which share of the deviations in cost estimates. This share should be between 30 and 70 percent and is a design element that significantly influences the future backlog. I therefore recommend a strategically considered decision here too.
Exit criteria describe for all contracting parties the conditions under which they can terminate the contract. Exit criteria can be results for the customer, protection of intellectual property, etc.
The development of these initial criteria can take place in an initial phase that comprises several iterations, i.e. a few weeks to a few months. This phase can also be put out to tender several times and extend to an MVP tender.
Second part of an agile fixed-price contract
Once these basics have been jointly developed (and I emphasize jointly and developed), the work can begin in iterations and increments. A backlog is derived from the initial scope. Its items are estimated on a relative basis. Here I wrote in detail about the basics of estimating work. The aim of everyone involved is to improve velocity without making unrealistic estimates, which is ensured by the aforementioned risk share. Topics can be exchanged within the scope of velocity, provided they contribute to the overall goal. This so-called "exchange for free" is a key feature of agile FPV.
The whole thing can be driven forward for as many iterations as the contracting parties wish and the previously agreed exit criteria allow.
For more details, I recommend the standard work "The agile fixed price"Unfortunately, it is only available in German. It also does not contain more recent initiatives on procurement processes and MVP tenders and contract (reverse) auctioning. These are topics that have been further developed in recent years but have not yet found their way into books and can instead be found in lectures, reports and websites. Anyone who would like to know more about this is also welcome to contact me afterwards.
Between context and control
Let's close the lecture with a loop to the beginning.
Excellent performance is the result of exceptionally motivated people who know why they are doing what they do. Regardless of whether they are working with internal or external employees,
People need a lot of direction and a little security when working together.
The shared vision provides context and direction. Joint control and protection can be achieved with agile fixed-price contracts.
The space that opens up between these two enables real, cross-company agile collaboration. Always try to enlarge this space!
to be continued
This article is one of my longest. And yet not all the questions have been answered. A lot of information is not available in collected form, so I have tried to provide it here.
Some questions are simply still open, for example: What if only one person in a team is external?
What else do you know that is interesting for this topic?
What other experiences do you have?
Comments
Write a comment