Embracing Agile Product Development

00:02 Please welcome Professor of Management, Science and Innovation at MIT, Steven Eppinger. Hello Liveworks 23. A lot of buzz this year around Agile development. It's not just for software anymore. Everyone seems to be talking about Agile now. My research at MIT has always been about improving engineering

00:36 and product development processes, and lately it's taken a turn toward looking at Agile. What are people doing? Why? How do we adopt Agile outside the realm of software? And today I'd like to share with you some of what I've learned and what you can learn about what I'm seeing out there in the world of applying Agile outside the realm of software engineering. We all know that Agile revolutionized software development over, say,

01:08 the past 20 years or so. And now I believe it's about to do the same for the rest of engineering. Now, if your engineering organization is like most that I've worked with, your software teams are almost surely using agile development methods. And what I hear from people like you is this How can we develop hardware using the same methods? Would the same methods apply, or would the constraints of hardware and physicality affect how they would work?

01:42 Do we need to adjust them to make them work? And why should we do this now? Well, here are four reasons. If you develop hardware and software, then everyone in the organization is already being exposed to Agile. Some of the terminology, some of the methods, how it works, some of the benefits. Second, most of the professional workers today are what we call digital natives, which is they want to work in digital first settings where remote work

02:14 and online collaboration are quite natural to them and they're also quite natural to the Agile workflow. Third, your product development teams operate in an environment of uncertainty and change. Specifications evolve. Use cases emerge. Technical debt is discovered. Supply chains are disrupted and more. And the structure of agile sprints helps us to identify these issues.

02:45 And if we're smart, we would address them more quickly. And forth workflows today are readily supported by tools that just were not available ten years ago. I mean, think about it. We have cloud native tools for engineering, for analysis, for project management and much more. And one more reason. Folks like you are so ready to adopt Agile methods

03:15 because folks like me are teaching it to students who come through engineering programs. Now I teach product design and engineering management in programs at MIT and in my product development class, we teach students how to create novel products, and we've been doing that for a long time. But what's fairly new is that we're teaching them how to use the Agile development process to do so. So here's how my students develop products using five two week sprints.

03:50 So the first sprint is what we call the research sprint. This is about discovering customer needs unaddressed problems and opportunities and use cases. The second sprint is the creative concept sprint, and this would end with a proof of concept model that we can review with customers in a sprint demo. The third sprint is a working model sprint. So we develop a working prototype. And this would end with demonstration of the working prototype

04:22 and feedback about that from customers in the Sprint demo. The fourth sprint is a refined model sprint, so it takes that model further and that includes testing with customers and other stakeholders. And the fifth and final sprint is what we call the alpha prototype sprint. So here we are developing and testing an alpha prototype, it looks like, and works like a production ready product. And I share this with you to show you that many of the young folks you hire today are going to be agile ready when they join your workforce.

04:58 But why bother with Agile? Is it really worthwhile to adopt this? Well, here's why. Agile is fast, friendly, flexible and familiar. It's fast because Agile can deliver value more quickly. And we do this by planning to achieve incremental, valuable progress in each sprint. So agile is friendly because it requires long term planning, which is hard,

05:31 but only at the very high level, which makes it a lot easier. And then we decompose these milestones into sprint goals, and then we do detailed planning only in the really short term, which makes it quite easy. Agile is flexible because it helps teams to respond to changes and feedback and uncertainties, and it does this through the sprint cycle built right in. And finally, Agile.

06:02 Agile is familiar because many of your teams are already collaborating remotely, they're already benefiting or they should be benefiting from stakeholder feedback and using iterative design approaches. And all of those techniques are built into Agile. So here's a real short primer on the Agile sprint process. And if you've seen software teams in action, you're certainly familiar with some of the terminology,

06:32 some of the events that I'll refer to here. Agile revolves around getting work done in what we call timeboxed sprints. So these are fixed development periods, usually 1 to 3, maybe even four weeks long. And each sprint cycle involves this set of repeatable events for planning and coordination and review. And these events have names like Sprint planning, a daily Scrum, Sprint Demo,

07:02 Sprint Review retrospective. The work is planned through what we call the backlog. And this is basically a prioritized list of jobs to do. And prioritizing the work of the backlog is the responsibility of the product owner. And who would typically work with product managers and other senior stakeholders? And then facilitating the work of the team and pretty much all the Sprint events is

