Onshape: Combining Additive & Agile Methods for Rapid Robotics Innovation

00:00 My name is Matt. I have a pretty cool job. I work for Ocado Technology and I lead the engineering teams that develop our automated storage and retrieval system. So I'm going to show you what that looks like at the moment. It's a large robotic system that we use for fulfilling warehouse orders and we're specialist in the grocery space. I'll give you a bit of the story in just a moment. The the backdrop to the Agile stuff that we're going to talk about today is this machine you might have seen this in Jim's keynote yesterday.

00:33 This is the 600 series bot that we are developing at the moment. You will probably pick up on the fact that I love this machine, that that might stand out in the talk, but it's not actually the topic of today's talk. We're going to talk about the story of the development and how that led us to innovate in the Agile hardware space. So how we built our methodology, our ways of working and our team. Okay, first and foremost and buzzwords, agile , hardware development.

01:05 We've we've all had the, the groundwork laid on that one, deployable prototyping. So we'll be talking a lot about 3D printing as well today. The notion of deployable prototyping is if you are using additive and you have your own factory and that matches what you're going to produce your product with when you manufacture it at scale, then all of your prototypes are actually the real thing. So you have something which is a proper representation of your product and that's quite powerful. We're going to talk about industrial DevOps, which is us shamelessly pilfering concepts from software development

01:37 and turning them into new ways of working for hardware and time to part and how that helps with time to market. So lots of things that help us move faster in developing a complex product. But first and foremost, who are Ocado? So Ocado.com started in the year 2000 over in the UK and we were the first people to figure out how to do online groceries properly. Essentially, we scaled up a large organization serving the UK market

02:08 and we have become exceptionally good at the automation needed to make that possible. And grocery is a uniquely difficult logistics challenge. So if you think to the last time that you ordered something from the Internet, in fact we have a little bit of fun with this one. By a show of hands, who has ordered something on the internet before and had it delivered to their house. So if you keep your hand up, think about the last purchase that you made and how many items were in your basket.

02:38 So if you keep your hand up, if there was more than one item in your basket when you placed that order, I would say we've lost 80% of the room there. So more than five. More than ten. Now we've got one left. Was it groceries by any chance that you ordered? Yeah, fair enough. Okay. Lots of screws is also a fair game. A typical grocery basket can can be in the order of 50 items. So just in terms of the actual amount of aggregation of stuff you have to do,

03:10 it's a really difficult challenge. And you add on top of that the need to handle ambient and chilled and frozen goods. You have complex food tech restrictions that say you can't put the bleach in with the strawberries and don't squash the eggs. So you have to be really careful in your packaging order. You then have a customer that expects it to be delivered in a specific time window because they need to be present to receive the goods so that their ice cream doesn't melt and they can put it away. And you have to do all of this while competing with the bricks and mortar business where the customer does the picking and the delivery for you

03:41 for free. So margins are absolutely razor thin. And to be profitable in this space, the efficiencies that you need to get in the warehouse are incredibly important and we've spent the last 23 years getting exceptionally good at that. So we are grocery by birth, but we are now more of a specific provider and we make very, very efficient fulfillment machines. So this is what one of those machines looks like, zoomed out. So this is our simulation system that we use for designing algorithms and sites.

04:14 Each of the little colored boxes moving around is a single robot. Its job is to pick up a box and put it somewhere else. They're all colored by the different types of tasks that they're performing, and you can see the paths and the plan all laid out in front of them. But the point is, these are large scale systems. We can have well over 1000 robots deployed in a single instance of this system. So that's what it looks like algorithmically in the real world. It looks like this. So that's not CGI. This is footage of one of our facilities in the UK.

04:44 And the machine that you see moving around is our 500 series bot. So this is the workhorse of our smart platform that we use for delivering groceries in the UK and also delivering our platform service to other grocers around the world. We have many thousands of these in operation all over the world and this machine is exceptionally performant and reliable. It is, as I say, the workhorse of our operation. So you could perhaps look at that and say, congratulations, give yourself a pat on the back. We're done. We've got a good machine and it works.

05:16 But if you spotted the small segment from our CTO James Donkin yesterday, you might have heard him mention that we don't typically like to stop at good enough. We would like to see if there is more that we can do. And we're always looking for a fundamental limitation in a system or something that some constraint that we can try and break and to make a system like this really, really reliable. You do a bunch of engineering and it looks like an industrial machine, right? You all have seen other pieces of automation. This would fit in in a room with other devices like that. It's also pretty heavy.

