Self-organization, cross-functional or not and release in Scrum

I was part of an earlier discussion before this was posted here. I'd like to share my responses/thoughts on these questions and get some feedback on my thinking from a broader community as well. I'm interested to see how others interpret the Scrum Guide and, more generally, the values and principles of the Manifesto for Agile Software Development.

Before I begin, I will state that my background is in working in regulated industries (aerospace industry) or supporting clients who operate in a regulated space (pharmaceutical industry) or dealing with adherence and compliance to standards (ISO 9001, ISO 12207, SOC audits, CMMI appraisals) and this may color some of my responses.

---

What 'release' means in Scrum. If the Product Owner decides to release the latest increment would this mean that must be made available to the users or a sub-section of its users?

This is the fundamental question.

Many of the definitions of "release" are around the noun. ISO/IEC/IEEE 90003:2018 (which clarifies ISO 9001 in the context of software development) and ISO/IEC/IEEE 12207:2017 defines it as "particular version of a configuration item that is made available for a specific purpose". IEEE 828-2012 defines it as a "software version that is made formally available to a wider community" or "delivered version of an application which includes all or part of an application" or "collection of new or changed configuration items that are tested and introduced into a live environment together".

If you abstract this to a verb ("to release"), the definition would involve the process by which a particular piece of software is made available for a downstream consumer. Who that consumer is isn't defined. If you are building a complex system (perhaps a combination of electro-mechanical components and software components), the recipient of a release is an integration team that takes the output of an electro-mechanical design and development process and the output of a software design and development process and combined them. If you are building a life-critical system, the recipient of a release could be an independent quality assurance team that performs verification and/or validation with independence. If you are building a mobile phone app, you may release to your Beta channel and let early adopters download the update and provide feedback. If you are building a web application, maybe you are going to perform A/B testing and run two releases in parallel to perform an experiment. Scrum doesn't preclude any of these scenarios.

In Scrum, the result of a Sprint is a "potentially releasable Increment of "Done" product" that the Product Owner can choose to release. Release simply means to the next step in the process. What that step is depends on the context that the organization exists in and the team is working in. Whatever is produced should be consumable by that downstream process without any issues. No downstream process should exist to find issues with the work done by a Development Team, but rather to provide some type of value, whether it's added value to end customers directly or value in maintaining compliance that gives end customers confidence in the product quality.

I find the term "user" confusing. If you would consider an independent quality assurance team or an integration and test team to be users, then yes - the Product Owner would decide if an Increment should be released to users or not. However, if you use the term "user" to refer to end users of the product or system, then no, a release in Scrum may not immediately reach any set of end users.

Considering this, would say that a team is cross-functional if on by the decision of the Product Owner to release the latest increment the team is unable to do so? Meaning that if the decision to release is made further work as in checks and approvals are needed.

A team is cross-functional if it is able to take a set of work and progress the work to a "Done" state without going outside of the team. At worst, dependencies outside of the Scrum Team should be minimized - there may be instances where very specialized knowledge or skills are needed to understand the work and get it to Done, but the effort should be to bring this knowledge onto a Scrum Team by embedding the experts or by having the experts teach the Scrum Team what is necessary to know or do.

If the team cannot, on their own, get work to a state that is ready for release to the next processing step, then the team has not achieved cross-functionality yet.

When it is 'Done' in Scrum? The Increment consists of 'Done' work according to the definition of done which may vary indeed across organization. However, to supports empiricism would you say that whatever teams and organization may decide that 'Done' is to them - evidence must be shown that the latest increment of 'Done' work function alongside with the past increments. True or false?

This is true.

The Definition of Done applies to both work items (such as Product Backlog Items) as well as the Increment as a whole. Consider "early and continuous delivery of valuable software" and "deliver working software frequently" and "working software is the primary measure of progress". Every delivered Increment must be working and valuable.

Now, valuable makes it tricky. And when you're working in a gated environment, value means different things to different people. Coming from my experiences in aerospace, it was much easier to get software to test on physical hardware in an integration lab than to get the physical hardware onto an aircraft. Ground tests and flight tests are expensive. So it may make sense to regularly have the software teams release to the hardware/software integration teams and less frequently take new revisions of hardware and software and try to field them, simply due to the time and cost with the steps required to put software into the field.

It's critical that the Definition of Done makes sense and supports a continuous flow of work. This is something that a lot of people get wrong. In environments with independent quality assurance or system integration and test, these people do not exist to find defects in the software. Independent quality assurance exists to provide a second set of eyes to check the built software against user needs and requirements to ensure that it functions as properly - they shouldn't be finding issues with either requirements or design/build, but it's better for them to do so rather than software to be released to end users and cause injury or death. Likewise, system integration and test exists to ensure that the software and hardware actually works together in cases where it may be cost-prohibitive to give the software team access to real hardware - sometimes, things happen and interfaces don't work well together, so it's better to find it in a lab and determine if the changes are going to be made to hardware or software or both to provide a high quality system in the end. Likewise, beta testers aren't there to find bugs, but rather validate that you are on the right track - the issues they report should identify misunderstandings in end user needs so they can be corrected before go live rather than finding bugs in the implementation.

Teams that are alienated from this and are not able to release and deploy its own work as need are self-organizing team?

This goes back to the definition of release. A team is self organizing if it has control over how it takes inputs and transforms them into outputs that can be successfully consumed by a downstream process. In the context of Scrum, the Product Owner is the one who makes the call as to if it is worth it to release the product to the downstream process or not, regardless of what the downstream process is. A release process is simply a handoff - what that handoff looks like varies widely, though.

A team should be able to hand-off its work to the next person or group successfully.