07:34 a job of the Scrum master. And I suspect you're familiar with some of those terms. You've probably seen this in action, certainly on the software side. But if you're using Agile methods in hardware development or operational activities, then you're really at the leading edge here of Agile beyond software. And that's what I've been looking at for the past few years. So through this research and other activities, I've been able to work with a range of companies in

08:05 a number of different industries, including consumer electronics, telecom, automotive, appliance, even packaged goods and complex systems are learning how to use agile. And what I've found is that we don't need to apply Agile all in the same standard way. You see, there are no agile police telling us what you have to do it this way because that's the way it works in software. Instead. There are many ways to apply Agile because your process

08:38 and your challenges may be quite unique. So people ask, What have you learned by studying all these different kinds of companies applying Agile outside the software industry? What's the key to success? Well, I can answer in this one word adjustment. You see, some agile techniques don't actually require adjustment. So these are things like a daily meeting or a daily scrum or daily check in.

09:09 Look, I've never found a team that can't do that. I've certainly found many teams that don't do it. But there's no fundamental reason why you couldn't have a daily check in with the team. Right? Or retrospective. Having a look back at how did the sprint go and what could we improve and what works and all that. And these are techniques that are just easy to apply in a whole range of contexts. But most of the elements of Agile, I think can and should be adjusted to fit your particular context.

09:42 So here's the meat of my message for today. I'm going to describe three specific types of adjustment that I've seen and found can be really helpful. Three adjustments. So the first type of adjustment for Agile outside the realm of software is about the timing, the pace, what we call the cadence of sprints. So most software teams are actually fine with one week sprints, but that's just too fast for teams in other types of projects to make meaningful

10:16 progress. So use longer sprints. Even if the software teams are using one week sprints, the hardware teams could do something different. For example, in one project at Ford Motor Company, the hardware teams used three week sprints while the software teams stayed on the one week cadence, and then every three weeks they would meet up and have a joint demo. And one particular advantage for the hardware team, if they discover something in their sprint where they need something from

10:48 the software team, they can ask them for it and maybe the software team adds it to their back for the next sprint. And then before the hardware teams finish their sprint, they've got that useful input and they can actually use it right within their three week sprint. Another adjustment related to sprint cadence that I've seen make ads really work involves alternating between two types of sprints. So in engineering organizations that are not only developing products

11:20 but also supporting operations, this can be really helpful. You could alternate time periods. Alternate sprints between two types. For example, there's a technology based clothing company here in Boston called Ministry of Supply. And their teams will spend one week in a development sprint and then one week in an operational sprint. And in the ops sprint, they'll be visiting suppliers, supporting maybe a market launch,

11:53 handling their performance reviews, kind of all the stuff that gets in the way of doing the dev work in the dev weeks. And this really lets them focus on the development sprints. Okay, here's a second type of adjustment for Agile outside of software, and it has to do with setting goals for each sprint. So if you're familiar with Agile in software, one of the interesting practices is that teams typically will prioritize what features and functions and bugs to work on in each sprint.

12:26 Then they kind of roll up that package of work and say, That's our sprint goal, get all that work done. Well, the trouble is, in the long term, they may not be heading in the right place. And this has been a real problem in a lot of software organizations and most hardware organizations, I think, kind of have that problem even worse. So what they do is something different. They do just a little bit more long term planning. So so first what they do is they identify long term. What are our strategic goals?

12:56 Like what's what is the major milestone we're trying to achieve in this development? And usually that's something like, say, our product launch or next dev, next generation of the product. So they say, okay, we want to have a product release, say in Q3 or we have a trade show in Q1 and we want to hit that milestone. And then they decompose the milestone into smaller ones and then finally into a series of sprint goals. So they ask something like, well, in order to deliver this product release in Q3,

13:29 what does it look like to be halfway there? And and they have a time a date for that. And what does it look like to be 25 or 75% done? And then each of those goals is achieved as a series of several sprints. And this is the way that Agile works, particularly in more complex systems such as mobile robots, mobile robots at Ocado Technology, many of you have seen or telecom systems at Swisscom that I've worked with.

14:00 Okay. The third one, one more super helpful agile adjustment. And this one's more of a change of mindset. Okay. So you've probably heard that software teams aim to deliver usable code in each sprint. Well, the truth is they only sometimes do that. And really hardware development teams are not likely to be releasing a new hardware version into the field every couple of weeks. Right. Okay. So the adjustment we make here is to expect