05:51 There's a lot of there's a lot of stuff in a machine like this. This weighs on the order of 170, 180 kilos for one of these machines. And that drives some challenges in the rest of the system because it drives on a big grid and that grid is on big, long legs. And when we accelerate, we're pushing lateral forces into the grid and we're giving that grid a really hard time. So we have to put a lot of bracing and support into that structure to make it survive and have good enough fatigue life for this type of system. And then that needs to be bolted really firmly into the ground.

06:21 Then you drive constraints in the concrete slab in a facility that you need to use. And maybe that means that some existing sites aren't available to you, or you would have to retrofit that concrete at some significant cost. So the fact it's big and heavy is a challenge and something that we'd like to have a look at. So so while this was happening, we had a small team over in Stockholm who were looking at whether we could make a much lighter machine. And when I say much lighter, I do not mean a 10% saving. I mean going from about 175 kilos down to 50.

06:52 So we're talking about less than a third of the weight of the preceding machine, and that's what the 600 series is. So. Over in Stockholm, work begins. We have a tiny little crew, a couple of couple of people that we've hired out of the local tech university, and we begin messing around and seeing what's possible. We've established that we want this general framework. If you look in the middle here, you can see some carbon fiber tubes and they're connecting some 3D printed elements to make this sort of skeleton that

07:24 we can hang all of the mechanical parts of the machine off. So we have a concept. We have some clever people, we've bought some 3D printers, We start making parts, we put everything together, we find out it doesn't fit. So we get the angle grinder out and make some adjustments and then put it together again. And eventually we land on something that has some new actual mechanical subsystems inside it. So this is one of the systems for lifting up the wheels because we drive on a grid system and we have to change between the X and Y axis when we do so. And I included this little clip here because this is an important type of test.

08:00 This is a non scientific test and it is a really, really useful compliment to very, very rigorous engineering. So we have found it powerful to be able to do both because this lets you throw away bad ideas quickly. And there is another set of rigorous tests that you need to do to prove that the real idea is good. And they are quite distinct and it's useful to have both skills. So this is vilhelm here giving our direction change mechanism a hard time and seeing what the motors can handle and seeing if we've got any easy to break parts in our machine, let's say.

08:33 So from there, our first prototype starts to come together. At this stage, we've established that we would like to use topology optimization to see what gains that can give us in driving even more weight out of the system. So if you've not seen this before, this is the process of defining a block stating what the load cases will be on that block and how hard its job is going to be, and then letting an algorithm remove material until you've left just what is needed. And that lets you drive material costs down and get the weight of

09:04 the machine down. But we hadn't hired the fabulously clever PhDs at FX to actually do the topology optimization yet. So what we've got here is those starting blocks that haven't been optimized, but you print them anyway and stick them together and make a machine because we can do that later and it doesn't matter. We're just prototyping. So this was our first ever machine that was sort of a full form factor, proper version of our XY and direction change. So it doesn't have any mechanism for picking up a box. But we're looking at how the chassis works and we call this Minecraft bot because it's made out of big blocks. So it drives for the first time.

09:37 Now bonus points to anyone who can spot the input from our IP team. We're not happy to show absolutely everything about our bot publicly at this stage, but here you can see we have a very first demo, our first prototype. We don't have a grid, we don't have any representative system. We're a tiny secret team in Stockholm, but we can drive it around by borrowing the event space in our little office hotel in Stockholm. It's clear, though, that we're starting to outgrow our facility, and we're going to talk more about that in a moment. So we think we are on to something.

10:10 Is this the stage where we have to look and say now we have to talk about the real proper product development? We need to move away from these prototyping tools and figure out the manufacturing strategy. Or do we want to stay with 3D printing and take that all the way to production, even though it's typically not that mature as a technology for manufacturing today? So we decided to stick with additive, and there's a few reasons behind that. Now this is specifically about our product. So while I do think there are lots of other products where you'll see this same thing

10:42 happen and it's going to be really exciting, I don't know how broadly you can apply this. Our parts are a certain size that are okay to 3D print. Our low cases are a certain we need certain stiffness and certain strength in the materials that are okay to 3D print in plastic. So we're in a bit of a sweet spot, but for us, we had a look. First of all, the topology optimization we've been working on, especially this large part on the left that can't be manufactured any other way. You can only make that part Additively So to realize these weight saving gains,