---

I do think that there's one thing missing, and Lean can give us some answers to this.

In Lean, hand-offs are a type of waste. However, there are also two types of waste (or muda). Type I Muda is a processing step that does not add value, but end customers find it necessary. Type II Muda is a processing step that doesn't add value and is unnecessary for end customers. One should try to eliminate Type II Muda while reducing the burden caused by Type I Muda. If you have hand-offs in your process, you should seriously be questioning if they are necessary - determine what rules or regulations or commitments or obligations require them to exist and if there are other, leaner ways to satisfy those obligations. This could be working to eliminate those hand-offs, but it could also be ensuring a higher quality product as input to those downstream process steps to eliminate defects (defects are waste, as is adding inspections or other steps to find and detect defects before starting work).

So I'll try to respond to these as best as I can understand your questions and feel free to clarify.

#1: I'm pretty confused on this but are you asking "If the PO demands a release, is the team really cross-functional"? If so, I'd say keep in mind that there is a difference between "Cross-functional" and "self-organizing". Cross-functional doesn't have anything to do with decision making, it pertains to the skills on the team. 

#2: "Release" can mean anything from a full on release to the customer/client or a release to a UAT style environment. It's for the team to decide what "release" means for them; Scrum itself does not dictate anything on this matter.

#3: The Definition of Done is always (or should be) adjusted and changed as a result of empiricism. As to your T/F request, It's true. If a new increment doesn't function alongside a previous increment; it's not done. This is usually part of a team's DoD to check the functionality of the new increment with the previously released increments.

#4: This is a tough one. There could be many valid reasons as to why a single team cannot release their product, this doesn't necessarily mean they are not self-organizing or even alienated. 

Many thanks folks for giving me a hand here. Special thanks @Thomas for going into such details!



Currently I see two patterns. Unfortunately, I can't get my head around pattern one.



#Pattern one: Stage gate development is fine too, and works with Scrum. As long as a party in the upstream develops work with sufficient quality that can be picked up by next party and continue as this, step-by-step until at some point it reaches the user - it is absolutely ok and it can be considered 'Done' and Scrum.

#Pattern two: If we were to reduce everything about Scrum to just two works I would pick 'Product' & 'Value'.

Product: it does not matter how many teams are working in perfect alignment and synchronization a product must produce value on it's own and independently otherwise it is not a product. Hence we do not have as many products as how many teams we have.



Value: With Scrum we develop and sustain complex adaptive products with the ultimate desire to produce 'Value'. Value indeed may mean many things however value it is what the Product Owner says it is.



My end though on this -

If we have a Product Owner who decides what 'value' is and at some point he may decide that a return of investment must be made and therefore he chooses to release the new increment. Would that be possible if each team would create 'done' increments in isolation?



If by releasing we mean, passing on the work downstream - would we really have the empirical process control in effect?





 Thank you.

Stage gate development is fine too, and works with Scrum. As long as a party in the upstream develops work with sufficient quality that can be picked up by next party and continue as this, step-by-step until at some point it reaches the user - it is absolutely ok and it can be considered 'Done' and Scrum.

Yes, but it does depend on what you mean by "fine" and "absolutely ok".

First, you need to determine if a stage-gate process makes sense and is useful for your organization and context. It's not always appropriate. And it's not only the fact that you have stage-gates, but how many and where they are. There's a lot of options here, but stage-gates are compatible with agile methods. Second, you need to consider the whole process flow, even when using stage-gates. If an upstream process is producing too much output into downstream processes, that's wasteful. You can't necessarily optimize a Development Team's Scrum process flow in terms of throughput if the throughput would cause work to pile up at a gate, so you would need to be aware of this and perhaps optimize for something else.

Construx has a white paper called "Introducing Agility into a Phase Gate Process" that talks about two models for incorporating agile (iterative and incremental) development into a stagegate. They use a notional 5 step process of concept, define, build, deploy, and maintain and talk about iterative and incremental development within the build stage as well as inclusive of the define and build stages. There are other ways to organize both your stage-gates as well as what process models you use between each gate.

it does not matter how many teams are working in perfect alignment and synchronization a product must produce value on it's own and independently otherwise it is not a product. Hence we do not have as many products as how many teams we have.

I'm leaning to yes on this.

In the most minimal example that I can think of that would involve independent groups involved in the process, you would need at least two groups for one product - a development team to take work from concept through building and then some kind of integration and/or test team to integrate and deploy. Product-focused development teams are stronger and support agility more than a single team supporting multiple products, so even if your independent quality assurance or integration and test teams were shared across all of your products, I'd be advocating for one consistent, stable development team for each product. I see ways to have one team support multiple products and one team for your downstream activities, but I don't think that's anywhere close to being a good way to do things.

If by releasing we mean, passing on the work downstream - would we really have the empirical process control in effect?

As long as there exists a feedback loop from the downstream processes to one or more upstream processes (it doesn't have to be the immediate upstream process), then yes, you do. You should also have internal feedback loops within all your processes to support continuous improvement. As long each process step inspects the outputs it creates, the methods by which it creates outputs, incorporates feedback from downstream processes, and maintains transparency along the way, I don't see how you don't have empirical process control.

If by releasing we mean, passing on the work downstream - would we really have the empirical process control in effect?

What you'd have is depreciation in any value added. Other things may or may not happen as work is passed "downstream".

I'd suggest that, for empirical process control to be established, the product has to be released into the environment where it provides value. This must happen in a timely enough manner for inspection and adaptation to occur. It is up to the Product Owner to communicate the meaning of product value clearly. The environment could be a representative subset of users, for example.