Agile & Scrum for Beginners

1. Introduction: Hi, I'm bad. Hell. And this is agile and scrum for beginners. Since 2010 I've been broking as us grand Mazda and an edge I coach for banks, insurances, publishing houses and software development firms. And what I've seen in their time is a lot off interest and excitement about edge of software development. What I've also seen is sometimes confusion and misunderstandings about what ej I really means. So what does edge I really mean? This is what this class is all about. What are the core values and principles that make up in agile mind set? What are the benefits and also potential pitfalls off working in an agile fashion? And I will also talk about this Graham framework, which is probably, at the moment, the most popular framework to put the agile ideas into practice. Angel is really about learning and improvement. So I'm really interested in your projects. Make sure to post them toe the project gallery and also please, right a review and give me feedback. What you think about this class? This would be very valuable to me. Thank you 2. What agile is about: What is Angel about? To answer this, we need to go back in history. In 2001 17 software development experts met at a ski resort, and obviously they went skiing. But they also created the manifesto for edge of Software development, and that was the moment that the term Edgell became known in software development. The text off the Edge I manifesto is quite short, the authors write. They are uncovering better ways to develop software better than what better than the heavy evade, documents centric process off the nineties that also focused little on the people actually doing the work. Instead, the authors write that they have come to value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan and why there is value in the items on the right. They valued the items on the left more apart from this text. There are also 12 principles in the edge on manifesto, and we will talk about all of this stuff in the upcoming videos. So to give you a summary what Hegel is, Angela really is a mindset based on the values and principles off the edge, I manifesto. It is about delivering software frequently and satisfying the customer by incorporating the feedback. It is about continuous learning and improvement together with the people in your team. And if you do it right, it is fun. What? Hegel. It's not. It's not a fixed process, method or methodology. Some people talk about the edge I method and what they really mean. It's graham. But scram is only one way to realize the agile values and principles. HIV is also not something you can impose on people relies on people being motivated by themselves and also agile is not a magic formula for success. You still need to build a software that people really want and need. 3. Agile values and principles: Let's have a look at the edge of values and principles in detail. The first value pair is individuals and interactions over processes and tools. The problem is processes and tools are optimized for recurring activities. So, for example, if you're baking a cake, you can always follow the same steps, and it will produce predictable results. But software development is full of surprises, and right now only humans are good at dealing with surprises. So the solution, the Edge I principles proposes work together. As a team. The team should consist off intrinsically motivated people. It should be self organized, so a Children depend on direction from outside or control the business. People and developers should talk face to face every day, and the rest off the organization should trust the team to do the best work it can. Let's have a look at the next value pair working software over comprehensive documentation . The problem with documenting too much up front is when the refinements change frequently. You need to redo the documentation very often, and that's not what the customer pays you for. The customer pays you for the software because she can use the software so the solution. The A child principles proposes. Keep it simple. Made working software the primary measure off progress focused on that and document only what's really needed. Let's have a look at the next value pair. Customer collaboration over contract negotiation. The problem with contracts is that they try to predict what the product will look like at the end off software development. But requirements often change once the customers HEASTER software, so feedback from the customers really essential to build a satisfying product. So the solution the Edge I principles proposes. Deliver working software to the customer early and frequently gather feedback. Incorporate the feedback into the software and by doing that, make the customer happy. And if you deliver working software frequently, you can turn customers into paying customers early, and your company can start earning money earlier. Let's have a look at the last value pair responding to change over following a plan. The problem is, changes are often seen as bad, but really they can be a competitive advantage. And when requirements change frequently, the original plan will no longer be valid and sticking to it the cause, problems and confusion. So the solution the edge of principles proposes. Make change the norm. Welcome changing requirements even late in development for competitive advantage and reduce the impact a change has on your development process. For example, keep your process is simple. Leave out everything unnecessary and automate as much as possible, maximized technical excellence like test automation and refectory. And if you want to read the values and principles as they are stated in the agile manifesto , here are the links. 4. Scrum in a nutshell: scrum is a popular framework for putting the agile ideas into practice. It only consists off five events, three out effects and three rolls. Let's have a look. Scram can be used to develop any complex product, including software. You repeat the following five events until your product reaches end off life in Sprint planning. You plan the next sprint, which is a fixed time period off at most four weeks. In the sprint, you work on the product increment. For example, you add features through the software or change existing features in the dailies Graham, which is a daily meeting off at most 15 minutes During the sprint, you monitor the progress and identify impediments in the Sprint Review. At the end. Off the sprint, you demonstrate the product increment with the stakeholders and get feedback. So, for example, you demonstrate the working software and in the Sprint retrospective, your team reflects on the process and the collaboration during the sprint and agrees upon and tracks improvements. There are three art effects and scrum the product back look, the sprint back look and the product increment. The product backlog is an ordered list off things known to be needed to be done for the product, for example, refinements, fixes and so on. The product backlog changes all the time. During product development, new items get added, others get removed. Only the items at the top me to be detailed the items at the bottom of coarse grained ideas for the future. The higher and item is up in the product backlog, the sooner it will be realized. The way this works is that during Sprint planning, the developers pull items from the top off the product oclock into their sprint back look. They also add tasks for example, create control a Class X. Then they turned the sprint back look into a potentially ship herbal product increment. That means that if business decided to ship the product, it could. For software, that means that the product increment is integrated and tested. There are only three roles in scrum. The product owner is the responsible person for the product and its back look. She make sure the product has value for the customer and orders her back look accordingly. She's also responsible for the quality off the back look, items and the availability off the back look to the stakeholders she can ride the back look , items herself or delegated, but she is the one who is finally responsibility for the product back look, the developers include everybody needed to actually build the product and software development. That means people with design, programming and testing skills, among others. The developers are the owners off the sprint back. Look, we haven't talked about the scrum master so far. She is responsible for the effectiveness off scrum in the team and organization. She helps the team remove impediments and sures. Graham is implemented properly and coaches people in the organization about scrum and together the product owner, developers and scram Master formed the scrum team to summarize. Graham is a framework for complex product development. It only has five events, three artifacts and three rules. That makes it easy to learn, but it's still difficult to master and practice. You need to fill in the blanks off the framework yourself. For example, use good software development practices like test automation and continuous integration. The scrum guide that defines Graham and contains more details can be downloaded from scrum guide start off 5. Benefits and pitfalls: in the final lesson off this class, I will talk about the benefits and pitfalls off working in an agile fashion. One benefit is that because off the frequent deliveries off software to the customer, there are many opportunities together and incorporate feedback, and that will make your customers happy. And they were like your products. Another benefit is that you minimize the lead time. That is the time from starting working on a feature toe, actually delivering it to the customer. The reason for that is that in order to deliver frequently, you only work on a small number of features at any given time and deliver them as soon as possible. And finally, if you truly work in an agile fashion, the people you work with are likely motivated to do their work. Now let's have a look at potential pitfalls. There many pitfalls. I will only present three that are very typical in my experience. I will also give you some tips off things you can try to do when you encounter them. In many companies, you need to fix the project scope in order to get project approval. If you can change that, you should at least define a way to deal with changes and you should do that early in your project. You can just keep adding features during the project. For every feature that gets a higher priority, some other future must get a lower priority or be removed. Otherwise you overload the system. In many organisations, the teams themselves are not really self organized. They let the necessary decision making power. Decisions are made up in the hierarchy, for example, of the product owner is not empowered to say no to requirements from certain stakeholders in such a situation. I have experienced it to be helpful if the product owner at least collaborates very closely with the managers who can really make the decision. Ideally, higher management should clarify rich decision making powers. The team has and make its own decision making process transparent. Finally, if developers repeatedly don't get the work done at the end often interational sprint. It can be a sign off leg off education, so you can, on the one hand, hire more. Senior developers, on the other hand, promote the further education off the developers. It is also a good idea toe plan, time for refectory, test automation and reduction off technical that every alteration 6. Conclusion: Hey, you watched all the lessons. How cool is that? I hope you enjoyed the content and that my German accent wasn't too annoying. That's one more thing. I want to invite you to do the class project. As you know, by now, agile is all about learning and improvement, and that's what you're going to do. You will learn one thing or improve one thing at the organization you work for, and you find a lot off helpful tips in the project description. And once you're done, I want you to upload the results to the Project Gallery. I'm really, really excited to see the result. That is very interesting for me. And if you have any questions or feedback, please just let me know the year.