11:12 we were for at least some of these specialist parts definitely going to have to stay in the additive space. We also have a big range of sizes of part and this is really interesting for the economics. So the part on the left is on the order of a kilo and the part on the right is on the order of one gram. So there's three orders of magnitude difference in the size of those parts, but we can throw them all in the same printer. So by the time I've bought and started to amortize a large industrial 3D printer,

11:42 I can print this big part and I get the little part effectively for free, right? Because it's just a very, very small incremental material cost and I'm already paying for the large asset to do the work. It's actually to get a tiny bit technical for a second, even helpful to have the little part because it helps balance out the thermal mass in the build chamber, which is really important for driving precision in the 3D printing process. So what we found was that for our product going additive first on

12:12 the design was giving us new benefits and it was also pretty good economics for what we were trying to do. We didn't need to make parts in the tens of millions. We weren't making fidget spinners, we were making a high value machine. So there was a great case for pushing this all the way. But is the technology ready? Is the next question you naturally ask yourself. So here is Gartner Hype Cycle. We've probably all seen one of these before. This is everybody getting excited about something. Everyone realizing that all the articles they read in the press were nonsense.

12:43 And then eventually the thing becomes useful much later than everyone said it would. So if you look at something like this and you check all of these different things that Gartner have pointed out a few years ago and say, well, what are we doing? Well, here's the stuff that we use or the stuff that we do. So 3D printing in manufacture. Yep, that's our plan. Great. 3D printing. Tooling. Jigs and fixtures. Yep. Fantastic. We're doing that as well already in our prototyping and enterprise 3D printing. I don't know exactly what that is, but if it's not what we're doing,

13:14 it's probably not even a real thing. So what about the machines? We use powder bed fusion primarily. We also do a lot of prototyping with extrusion and jetting all of these technologies. Now we're broadly on the right hand side of this graph, so that's great. We're at least past peak hype for all of these things so we can make a sober assessment of them. But perhaps more interestingly, this is quite an old table, right? This is missing an overlay, but this is five years old, so it's pretty clear that we could be at the point where we've reached maturity here

13:50 and we might just need to be the first people to do it. And we're okay with that because we want to have a moat between us and our competitors. And that sometimes means pioneering something and we back ourselves to be able to deliver really complex high tech things as a business. So we made a decision that we were happy to scale this. We're going to build some of the largest printing facilities in the world and we're going to make the most additive product in the world, probably. So that's the product, that's the background. And we are now the small team in Stockholm.

14:21 We're starting to get excited about building this thing and we think we have a strategy and we think we've got some good concepts. So there's myself and six engineers, six exceptionally clever people, largely out of the university in Sweden, but also some international folks. And the next thing we need to do is move because we have outgrown our one room office where we've been messing around. So first and foremost, what are we trying to do when we move? What do we actually need? How does our team operate? And what's good about that?

14:52 Well, we start by looking at the iteration cycle. So most things look like this, especially for physical stuff, right? You design something, you buy the stuff, put it together and see if it works. And you do that lots of times until it works. The problem is that if you scale this for time, it looks a little bit more like this, right? Buying stuff sucks. It takes ages. It's complex. If you have to customize things, you have to do complex development programs, you're going to have legal agreements. It's just a pain. So we really, really prefer to change it to something like this.

15:25 How much can we just make ourselves? And this is another area where additive really shines because we can put stuff in our printers we use. Most of the complexity of our product is in the 3D printed parts and that can drive how we design the facility that we want to move into. So this is a little layout of our ground floor space in a beautiful old shipbuilding shed that we found on the waterfront in Stockholm. A couple of people in the room have been there. They can vouch for how cool it is. We have to decide how to lay it out. So first and foremost, we need some additive stuff.

15:58 So over there, all the different technologies I described, that's the powder bed fusion jetting filament SLA. We've got a little bit of everything. You can squash it all into what's probably about 30, 40m² over there and you have your own factory additive is awesome. It's incredible that you can do that in the space that it's using for the other half. We're going to have the rest of the prototyping capabilities as your laser cutter, your bandsaw, all of this kind of stuff, soldering irons and oscilloscopes so that you can work on electronics. It's just the other bits of hardware development.

16:29 And then we have a small test area and we've got some tables to assemble on. And the fact that those are tables is quite interesting because it's another benefit of a lightweight machine is that you don't need any special handling tools to move these things around or work on them. We just take parts out of the printers and build them on a table. It's kind of like advanced Lego techniques. So then upstairs you have all the clever people and me. I get to sit and watch them and that's it. It's about 700m² to do all of this development for

