How/Where is the Increment made available?

Is the Product Increment made visible through its code base, or through the customer-facing functionality delivered?

It depends.

First, the Increment in inspected at the Sprint Review. The Scrum Guide does define some elements of the Sprint Review. Many are discussion oriented - explaining what was done and not done, discussing what went well and what problems arose during the Sprint, a discussion of the status of the Product Backlog and projection of delivery dates, reviewing how the marketplace or use of the product is changing, reviewing timelines and budgets.

The Sprint Review could also include demonstration of work that was done. There's no definition of how the demonstration is conducted. Coming from a software development background, I tend to discourage "live demos". Rather, I encourage teams to create walkthrough videos of the done work that highlights relevant changes and be prepared to talk about it as its running. This makes this go a little faster, and it also prevents hiccups or technical issues (not necessarily related to the product).

However, one of the best forms of feedback is a user actually using the software. If user representatives are available at the Sprint Review, it may be a good idea to actually make the software available to the user. There is some level of risk here, depending on where the review is held.

Outside of the Sprint Review, the decision to release is left to the Product Owner.

I think it's important to identify that the concept of "release" is unclear. There is nothing that says that the release must be to production. Consider app stores or marketplaces that allow users to opt into beta releases. Or consider web applications running in a sandbox, demonstration, or pre-production environment. Or consider software being deployed in the context of regulated industries that must undergo a formalized release process. Scrum gives the Product Owner the ability to decide to release the software somewhere, but the Product Owner may also be guided by organizational or regulatory requirements on a release process.

My suggestion is always to maximize feedback. Whatever your release process is, it should increase the ability of the team to get real feedback from user representatives or users on the work that they are done. This can help the Product Owner shape the Product Backlog and the Development Team to make informed design decisions.

Is the Product Increment made visible through its code base, or through the customer-facing functionality delivered?

@Timothy Baffa, Good question! I believe that is one way of looking at it. However, assuming it has not been released to the customer i.e. the wider market, then where does it reside internally within an organization? How is it made transparent to the stakeholders even before it reaches the market?

Also, let us take this angle, when an Increment is being developed during a Sprint, how is it progress made transparent to the Product Owner and to the internal stakeholders?

However, assuming it has not been released to the customer i.e. the wider market, then where does it reside internally within an organization? How is it made transparent to the stakeholders even before it reaches the market?

If something is not available, it hasn't been released. I don't believe that it needs to be widely released to all stakeholders - there are different ways to release software to different people. The only ways to make the work transparent to stakeholders are to create demonstrations or to make working software available (either via source code or distributing an installer or hosting the software somewhere). Actually letting people use the software will get better feedback than demonstrations.

Also, let us take this angle, when an Increment is being developed during a Sprint, how is it progress made transparent to the Product Owner and to the internal stakeholders?

During a Sprint, the progress is made transparent via the Sprint Backlog. Perhaps it's just a view of the Sprint Backlog that shows the progress of Product Backlog Items selected for the Sprint. Also, the team and Product Owner do not need to wait for the end of the Sprint to make an Increment available, so releasing the Increment early is another method of making progress transparent.

when an Increment is being developed during a Sprint, how is it progress made transparent to the Product Owner and to the internal stakeholders?

For this transparency to happen, might the team need to implement a strategy, within Scrum, that allows their workflow to be actively managed?

For this transparency to happen, might the team need to implement a strategy, within Scrum, that allows their workflow to be actively managed?

@Ian Mitchell, I am not sure I have the answer to your question, however, let me make an attempt, if its nowhere close, please help :)

Perhaps not within Scrum, but if the team is to implement a strategy, they could have a sandbox environment where stakeholders can interact with the developing Increment if they wished to.

My understanding here is that the Increment is a piece of working code that meets the DoD. Therefore is it made available through a codebase through a shared repository like GitHub?

Please note that a Done Increment is not working code, it is working software!

Working code might not have any Value, if it is unable to interact with third-party systems, or if it has no UI.

Working code might not even be usable let alone Valuable.

A workflow management system like Jira can be sufficiently transparent to make progress transparent .

But for sure, it is not about actual "software you can see". It all depends on what lever of transparency is needed.

A sandbox environment might prove to add transparency, but it might also delude it.

Just as an example, a developer finishes a user interface, but it contains no logic or backend a all. Stakeholders might see this interface on the sandbox environment, and think it is already Done, shiny and polished, where it actually is an empty mocked shell.

So, What Ian said, the scrum team should design a strategy for transparency. This can be simple (and maybe should be), but there are multiple factors to consider.

Also, a factor to consider is that if extra effort is needed to meet the level of Transparency, this effort can be seen as Waste, since it is not contributing to the actual Done Increment, therefore, the strategy should preferabel  not create waste and not demand additional effort in the development process (or at least as little as possible). So there is a tradeoff there.

You should collaborate with stakeholders what helps them and what meets their expectations.

But I think the biggest point to consider is: what is the added value of the transparency needed. If it is to help Inspect and Adapt, to continously improve, you should embrace it. If it is for management to be in control, and to help them in top-down leadership, you are investing in the wrong reasons. So how much Transparency is needed (as opposed to wanted) and why. In the end, your quest for Transparency might be fueled by lack of Trust from others ;)

the scrum team should design a strategy for transparency

Kanban is one strategy which Scrum Teams can choose to implement. Doing so may improve transparency, in so far as the workflow is then made visible and actively managed. Limiting work in progress, for example, may reduce the time during a Sprint before demonstrably complete items are available for inspection by a Product Owner.

We have a number of internal stakeholders for the work we do.  To make the work visible we have an internal staging area where we can push the code and let the internal stakeholders exercise the code in order to provide hands-on feedback.  We also push all external facing code to the staging area and have some "proxy" stakeholders work with it.  Our "proxies" are usually our support staff, sales or any other group that interact directly with external customer base on the functionality of the product. The proxy solution isn't ideal but it is the best we are allowed to do and is better than nothing at all. 

Just making it visible via a code base doesn't really help most stakeholders because in my experience very few of them can actually read code.

Doing so may improve transparency, in so far as the workflow is then made visible and actively managed. 

@Ian Mitchell. Is it sufficient as far as Increment transparency is concerned to only ensure the workflow is transparent and not the actual tangible Increment? Need some help here, if there is a scenario where the individual items cannot be inspected by the PO, then I am understanding that the inspection can happen only once the Increment is "Done". Should the PO aim to inspect this Increment prior to the Sprint Review, or it acceptable to do so during the Sprint Review?

Please note that a Done Increment is not working code, it is working software!

@Xander Ladage, That's a very good point! Thanks for that.

Apart from using the DoD, Scrum doesn't advise on other practices that will help make the Increment transparent. From your experience, could you help with any other best practices that may help with this? What are some common things that may make the Increment lack transparency? Also, when we talk about Increment transparency are we talking about transparency to the Scrum Team and the internal stakeholders or even to the market/customer? Just to ensure my understanding is clear, would the example of disclosing what a software update does constitute this transparency to the external stakeholders?