Demand/supply model

An often-seen demand/supply combination is the combination in which the demand party (often referred to as “the business”) uses a waterfall approach and the supply party (usually the IT organization) uses a Scrum approach. In IT delivery, a separation can be made between the responsibilities of client, user, manager, and operations on the one hand (demand party) and system developer and supplier on the other hand (supply party). This separation is indicated in the figure by the dotted line.

The supplying party could be both an internal IT department and an external systems or services supplier. The exact location of the dotted line is different for each situation. For example, the user stories etc. can be drawn up by the demand party in one occasion and in another by the supply party. One time the supply party carries out the acceptance tests; the other time this is done by the demand party. Depending on the number of Scrum teams, the complexity of the system and the dependencies between applications, the integration of the software is sometimes done by the supply party; the other time by the demand party. The same applies to, for example, integration tests and E2E tests, etc.

Both the demand and the supply party will have some responsibility for quality engineering, the exact tasks will differ from situation to situation.

When the demand party works according to a waterfall approach, a project manager and a test manager are often assigned to the project. The supplying party working with Scrum will have a Scrum team with a product owner, Scrum master and a development team. This setup will often lead to tensions, for example when the project manager has a clear end date of the project but the Scrum team determines what to deliver for every individual sprint.

At a general level, you could distinguish the aims of the demand and supply party as follows:

• The demand party establishes what is required and validates if that has actually been received and whether they actually achieve the pursued business value.
• The supply party delivers the IT system and demonstrates that what should be supplied is actually supplied.
  

In this situation there are two clear quality gates: one where the demand party hands over their requirements to the supply party, and one where the supply party delivers the IT system to the demand party.

In practice, the distinction between demand and supply party is often less strict. For example, the members of the development team (from the supply party) help the demand party in the requirements elicitation, when writing the epics and in the acceptance test. And vice versa, the expertise of users and operations people may be deployed for the building activities.

However, it is also often the case that the demand party and the supply party do not cooperate properly, especially when there is a strict contractual separation between the parties.

It is important to define the various responsibilities clearly. This certainly applies to testing. Who is going to act as the client of a test, who accepts the IT system, who wants advice on the quality and who will test what, and when? In other words: what should someone in the role of test manager consider?

• Define the expected quality.
  What is the expected quality of the IT system delivered by the supply party? The test manager and the demand party should think about this upfront and share the expectations with the supply party as early as possible.
  
• Define the additional tests.
  What has already been tested by the supply party and with what coverage?
  • In a well-organized situation, the supply party will show the test manager of the demand party their test strategy and test reports. In this situation, the test manager would establish an acceptance test strategy covering the still outstanding risks.
  • In a less organized situation or when the supply party isn’t willing to share their testing information, the test manager should think of another approach to establish the quality of the delivered software. The test manager could, for instance, start with an intake test (for example as an exploratory test) to gain an initial assessment of the quality of the software and take it from there. Software that shows significant faults at this point will probably need additional system testing, although this actually would have been the responsibility of the supply party.
    

A few characteristics of the hybrid demand/supply model are:

• Clear and measurable acceptance criteria must be established in advance for the transfer from the supply party to the demand party.
• At least two parties are involved, a Demand party and a Supply party.
• A combination of a waterfall approach for the demand party and Scrum for the supply party.
• Roles such as project manager, test manager, product owner, Scrum master and developer have been filled.
• Tension between end date of the project and sprint length and number of Sprints.
• This is a template “blogpost” to be used for every building block, page of wiki within TMAP.net
  
  Copy and paste text and images form tmap.net page to this part. Don’t forget to (re)select the images from the WP Media library!