17:01 a team of what was then around 20 people. So that's what we've moved into and we're building it around this iteration cycle and trying to set ourselves up to be able to do everything in one space. And I was reflecting as I was watching the keynote this morning on the coffee shops during the Enlightenment and how you have these multidisciplinary spaces where you can do everything together and all the ideas are in a melting pot. And I guess that's a hint of what we were trying to put together when we were thinking about this. This site. So we were pretty keen to get in and we moved in while

17:36 the building was still being renovated and started building our grid and started trying our machine out on an actual grid for the first time. I'm afraid I can't show you exactly what the machine looked like on that day, but this was the sort of first steps into having some proper testing facilities. A really, really exciting day for the team. And this is what the team looked like by the time we were settled into that building. So you can see the different crafts there, you can see the Multidisciplinarity. We've got everything from the CAD through to how we build it, how we figure out the assembly instructions, how we figure out how to measure it,

18:08 how we're going to get the electronics in, how we're going to program it, and how we're going to learn about whether it works or not. We're doing all of that in one place, so that's great. At this stage. Our CEO paid us a visit and we had the sort of turning point in any project that you sort of want and fear in equal measure, which is that we get told, Yeah, okay, let's do this. So we stop being a secret R&D team at this point and we rename from our little project codename to the 600 series and we say, This is Ocado's next production machine.

18:39 So suddenly you're on a journey from your little prototyping team to trying to build a large organization that needs to deliver a project. So how are you going to do that in an agile way? That's what we're going to talk a little bit about now. So as I mentioned, team status 16th of June 2021, on the 17th of June, that organizational chart doubled. So we seeded teams in the UK. We mirrored the org structure. I then had a head of product counterpart to work with,

19:09 so I was the head of engineering at the time. We had project management craft come in, which was a revelation to us as people who had been very frustrated needing to buy their own stuff and look after their own finances and everything else. Good project managers are wonderful. And then most importantly, we actually had a deadline. We actually had to get something done now rather than just proving we could do cool stuff. So let's look at some of the fundamental differences in the organizations before and after. So we've gone from 20 ish people in Stockholm to 80 directly working on

19:44 the bot itself and then another 80 plus working on everything else around it. So that's the firmware platform that's shared between the Bot series, that's the recovery tools, that's all the maintenance operations, that's everything else that goes into actually putting one of these products in a production facility. So lots more people. We're also suddenly in three development centers. So we've gone from being a Stockholm team to a Stockholm and UK and Bulgaria team. That means we're in three time zones now, so we've got to figure out how to navigate that.

20:14 And most importantly, we actually have to have this thing manufactured at scale. So we have to turn it into something which can be contract manufactured with fixed instructions by less skilled labor than you have. Right? Because we're using highly skilled engineers to make these machines and we've got to transition towards something that we can do by the thousand. Okay, so quick pause. So have a think about the way that you collaborate with your teams at work today

20:45 and think about how it looked in 2020. Now, Jim mentioned this in his keynote during the pandemic. We got a lot better at this, so video conferencing became much better. Online whiteboarding tools became much better , chat tools became much better. And we have been big, big beneficiaries of that change. And a lot of what we're going to talk about, I think, would have been an awful lot harder if we tried to do it five years earlier just because a lot of those online tools wouldn't have been there to support it. But they are there now, and that's worth reflecting. Okay.

21:19 So we would like to figure out how to capture the magic of this wonderful prototyping team that we had in Stockholm and do the same thing with a bigger group. So what are the bits of the mindset that we want to bake in? So first of all, we love physical testing, right? We love get something in your hand, build a prototype. You will learn more from that than you will sitting around thinking about it for hours. Again, it doesn't remove the need for doing rigorous engineering, which we've also called out here, but it is a very,

21:51 very powerful tool and something that our additive approach we've put front and center and we want to make sure everyone does it. So we love physical tests and printing is free. Never ever think about what it costs to go and print a prototype. If you think you're 80% done, print it on a Friday so it's ready for you on Monday. Even if you find out the other 20% was important at the end. And then there's a last point here, which is where our methodology differs slightly, or at least it's what drove us to build a methodology that differs slightly,

22:21 which is trying to have everybody feel ownership over every aspect of the product. And this is again a product fit thing because we're not making the Volvo trucks that we saw yesterday, right? We're not making something that is such a large, complex configured item that it's basically impossible for any team to feel like they understand every part of it. Our machine is complicated, but it's small enough that we can take this approach, and that's what we've baked into our methodology. So we'll talk about that in just a moment.

