Welcome back to this course series on becoming a certified scrum master. In this course, we are looking at scaling Agile solutions and team of team solutions. This course and this series is a presentation of Learnquest. It's been a myth for a long time that Agile cannot support hardware development, software, hardware or device development. Agile practices actually got their start in hardware and then those practices move to software product development. Lean, which is an agile methodology, was initially developed and first used in automobile manufacturing at Toyota and other automobile manufacturers adopted the practices. Lately, the emphasis has been on software development. However, all the same Agile practices apply to hardware and device development as well. The critics are right in some cases, there are challenges with device development. Software development typically progresses faster than hardware development. This makes it more difficult to align, more difficult to integrate. Hardware emulators to a certain extent, it can help software teams validate their products and the way they run on hardware. Essentially, the device hardware can be virtualize on an ordinary computer PC and then that software can be run in that virtual environment to validate the features of the software, that works to a certain extent. Security is also emerging as an increasingly large issue with device development. A lot of times it's overlooked, security is overlooked. A lot of times there is no log in and there's no way to validate users with device development. When specialty devices are built, there's so much work goes into building the specialty device that there's often not enough bandwidth to investigate security issues, so security still needs to remain a major focus for teams that are building devices or building specialty hardware that run software. In the Agile world device development is done in the program alignment where we implement a program approach, meaning that there are several teams. There could be a specialty team or specialty teams for software. There could be a specialty team or teams for the hardware, and they need to align and synchronize. All of the agile practices are here, we have the backlogs, we have the sprint planning, we have the the sprint reviews, the finished work, the daily stand ups, the scrum master, the product owner, all still here. We also have the customer that expects a working device. When we align in this manner, obviously the teams need to plan together and integrate often. Can't say it enough, the Agile manifesto says that, "The working solution on the device is the true measure of progress." That working software hardware solution, that's the true measure of progress and that's what the customer is going to evaluate. We've got to come up with the teams that will pick the practices for the proper alignment and integration and we need specialty teams to help us with integration, to help us work for and with solutions for this type of development. There may not be an out of the box solution, we may have to come up and quite often that's the case, we have to architect our own solution. Again, pace is a big issue and progress, no question about it. A hardware development does proceed slower and defects in hardware are more difficult to detect and take longer to resolve. Similar to software, hardware teams need to architect a solution for building hardware incrementally. There is a practice called continuous manufacturing. Now, this doesn't mean that every day there is a new version of the hardware that may not be the case. Hardware teams may need to practice what's called iteratish and continueish with the 'ish', meaning that the software teams may need to use emulation during times where they have not yet delivered the next version of the hardware. Again, we need solution teams and engineers to think about how to architect a solution, think out of the box. Think of a way to be able to allow software to progress to a certain extent while still delivering the features of the hardware.
