Here you are, a Scrum Master who has successfully made the transition from waterfall to agile along with your team. You have coached the team and facilitated self-organization. Your team has also started Sprinting regularly following a cadence and you are satisfied with the velocity achieved. All of a sudden you find that an impediment punches a hole in your perfect agile world.
Suppliers!!!
You believed that your movement to Agile would be mirrored by your Suppliers. However, they could not agree less with you!!
You could not convince them to move their process which has resulted in your team facing a huge impediment. They will need the supplier delivery for next Sprint which starts in 3 weeks. What do you do? If you would like to know of one of the templates to handle this situation, read on.
The Template
Back to the Statement of Work (SoW) - We now find ourselves in a position where Supplier has refused to move to an Agile process and will follow the waterfall model. Since the supplier is still on waterfall model, they would have signed a SoW with you giving the details of delivery along with other specifications. Let us go back to this SoW. Does it give a single delivery on a given date? Or multiple deliveries till the final version? It should not matter in which way the delivery is scheduled, although do make a mental note to ensure that next SoW should mention multiple deliveries. These deliveries would be associated with a deadline. Let us now look at how to use this SoW to solve the impediment faced by the scrum team.
OR
Slice the salami - Let us imagine that the delivery pipeline has been setup with Supplier where deliverable goes through rigorous internal testing (on Supplier side) and acceptance testing (on Client side) before being integrated into the Production. If you require repeated deliveries from your supplier for every Sprint, not only would the Supplier have to setup a robust system to handle the regular testing and fixes but you would also need to setup a regular acceptance testing format. In all reality your Supplier would be reluctant to handle the initial cost associated with this setup. After all he has a perfect working system in place. How do we handle our requirement of Sprint dependencies in this scenario?
If we go back to the Agile Manifesto we will find an important lesson:
"Customer collaboration over contract negotiation"
Let us discuss with the Supplier about the modalities needed to handle these deliveries. It is time to slice the salami!! If we visualize the delivery pipeline as a whole salami we need to slice it as thin as possible for our dependencies. However, the Supplier need not test each such delivery. We, as clients need to strengthen our test formats to support the Supplier and inform of any defects back to her. This helps both the Supplier and us by
Generating defects early
Providing regular deliverable for Sprint dependencies
The Supplier only tests those deliverable for which she has agreed as per the original SoW. This does not increase her cost hence, is a manageable operation.
However, now a key question crops up: "How do we synchronize the delivery slices to our Sprint requirements?”
Planning and Communication- This leads us to our last but most significant set of activities.
Planning - The Sprint planing and refinement activities should bring out those dependencies needed for next 2 Sprints. In parallel, Sprint planing should pull those Product Backlog items which can be completed using the high level delivery information from Supplier which should be taken as a guide. E.g, If you are trying to create a backend database solution through PBIs in current Sprint, while SoW says Supplier will be concentrating on the UI components, the Sprint will surely fail. One more question haunts us. When do do an intake? Will it be correct to do an intake whenever the Supplier provides a delivery, Surely not as this will lead to utter confusion. Imagine a situation where team is Sprinting with a Supplier sdk having API 1. In the middle of the Sprint, Supplier sdk with API 2 is taken in. It might result in complete Sprint failure. Hence, Supplier deliverable should be coordinated to be available either at the beginning or end of Sprint (for next Sprint) or at both times.
Communication - Regular communication with Supplier is needed in order to communicate the requirements of each slice. This should be done well in advance (at least 2 weeks). This will enable Supplier to get the requirements early and make any adjustment to his schedule. Feedback in terms of defects need to be reported every week so that Supplier is kept well informed of such issues. This might also help in getting early fixes to Critical issues seen in the sliced deliveries. Although not agreed to, after all no team wants to deliver crappy product to their clients!!
To summarize, a hotline with your Supplier goes a long way in solving the impediment you now face!!
Conclusion
However, before we conclude, there is an important question. Wouldn’t above mechanism lead to waste? After all any organization tending towards Lean operation would find it an anathema to support an operation which leads to creation of waste. In my experience, having successfully implemented above operation, I found that it not only stops creation of waste but actually, removes it. The metrics we ran to prove it were defect counts (as delivery timeline and scope remained same). As we had an SoW which had phased delivery plan, defect counts were taken at each phase and in total. It was seen that regular input of defects to Supplier led to better quality software being delivered at each phase and the defect count in total reduced by 25% from projects where waterfall model was followed.
Hence, in conclusion, above mechanism can be taken as a template to handle suppliers without modifying the SoW during Agile transition of your scrum team.
About Me : A passionate Agile leader having 16+ years of experience in software industry, I have handled Agile projects of various complexities. Having successfully handled Agile transition for multiple organizations, I write about my experiences, challenges and some solutions.