22:51 It's really good for driving ownership and accountability in the team if people feel that way, though, rather than it was those guys fault. So tooling that we use is relevant. So this is all the all the good stuff that I was just mentioning. So we love Slack. Use your favorite chat tool, but be good at using it. It's really, really important. We love Onshape. That is why we're here today. It is fundamentally brilliant at collaboration. That's the most important thing about it by far.

23:22 It's got lots of other good things, but if you go international, then it is an absolute game changer to be able to collaborate so seamlessly. We use Jira just to have a good project management tool, make sure you know all the things you need to do. Have something for collaborating online on some kind of equivalent to a whiteboard. When you can't be in a room with someone. And a key one for us is actually making video. It's really, really easy to make video now and it's a great way to share complex technical concepts. It's also a great way to share project updates and other things,

23:55 but we do actually a lot of asynchronous communication by just recording a video. I found this problem with the machine throwing it on Slack. It is much, much quicker and much less effort than writing reports on things in a lot of cases. So most important thing behind all of these is that it's collaboration first. So for any large organization you will not get linear scaling between the number of people and the amount of stuff that gets done. You don't ten x an org chart and get ten times the productivity and all of

24:26 the losses in that. Are people not being able to do stuff with each other as well because the thing is big. So the collaboration tools are the most important thing to get that efficiency up and get everyone working together as well as they possibly can. All right. So some techniques. So this is where we get into more of the industrial DevOps stuff. So everything here is stolen from software and it is surprisingly novel in the hardware space. I'm a software engineer, so I have fallen into leading a hardware team and this is all bread and butter

25:00 for me, but was apparently novel in running a team the way we do. So automate as much stuff as you can. Doing the same thing lots of times is boring and usually not the most effective approach. Equally, release your product as often as you can, so build your complete manufacturing pack and have everything that is required to make a full real version of the product ready at the click of a button, which is linked to the first point. Releasing is hard in hardware, but if it if it's hard,

25:32 you should do it more often because it will force your hand in making the automation to be better at it. Pairing up is a really interesting one as anybody in here ever done pair CAD before. We have one, two, three. Okay, That's awesome. You can tell we have some Onshape people in the room. This is so standard in software that it's amazing people don't do it more in mechanical design. It is default working practice for us in the 600 team and we do

26:02 a huge amount of pair coding and single documents live in Onshape from people in different countries. And again, it's just a standard way of working. It makes better products. People should do it more and then build tooling if you have to. So I have a specific example of this one. This is one of the integrations that we've built. We do our topology optimization tool called in topology. The specifics of that tool aren't the relevant part here, but the ability to use a little bit of software capability to link stuff together

26:33 is really powerful. So we can write some feature script in Onshape to define the load cases on our parts. We can then hit the API and Onshape to extract all the geometries and load cases together and push them into this topology tool. We can then write Python scripts that will run that in topology tool countless times to do a design of experiments and build up a Pareto front of the trade offs in the parts. ET cetera. ET cetera. And we can then automate the pulling of all that data back into our main assembly so that we can finalize, clean up the geometry with some booleans,

27:04 get it ready for 3D printing. So it's quite a lot of work to build something like that. But we want to iterate our entire product quickly and it's got a bunch of topology optimization in it. So we can't just stop for three weeks every time we make a change because it takes that long to topology optimize. You have to automate it so that you can keep up with your own desire to iterate the product. We also automate the generation of manufacturing packs, so we go and talk to our contract manufacturer. We find out all the specifics of exactly how they need to consume data, and then we build a little bit of tooling around the Onshape API to extract everything

27:36 and exactly the format they need. And it skips out a bunch of complexity in the interim. And I mentioned CI CD up here as well. This is another software term. So this is continuous integration, continuous deployment. This is stuff that people do in software tools all the time. I should be able to make a change and then everything downstream is automated and I get the complete artifact at the end. So whether that's a piece of software to deploy or in our case, a manufacturing part that completely defines your product, that should be a button click, and you should have just about every step of that automated. Okay.

28:08 So lastly, the process that we actually follow. So what does doing an Agile methodology look like for the team that actually execute it? So this is a little snapshot from one of our Miro boards I mentioned earlier. Insert your favorite whiteboarding tool here. It doesn't matter which one the. Ability to get an entire department of 80 people to come in and do something like this is really cool. So every Monday morning people will come in and they will see something like this.

