In this video, you'll learn the three core elements you need in order to start Scrum in your company. First, strive to create a working product every sprint. Working product doesn't mean the finished product. It doesn' necessarily even mean something you want to release to customers. Rather, a work product is some usually small part of your product that is done. On a software product, done means that design, coding, and testing are all complete. Hold on a second before you tell me this is impossible and that many of the features you build are too big to fit within a few weeks sprint. Remember I said we don't need to be creating the finished product each sprint? I get it. In many cases, that is possible. The goal is to create a working product and then add functionality incrementally each Sprint. Let me give you an example. Suppose you're building a word processor and it doesn't yet support tables. In the first sprint, you add very basic support for tables. And I mean very, basic. All tables must be two rows by two columns. Columns cannot be resized. You can't add headers or footers. you can add shading to cells. Can't change border styles. This is pretty basic, so basic you would never ship it that way. Very few of your users need only 2 by 2 tables without headers, or shading, and that use the default border style. But this is, sure, a nice step forward. It's a working product, even if not one that is worth shipping yet. And if you keep building the product in this manner, eventually you have enough to give sellers show to users. And you often get there well before you've added everything. This allows the team and its product owner to get early feedback on what they're building. That early feed back can be used to guide future decisions about what functionality to add and when. Second, inspect and adapt continually. Scrum is about continuous improvement. Therefore, Sc rum teams inspect an adapt both their product and their process every day. By inspecting and adapting the product, I mean the Scum team, the developers, and the Product Owner are constantly assessing whether they are building the right features. Returning to the word processor example, say the team has a plan in mind for how they'll add support for tables. They give a quick demo of the planned functionality to a few stakeholders, and the stakeholders don't like the user interface. The team and product owner would consider that feedback and quite possibly make a change to how the support tables By inspecting and adapting the process, I mean the team is routinely assessing how they are working together and especially their use of Scrum. Let's suppose the Team is struggling to produce high-quality code within a sprint. To improve, they may decide to start pair programming or taking automated testing more seriously. When I say a team should inspect and adapt their product and their process daily, I don't want to imply that there is no continuity in what the team is building or how team members work together from day to day. Often an opportunity to improve will not be put in place until the next sprint. That's fine. But team members should have their eyes open to opportunities to improve the product or process at all times, even if every improvement is not immediately put in place. Third, trust the team. Trusting the teams is key to succeeding with Scrum. A Scrim team is built on the idea of self-organization. This doesn't mean that a Screm team works without boundaries. There are confines that the a team must work within. However, a scrum team should be trusted with making a lot of the day-to-day decisions on how they will work. Many teams form working agreements. The team collectively decides on things like, what are our overlapping office hours with a distributed team? Do we want remote team members to participate by video? When can the team work from home? Creating a culture of trust is vital to success with Scrum. Scum itself is easy, but to be successful requires the entire organization to to disciplined and dedicated to learning a new way to work.