14:33 a reviewable increment of work in each sprint, not a releasable, but a reviewable increment of work in each sprint. So, for example, at Bose in consumer wearables, this could mean that they'll build a prototype test and review a new user interface, maybe a particular feature on that prototype. So that's not going to be released, but it's something we can review. We can test. We can get feedback. And that leads to the next development sprint.

15:05 Another example, a company called Sigma, which is a global packaged foods company I've worked with on a particular snack food product using agile development. Each sprint has had particular goals, and these are things like extrusion tests, baking results, packaging, design, reviews of taste and texture. So the reviewable increment is the sprint goal, and this is what we would then demonstrate and assess in the Sprint demo and in

15:36 the Sprint review at the end of each sprint. Now, having seen this Agile transformation start to take place across a huge range of industries, something really struck me. So agile depends upon close collaboration within teams and also across teams. And collaboration today is based on a certain types of tools, largely cloud native tools. But

16:08 the interesting thing is you could implement Agile without cloud. And we've been doing that for a long time. But the reality is that teams today are working less in a co-located fashion and more in a distributed fashion. We've seen a big transformation of that, particularly over the last few years. And cloud based tools are ideal for remote work and for teams that are distributed across time and space. And frankly, this way of working was just not possible even ten years ago.

16:42 Even five years ago, the tools were just only starting to get really good. And today teams are benefiting from a wide range of tools that we've all come to depend upon. So tools like Jira and Trello keep us on track. Miro and Mural help us to collaborate. Figma Canva help us to be creative together. Zoom Microsoft Teams. These.

17:14 Let us have our daily meetings from pretty much anywhere we are. I'll show you a couple of examples. So here's the start of a daily meeting for an Agile team using Zoom. Love to see everyone's faces. Let's just jump into standup so we'll go over and do the regular review. So status update with actions as usual. Three questions. What did you work on yesterday? What are you going to work on today and what, if any, impediments do you have?

17:47 As always, keep it short, starting with Leroy. Thanks, Jake. So, okay, now, this type of daily check in would be a 10 to 15 minute meeting. And you know what? It actually works a whole lot better on video than it does face to face. I mean, it's simply less disruptive to everyone's daily work if we can have the meeting online. Now, since we're here at PTC Live Works, how about Cloud Native CAD?

18:20 So we all know that Onshape is the CAD tool that helps teams collaborate without the confusion of file versions. And we've heard about Creo Plus being released now and how it's starting to do the same thing. And this eliminates the barriers created when 2 or 3 or more people need to work on a model that's evolving, but really only one could edit it at a time. And now we all can. So Cloud Native CAD allows us to share these models, and sharing is important.

18:54 That means sharing with suppliers who are providing input to our evolving work, sharing it with customers or providing feedback, and any stakeholders. They could be on other teams. They could be senior managers, they could be outside. And we bring that feedback into the Sprint demo so that we can review the incremental progress. Now, I've just released a new paper. That's our currency in the academic world is we write papers and this one is with John Hirschtick here from PTC.

19:28 And this includes a summary of Agile. It's called Transitioning to Agile Development how to develop hardware like software. So the summary is really focused on, well, how did it revolutionize software and how do we adjust it for hardware? It talks about how agile development methods work and what are some of the benefits for remote collaboration risk reduction with each sprint incremental value delivery

19:59 in each sprint. Most importantly, it talks about these agile adjustments, how agile requires adjustments to suit hardware, project development, development constraints. It's also got a step by step guide toward the end toward Agile adoption. It has steps like start small, ask for help, get some training, get some coaching, make your project work and its success visible. Scale it up slowly.

20:30 Stay the course. And finally, I'll end with the call to action. Look, I really believe that we're on the cusp of this huge wave of agile adoption beyond software. I think it's going to make a difference in your process, in your in your your outputs and in your customers lives. So my message to you is this Learn about it, try it out, but stay the course. You know, your first agile sprint will feel a little bit awkward by

21:03 the time you've done five sprints or ten sprints, you actually get really good at it. It becomes normal. It becomes a process that you'll like, you'll use, and you'll never go back. This can be a thrilling journey, so give it a try. Thank you very much.