28:40 Each one of these. This is all pretty standard stuff. If you've done any project management before, if you worked in Jira or whatever, this is basically a download of our Jira board. So there's the title of a problem we'd like to solve or a piece of work that we'd like to do. There is why we want to do it. That's the product angle. There's the definition of done. So we've got five deliverables over here in these yellow boxes and then we've got the types of craft required. And then every Monday when we come in, sorry, every third Monday, when we come in on a three week sprint, people will drag their name onto the product where they think they will add

29:13 the projects, where they think they will add the most value. So we don't have teams owning a specific subsection of the machine. We don't even worry about having teams as a distinct atomic unit of work doing. We just allow our engineers to figure out what's important and go and assign themselves to it. So we have a self forming team. We do some work for three weeks, we demo the deliverables at the end and then the teams dissolved and we start again. And this is great because it is implicitly multidisciplinary,

29:45 so we don't need to say, Oh, I better get the mechatronics team to do that, but we can't because they're busy over here. You will just naturally find the mechatronics team split themselves between the bits of work that need doing and apply their capabilities as needed. We also have this section on the right. So these these golden tabs at the bottom here, they're folks from other departments that are coming in who were involved in that project as well. So we say we need a bit of help from you guys. Can you come and get involved or we're going to put you in the advisors list, which means you're invited to the planning meetings, you'll see the outcomes, etcetera,

30:16 etcetera. So this is a distinct piece of work to just solve a problem and it is not linked to an organizational unit. So the next step from that is zooming out on that board. So that little purple box you saw is one of these tiny purple boxes up here online whiteboarding tools are great, infinite canvas, etcetera, etcetera. So we've got 12 projects defined for this particular sprint. We've got all of the team tokens on the side. So that's where you find your name and you can drag it onto the piece of work that you're going to do.

30:47 We've then got planning spaces for all of those projects down the right hand side, so each team will just go and have its kick off meeting and put all their planning straight into the Miro board. And then there's a place to capture the retro . At the end of the sprint. Was this project well defined? Were the deliverables any good? Did we have too few people on it? That's the opportunity for the engineers to beat us up a bit. If we haven't done a good enough job at defining those pieces of work that need doing so. One nice benefit of this is everybody sees everybody else's plans,

31:19 which is good just for general visibility, but it's also good because they all steal each other's techniques in how to do good plans. So we have a mixture of coordinators in the project. Sometimes it's an explicit project manager and sometimes it's one of the engineers. So everybody gets a little bit better at project management because they see what good looks like in that space. And then because you've gone all the way from the definition of the project through the plan with the retro, and we then record the demo video that we do at the end of each sprint and dump it in this board as well. You now have a complete artifact of that total sprint in one place that you can go

31:51 and reference any time you need to. So if you're a new starter, for example, and you want to know why we decided to do something, you just go to the sprint where the work was executed and watch the demo video and you're going to have it shown to you just like that. It's really, really easy to track the development of the program through these boards. Okay, so that's all pretty cool. It doesn't solve every problem. We still have to buy motors and batteries in our cases and PCBs and can't 3D print them. They are very,

32:21 very difficult to get hold of and have been for years now. I'm sure a lot of you who have been involved in some of that same challenge and as I've tried to point out as well, a lot of this is specifically designed around our specific product. So we have got a lot of things here where we have optimized our organizational structure and ways of working for the thing we're trying to build. And I think if you were going to take one thing away from this, it's that that's the most important bit. So a lot of the agile general principles apply.

32:52 You want to break things down into small chunks of work. You want demonstrable value at the end of each sprint so that you can see that the product is progressing. You don't want to copy and paste our Miro board and do exactly the same thing because it won't necessarily work for your team or your product. But these ways of working are possible and they drive huge value for us both in terms of how lean we are in terms of the engagement of our engineers and in terms of capturing the multidisciplinarity that we wanted to protect in our org structure as we grew.

33:24 So all of that has allowed us to go from this machine, which was the 602 generation machine. It's the one that we saw in the video in Jim's keynote yesterday to. Drumroll, please. This machine that I can't show you. What I can tell you about it is that it doesn't have a single printed part in common with the 602. We had a look yesterday in the Onshape model. Every single one of them has changed and in fact,

33:54 most of the off the shelf parts have changed as well. So I think the drive belts are the same. There's probably 1 or 2 carbon fiber tubes in there that are the same length they used to be and a couple of other bits. But even though it's the same bot, it does the same job and you can see how it's a natural maturing of the product towards something that's ready for its industrial environment. It is completely different and that wasn't difficult to do with additive and that's why we love it and that's why we have built our entire team around leveraging the speed that that brings us.

34:25 And that is the story of how we have built our methodology. Thank you very much.