Scaling Professional Scrum and non-software products

Hi Ian,

It is my understanding that one of the reasons that Ken moved away from Scrum Alliance and initiated Scrum.org was to limit the scope of Scrum to software development. But I guess you and other people here are better equipped to comment on that.

A reason to limit Scrum to software engineering is that other fields are less suitable for emerging architecture / infrastructure. Then again I heard this story about building a sub-marine. After the design phase has finished and construction of the hull has all but completed, it was concluded that the hull was not large enough. So they just cut the hull in 2 parts and inserted an additional section.

Another example of scaling up large projects with a strong physical component would be ASML. They manufacture the equipment that Intel and TSMC use to produce computer chips. I worked there as a software architect some 10 years ago. The code base was 6-8 mio lines. The hardware has the size of a truck and contains a stage that accelerates faster than any sports car and still position at nanometer range precision. The production facilities had the size of a small town. We had a total of 1500+ engineers. 500 were doing s/w engineering.

At that time Agile / Scrum was not fashionable. The way scaling was organized was: small teams (3-20 people, daily s/w integration. Almost no hierarchy or closed management rooms. The efforts for orchestrate the engineering efforts among s/w, system engineering, optics, mechatronics etc was a shared understanding of the goal. To create a machine capable of producing chips that are faster and have better energy efficiency as the current generation we must use shorter wavelength. These wavelengths are imposed by stops defined by laws of psychics.

So we were organized to a common goal by a force: in this case laws of physics. I think some readers can comment to this from other fields like aerospace or military manufacturing.

My gut feeling is that scaling up large projects that are not s/w only, you need some kind of up front design and thus with some command and control type of organization.

In other words, my guess is that for projects with a large physical component, empirical design is not always possible from the perspective of risk management.

> My gut feeling is that scaling up large projects that are not s/w only,
> you need some kind of up front design and thus with some command and
> control type of organization.
>
> In other words, my guess is that for projects with a large physical
> component, empirical design is not always possible from the perspective
> of risk management.

You are not alone, many would share that "gut feeling". This is at least part of the reason why the Scaled Agile Framework has gained traction. The John Deere case study has been used to illustrate how SAFe can be applied to non-software contexts at scale. The empiricism you refer to may indeed become questionable with such implementations.

Agile Meets Big Iron: Agile Transformation at John Deere ISG http://scalingsoftwareagilityblog.com/agile-meets-big-iron-agile-transf…

I'm therefore wondering to what extent "Scaling Professional Scrum" (SPS) has addressed this gap. When scaling Scrum, I generally coach that any departure from providing an integrated release at least every 2 months (as per the Agile Manifesto) must be handled by exception. That's the principle. The need to make such exceptions can be mitigated by testing business assumptions, as opposed to trying to provide an enterprise PO with a minimum releasable feature set that includes these tricky non-software components. In other words the focus shifts onto validating a "Lean Startup" type of MVP. Unfortunately I don't know for sure if this aligns with SPS thinking...although I suspect it *probably* does.

I have personally participated in (hw/sw) telephone switch projects for Siemens and Nokia, and embedded sw projects for many organizations, including Bose and iRobot. I'd love to be able to get my mind around how to organize work, teams, and particularly testing for Tesla cars.
The whole area of scaled agile/Scrum for the Internet of Things and embedded sw has been upon us for a long time. However, I don't feel comfortable extending a framework beyond SW because of the demands and nuances of the various applications. Tesla, smart grid, and iRobot are wholly different domains.
So, I've stuck to sw. It is very clear to me that sw has a long, long way to go to meet the demands of our complex society, and there is plenty of work ahead of me and those I work with.s

I've been working on agile implementations and scaling Scrum for the last four years. To me, scaling carries with it the expectation that a substantial number of the benefits of scrum in the small can be realized by scrum in the large, say 40 teams. The expectation is that as the number of teams grows, the productivity and benefits also grown uniformly. Unfortunately, but not unexpectedly, the benefits usually scale in a non-uniform manner. So, I've been working on a framework and set of practices that allow at least some degree of predictability in the productivity and benefits.

We have a lot of work ahead of us, as usual, but what a great way to wake up in the morning.
Ken

I was searching for a discussion related to non-software product development.  I want to thank you for clarifying the focus and intent for Scrum/Nexus toward software. 

I'm curious if Nexus could be used for hardware systems product delivery?  Cloud hardware systems have complex variations that meet current and future business needs.  As a result I'm wrestling with how quickly a system increment can be delivered and if Scrum/Nexus could be used to guide production.