The complete guide to Agile, Scrum Master and Kanban *Free E-book*

1. Course intro: Hey, guys, welcome to the first actual lecture of the course. We're gonna talk about agile scrum Cambon. What? We're going to cover it. What you should expect and give you guys a solid guy have to deliver change in value within your organization. You don't necessarily need to have a basic understanding of project management. If you're ever gonna be successful, agile, partitioning or scrum master, you have to make day to day decisions on project velocities for appointing with your team and run retrospectives to help the team go. You'll see that the course touches on everything that has to do with change and agility, as it's a philosophy that stands at the center of everything we do. Whether we use scrubber combat during life, you will also listen to videos and see demonstrations are building your first generation. How can men is a fight within your organization, but also the different roles that a scrum team consists of, But your responsibilities as a scrum master product, even a member who is a part of the development. This course is also for people would like to refresh your knowledge of agile scroll me Cambon as it offers a great inside. It's how we work daily. Using this course also includes ready made work sheets for you to pick up and start working . It includes a story point template, burn down templates and even a user story. Tough to guide you through your first year of stories of partition. If you do have any questions during the course, if you do need some more guidance if you have some feedback or suggestions from even, please let me know, because this course will always keep improving with your feet back. Our guys so hope you're excited because I'm excited to teach this course Solis jump it. 2. Intro to the Agile Course: no matter the company's sizer industry. There's always a least one person talking about making things more agile. But what does that exactly mean? And how could you put into practice and become more than a buzzword? Well, first of all, the business context agility is anonymously used to say that something is flexible, proactive and quick characteristics that come in handy in a fast paced and transforming world. But beyond this, descriptive meaning stands an entire mindset in a philosophy way of looking at challenges and doing things that goes a lot deeper, simply putting agile label everything that differs from a traditional waterfall processes. In short, being truly agile is a question of corporate culture. Perspective. To become agile helps to have a look at a shining example. One industry that is characterized by agility more than any other and has been so far from last decade's is software development. It could serve as a model for every other industry wanting to be agile. While many areas are only now realizing the full impact of digital transformation, software development has been at the very heart of this development from the very beginning , the way in which it understood the need for new approaches in the quickly evolving world can be best in the agile manifesto. It was published in 2001 after 17 leading figures in the software industry admit Utah mountains. A common goal was to find the best possible work flows for software development during their stay. They managed to identify and formerly common beliefs are defined in the agile manifesto. Today, almost two decades later, is more relevant than ever, especially for other industries. The guiding principles formulated in the manifesto by the essence of the software industries capability to keep up with a fast paced, digitalized world. So the most important question that all the other industries affected by this transformation have to ask is what is software development doing differently? And how's it able to turn the challenges of speed and flexibility to become part of its very nature? The speed at which new possibilities emerges? Breathtaking Virtual We have Blockchain artificial intelligence have already become the new normal technological foundation from any potential game. Changers dismiss that over the past years. Practical applications will without a doubt follow an exponential speed. But even as these new technologies are beginning to reach mainstream the next big things already in the making. Consequently, reacting to such developments is only one part of the challenges companies have to face, keeping an eye on the horizon and identifying potential game changers and understanding. The implication is a second part. The pervasive nature of the advancements in digital technologies makes things especially important. As everything is becoming digital, it becomes even harder to anticipate the full extent of the impact of new developments. Companies who are not prepared to adapt to these new requirements will quickly fall behind . Therefore, it's only necessary for companies to become more digital. Also have become faster and more agile. Nothing shockingly new here. So the real question is how to start and how do we go beyond buzzwords? We believe that there is one area which benefits most from agile methods, which is innovation. But why is that? Simply put, the active innovating often comes down finding a new solution to a problem not just any problem but a problem that often lies in the future. For this reason, the requirements for a solution can change again and again, planning a project from start to end and then adhering strictly to this plan is in many cases no longer direct route to success, the circumstances changing way too fast whether these air changing user needs technological requirements, consumer habits or market dynamics changes and the accompanying new challenges inevitable. Nevertheless, words such as unexpected or unforeseen are red flags and classical project magic. In contrast there no problem fragile teams. The paradox of them one of the corporate world is that almost every industry feels threatened by uncertainty and disruption, but the same time there's more information data available than ever before. So the problem, really is that information knowledge often not properly used or included in decision making , adopting agile principles and aligning your organization with them is the first step to solving this challenge. An agile mind sets deeply embedded in the corporate culture enables a constant look beyond the own organization at every point along the creation of new products or services and by all individuals involved with the right agile processes of mindset. Incorporating or reacting to these insides should not be a problem. Now this is only possible when agility is understood in its entirety. We're going beyond the buzzword of mere process optimization for software development. The idea of agility becomes the central elements that defined the end NT of an entire industry. It helped established a shared foundation for suffered developers across organizations and nations. At the same time, said the industry, apart from processes in the analog world, in doing so the agile principles to find a new type of work culture perfectly aligned for the requirements, a digital environment, a transformation of the world outside softer development needs to catch up with. 3. How is traditional project management different from Agile?: so looking at the waterfall timeline that we have in front of us, there's seven steps. As you can see, so is gathered document requirements, design code testing. You're pretty, fix backlog issues and deliver the product. So during this development mythology, each stage needs to generally finished before the next phase can begin. However, in between the different seven tasks I've listed, the project needs to be reviewed and approved by stakeholders before any form of design can be getting obviously isn't anything in this world. It comes a lot of positives, but also drawbacks. Let's take a look at these now. The 1st 1 is mutual agreements. Now both parties, customer and developer. They need to agree on what will be delivered before the actual implementation work. This makes the planning and design straightforward, and you can expect very few changes in the second part progresses, measuring through the full scope of work. Very simple. This means that the R A Y, and the processes for the project have already been guaranteed before the work commences. 31 is designed is the earliest phase now. Design isn't earlier phase. The most other phases in these type of projects this means that it lends itself very well to wear. Components need to be built or designed. For instance, you're building television, electron ICS, car seeds, refrigerators, anything big and physical. Number four all requirements known beforehand now, since all the requirements obstacles are known before had it provides a more complete image for the engineers and very little area for errors. Now let's take a look at some of the negative parts of waterfalls, so the 1st 1 being stakeholder being ability as we look, a waterfall is a heavily oriented towards requirements gathering as well. A stakeholder availability requirements gathering phase dictates of the rest of the project will look like there's very little to no roof. Flexibility says that you have a key state cold. It's on vacation for four weeks, and that's when your apartment scattering sessions going on. You might have an issue gathering requirements from the specific business unit blueprints and mock ups and difficult to visualize Now, stakeholders and customers not always able to visualize what blueprints, wire frames or mock ups will look like as a kind of product. Most end users also difficulties pairing these with a written requirements given prior to the project. Start changes also become difficult and very expensive, especially later into the project. Um, what if all is based purely on requirements have been set months, maybe years in advance. So imagine how difficult it would be to change the door on the refrigerator or three floors of the skyscraper versus writing, re writing a couple lines of code. That's what I'm trying to get. 4. Agile comparison: So if we look at agile, you see that the first point is actually key principle within the job with the dollar, Do you frequent delivery? A working value that the customer frequently sees work being delivered within spirit review sessions, usually within 10 days. Changes and decisions can be made throughout the project, the second part being strong sense of ownership. Now there's always a strong sense of ownership team wives. The team works together daily to build a product. You have all your ceremonies in your scrum, whether you use camera very easy to produce. M V P, now agile, prides itself on delivering high business value and working software, thus making it easy to produce a basic version of said software that can be timed with business goals such as marketing etcetera. Every day is a requirement. Day development is a more user focus, as there is no single point in time for apartments. But every day, Community Requirement day, which give me section into further sprints, added into the product backlog and take it into the future sprints that you will have. Now let's take a look at the negative side of agile here, so each item might not be completed in the time box. Agile as we're going to explore within this course is a time box delivery. This allows for changes every prioritization. Now this means that delivery items might not be able to complete it within the plant. Sprints should distort one's be too high or wrongly estimated by the team during a sprint planning. Now, additional project costs can also occur just additional features being requested throughout the project. We need to adapt and change as well working a job so reduction of quality. There's a risk for possible reduction in quality due to frequent re factoring, it's a full scope is not considered in the architecture or design. Now, if we look at the agile time that loop here, you usually have your meeting plan. This is your backlog group sessions or Sprint tanning sessions. You also have design. You have code and test release feedback, which you were receiving. Your Sprint Review sessions going back into me. The plan. So let's take a quick look at a comparison between waterfall and agile. So starting with customer availability, customers get involved that very certain milestones in the project. For instance, approvals there's AH design hand over to death. There's test handovers you ain t hand over, so all those are very self contained. If you look at a customer availability with an agile stakeholder, availability is very, very important throughout the project. That's actually key. You have them in your reviews. You have them within your sprints. You have them within your sprint planning, always talking to each other, communicating. It's also on the principles of agile. So when we look at scoping waterfall, the pre defined requirements are key for waterfall, and they work really well when the changes are limited. That means that there's a pre agreed scenario toe work out of, and this is pretty much any changes on welcome. So if you look a scoping, agile adapts very well to change, it does come at a cost of the project is not known in advance. When we talk about prioritization and waterfall, the customers get everything they asked for. If the task is determined within the contract and the requirements phase, that is a little agreement with that waterfall is that it's everything is agreed on up front and then the team executes it. We look a prioritization with an agile delivering value. A working software reduces the risk and can show signs of product being on track. Rapid milestone delivery increases the chance of an organizational approval. We're looking at pricing cost budget for waterfall. There's always an agreement as major before the handshake happens up front. That means that the fixed project costs stands not for agile. It works great with a rolling budget or when a cost this set with the limiters friends, let's say 10 sprints or whatever. However, that means the work and still be pending. So a cost model fragile could be monthly funding for the whole project. We look at the team aspect for Waterfall Nigel's over waterfall. The team handoffs mostly happened during separate milestones have been achieved designed to development. For instance, if you look at agile, they're smaller teams and pause ourself organized the pretty much run themselves with this process is the killer of agile 5. Waterfall and Agile Car: So as a car manufacturing company, I would like for my card to be produced within 12 months. All my requirements of the ships are factories, all the designs of also manship, and now it's time to build. So if we look at the whole process eagles from design, down to development now the testing of finishing with shipped in done. Now let's take a look at an agile way of building a car so the client and the team are completely involved in the process. Together, the team delivers the highest business value first, which is the car because we want to deliver a solid M V p. We take items out of the product backlog work on those during generation one, while remaining in constant communication with the clients that can adapt our project to change. Should there be in after iteration, which is two weeks long, We then present our clients with a car. Once you have received our feedback in new insights from a product manager, we're going to look at improvements that this car in interest two and three, with every iteration lasting two weeks 6. Agile Principle 1 2: the first principle of agile says are our highest priority is to satisfy the customer too early and continuous delivery of valuable software. Your gold here is to focus on delivering value, whether it's software or designs for organizational plan forward. That means by how you do this, you scrum, master of ceremonies and, for instance, different tools are just tools. Should you not reach your gold complex, tools and processes is obviously a bottleneck. It needs to be cut for set aside in agile will you deliver used to have a level of agreed usability. This means that in a small amount of time, you re on a deliverable. Let's see your first sprint. He should deliver the highest business value to the product. You may not be perfect, but needs to follow a trajectory of iterated processes that make public hold for the first month That helps you do is the delivery. Improve the work. Allow customers to evaluate the value you brought to the table and get points of feedback as well as opening up for war. Communication with your team decline for the organization. Here's where we again refer back to waterfall project management, reclining contact usually happens at start at the end of the project, continuous delivery can be challenging. These environments are breaking down. Work on deliver feature incrementally helps delivering pieces of projects. The customer so they received the second principle of agile says, welcome changing requirements even late in the development. Agile processes harness change for the customers. Competitive advantage. The second principle addresses a concept traditional project manager methods. Can being a doctor to change in the software world within an organisation? Change of scope for details in the product often come in all sorts of risks, such as missing an important clients that deadline or going over your budgeting forecast. The reason it's a race change is to provide about the change does not provide value of any sorts. Why would you do it? Well, sometimes our customers orientation towards the goals change. Sometimes they also don't completely understand their needs until seeing the first incremental piece of value being delivered from both parties or even within organization. Stakeholders focus on value and have that mindset across the entire project. Change won't come so difficult, also taking a navigational approach. Rather it's not approach means that you might get a better destination yet be prepared to change direction and find advantages or the people we work with decides change might open up more opportunity for you, and the teams do excellent work. 7. Agile Principle 3 4 5: the third principle of agile tells us to deliver working self frequently from a couple of weeks to a couple of months with a preference to the shorter timescale. It's very simple to remember, but also key here is to know that we always try to deliver value. This principle focuses on delivering the highest business value first, as well as delivering a piece of integration that the customer can actually use while being able to attach measure reports from their side. Even if we're looking at a very rough design or rough piece of software, this could mean it still carries a lot of value for organization, especially agreed with a product owner. But why deliver half baked biscuits and call it a day? Well, work that is measurable and that provides value also offers a bridge over to more feedback . For instance, a booking Vigen for a Web site, a product details page or even a product filter feedback gives you in the product owner a basis for the continued communication. Frequent delivery and feedback means that people get used to communicating, which also builds trust you as the scrum, master or product manager are including the client in the core of the project, opening yourself up to viewing how you work in time with trust and communication. Next delivery also improves frequently, however, also does not mean fast deliveries. Generally speaking, fast deliveries have a tendency to be seen. US have lower quality due to cutting corners and delivering as what some people refer to as half baked biscuits. If you do think about frequency, this could also mean you could restructure your work so you could deliver better work and more value. Looking at all this information about the living work frequently, as well as receiving feedback, communicating openly. The summary to all of this would be you deliver usable work. Received more feedback. Faster deliveries show more transparency leaves more room for optimization delivering work as early as possible. Results in good communication, which improves the following deliverables. The fourth Principle of agile tells us that business people and developers must work together daily throughout the project. This principle focuses heavily on the value different types of cross rolled communication and cooperation could happen. The project. This mindset has you expected to work with the customer daily, speaking directly and often with your customer or members within your organization that you're doing the project for increases, trust feedback as well as a direction towards gold. This could also lead to informal improvements. These improvements are generally not taken down his action points and formal meetings, but rather informal settings such as standups or show until where you all agree to improve the product based on the mutual understanding of the group rather than a direction set by someone else. This type of improvement comes with passion and excitement rather than just getting the job done, I found that mixing these Beth is up together with your internal team as also product owners, does help and contributes to reaching the nirvana of informal improvements, passing updates to each other on slack, creating cultural open and regular communications to catch ups and quick calls. Also invite them to describe Mr ceremonies, such as warning standards. If your customer includes multiple people, stay in touch with them in touch base with him frequently. Fifth principle of a job tells us to build products around motivated individuals. You give them the environment of support they need and trust them to get the job done. This principle touches upon the concept of creative individuals can flourish if they're being micromanaged, forced to work in environment, the slightest of creativity. For an agile project to be successful, a team must be given the tools they need to succeed and be trusted that they're able to your job. But this principle is so much more. It is saying that one cannot work without. The other projects cannot be built without motivated individuals. So to make this a whole lot easier and to create discussion around it, let's break it down. Building projects means that you are working towards defined golds. These goals come with their own sets of activities and goals as well as boundaries to work within deep inside the mind of everyone. Launching or working within a project is the need for progress knowing how to accomplish progress and success is vital to retain motivation. Interest Seed as a navigational gold. If you were constantly drifting, how do you know you achieve what you set out to accomplish? Motivated individuals can achieve the impossible Motivation is fires and drives us while also bringing interest in knowledge, product agile and motivation living constant symbiosis, agile, built up, looking at people first if people are demotivated with poor feedback, have issues communicating and go show initiative. One cannot exist without the other. Give them the environment of support to meet any sort of development. Whether it's organizational creative software requires a set of tools. Are digital landscape is ever changing mawr more tools coming out to simplify collaboration and process. But this also comes good. Support someone to help them solve these annoying small problems, making sure the voices air hurt. Here's where a sense of empathy and carrying for the well being of others comes into play. Trusting your team members to get the job done is a challenging situation is you can find yourself in a situation where too often develop patient leads to go about output. 8. Agile Principle 6 7 8: the six principal says the most efficient and effective method of conveying information to women in development team is face to face conversation. Face to face communication is always the most effective education, this type of conversation. There's no room for misinterpretation and helps you get to the point of any communication. This is especially true when a group of people are working on a project together. Particularly must beat is the gold. You communicate effectively here more same or and work for efficient. I've seen team behavior change and companies being large airfare bills just have teams in one place in a job projects where teams work intensely on a project for short periods of time. There's really no time from this. Communication depends why there's a principle face to face for education, but I'd like to take the opportunity to also discuss remote working as a policy. If a team is well connected through all nine ways of communicating and have built a level of trust, why would remote working be a problem? Remote communication can distort the normal pace of our conversations to delay between messages can offer, postpone or hide emotional reactions, comments how many times have you written and you know it immediately. Everything send. They're concerned about How land did your ball see your late night email and considered to be an intrusion on a private time? Lacking in an immediate response, we can become distracted. Second, guess ourselves. We even grow frustrated with their teams. So to make this easier, don't complain. Brief communications. A clear communications In our efforts to be efficient, you sometimes use fewer words to communicate. But such brevity can mean that the rest of the team waste time trying to interpret your messages. Spend the time to communicate with the intention of being ultra clean, no matter the medium. Indeed, you can never be too clear. It is too easy to be less clear than you should create intentional space for celebration. Old school birthday cakes are still important for remote teams. Cranium, virtual spaces, the rituals for celebrations. Socializing can strengthen the relationships and lay the foundation for future collaboration. Seventh Principle of Agile tells us working software is a primary measure of progress. This principle address is the fact that because work is done intensely and quickly, sometimes mistakes will be made and products will fail now failing fast is a terminology. Use a lot within the agile industry and does not mean successes void. It generally means that within a failure, you do learn and establish grounds for success. Their questions. You can ask yourself to assess your team's progress. He's a development team, burning down consideration stories 100% without feeling overloaded or under used. Is your product owner satisfied with the deliveries of the end of the federation? Is your team adaptable to change? We're not leaking defects that every iteration the point the agile manifesto was trying to make here is that the more you deliver, the more you learn. Remember when we spoke about navigation? I've been a part of projects where clients and customers understand what they really do want. Once we've seen the first bits commiserated delivery coming in, this means constant refinement, delivering a usable parts as well as delivering review. Will parts that can be doubled? Let's say, for instance, you are working on a product with a list of features, much like a game. As you deliver your prototypes that are testable, you contract them with measurable bulls considerations. If you're aiming for a certain number to attach to KP eyes. You can measure that with a workable product, even if it's very rough. At this point, the eighth principle of agile for most sustainable development the sponsors, developers and users should be able to maintain a constant pace in definitely in traditional project management methodology. Some projects require lots of work up front and at the end to keep the maintain with agile methodology. That should be a constant amount of work To explain this further agile principles state outright that you should find and keep pace that can be maintained indefinitely, and everyone should have that pace. This is also what we call velocity. I love to phase is positively, but let's face it, it's a principle about not burning up adult processes. Make sure that development that is sustainable, that the inputs velocity testing all aimed so everyone and I do mean everyone involved could keep this up forever. This, of course, makes sense once you find a doable pace, be able to continue predictably over time. When there's deviation, you can adapt as you've got a stable pace going. When it's sustainable, you can keep delivering value. You don't just say Hey, let's be sustainable and it happens. It's something you have to work on. This principle reminds us to commits to it, to make sure we find the pace we can all work out together. Sponsors are the people asking for the work. It would seem there old is obvious. Don't overload people. Of course, it's not that obvious. Each of the three groups have different interactions are created products. So how can sponsors worked with the other groups? So sponsors need to understand what pace developers can work out and supported, perhaps even pushed back on. Those pressuring sponsors need to work with developers and be available so they can assist both developers but also stay aware of their paste and sustainability. Sponsors need to understand user expectations, not just what's wanted for what give me handle. It might sound great to shovel out of Thomas stuff, such as patches for games, but this may limit feedback. Communication users can only handle so much sponsors, should listen to users and give FIBA finding ways to encourage sustainable development. This may also mean understanding music, perspectives and what they want and what you want. My different. So what do we need to watch out for sponsors, overload developers, this often fails. He's bad blood, and there's more where that came from. Attitude I see a bit too often in creative fields makes enemies. Sponsors don't pay attention to users or assume on what they want. They often get it wrong. Your team versus sponsors give sponsors feed that information to help them pace themselves on pace. Working with you, the more preemptively you give them an idea what sustainable quicker they'll get it. Help sponsors reaches sustainable pace. They don't do the work. They may not know what it is. You might save them from burnout, or being overly pressured will help them find an outcome. 9. Agile Principle 9 10: the ninth principle of Joe tells us that continuous intentions of technical excellence and good design enhances agility, are paying attention to technical excellence. In good design, you become even more adaptable, more productive and more agile, simple and elegance. So, as you may guess, I'm going to analyze this. It's not that it hides any complexity. It's obvious it's that there's a lot of power in this one that anyone can use. This principle spells out a technical excellence in good design are things that one wants to be attention to always. That, of course, is obvious because who wouldn't want to pay attention to doing things right in designing things right? Was they specifically that enhances agility? The benefits of these things aren't just hey, well done here that you use agile methods and apply agile principles. Better is a benefit beyond the obvious of doing stuff. Well, we designed something. Well, it's more than just a valuable piece of work. It delivers other benefits that deliver agility. Let's look at them and how they applied to creative Would good designs prevent errors since you can get it right the first time. This means that you save time says you've got less revision in aspiring to good design. Focus. You're listening to the client understanding works. You deliver value that helps in unpredictable environments, which you probably face a lot good designs. A repeatable in part or in whole, which saves time in the future that lets you work faster, since you've got other things to call on, like design templates, reusable code or even helpful checklists. This can help being creative works because you got some work done already, at least the less predictable or standard parts. Good design isn't necessarily the same as technical excellence. Good design, maybe about laying things out and putting things together well about organized making patterns. Apparent technical excellence is about attention to detail, about doing things right about not over doing things again. It is obvious benefits. Anyway. Let's see how it effects agile creativity. Tens Principle of agile tells us about simplicity. The art of maximising the amount of work not done is essential. So imagine you have a to do list for more than 100 items on it software. It's easy to get carried away, trying to achieve absolutely anything that may be possible under the sun however, agile methodology states to focus on achieving on Lee what is absolutely essential to the project's success in order to deliver the project as quickly as possible. What does this mean? Practically when the right value is delivered to people, you avoid delivering work. We're getting stuck in processes that over incumbent routine. This means focusing on simplicity from the get go hand, carrying out each task and the simplest way possible. Don't build more than minimum required. Don't talk about features which are four sprints away. Elaborate your backlog as your progress in the project, which means top items in the backlog well refined as you go down less and less for fine. The interesting part of this principle is that it is generally applicable. This principle is true and important for a wide range of processes outside the software industry. It could even be applied on our own Personal lives is a principle of time management and of work optimization in many different expressions of this same principle are out there so eliminate low importance of the largest issues. An example put them in the not to do this. Always try to keep your process is as simple as possible without the end product losing his desired functionality. Ask yourself if you're producing something that is a most useful for the least amount of time. 10. Agile Principle 11 12: the 11th principle of Agile tells us that the best architectures, requirements and designs emerge from self organizing teams. I've been on both sides of world during my time aboard large multinational corporations, so they're very arcade with the project management, and I have been involved in startups, for we have all been self organized enables to tackle the work ahead. But how did all this work out and why? Entirety. What we have been reading and talking about in this entire section is focused on self organizing, an a level of autonomy, from communicating to reflecting, tantalizing and cultivating on organization. We also started how this practically works is that people use their hands on knowledge to design, organize implant. As long as you're delivering value to stakeholders, will appreciate your approach. People will also gravitate towards a structure that works for them. You don't hold all the answers that start, but having self organizing teams says every individual out on 1/2 to achieve just that, answers that can bring the team in the project closer together. This approach allows for adoption. You change it, a dad works, and what doesn't focus on value will keep your team for being too distracted with other waste so summary avoid over structuring. Encourage adoption with feedback. Also encourage communication. 12. Principle of Agile tells us that at regular intervals, Team reflects on how to become more effective than tunes and adjusts its phase recording. We have now reached a final principle together, and it is as transparent as a sounds. Team regularly reviews ways of becoming more effective and steers the ship in that direction. The most important rule within this rule is regularly. This should be a very anti great part of the team structure. You then know how it's coming and you ready for it. This certain ketchup or retrospective, as it's called, is a good time for the team to reflect on what has gone great or could go better. He gets people into an improvement mindset, and when we learn that what we grow together, it also encourages lessons that can be used in the future, whether it is on a product level, team level or an individual level reflecting on being more effective. Sounds great, but there's an issue. What does it mean for your team to be more effective? It's not an obvious question which is why the importance is and how we answer it. How do you measure efficiency? You know you're getting better. I don't solve this by asking a team how they want to measure efficiency and then going around until we have an agreement in a way to do it. For many, it's a simple general gut check. Did we get the work done? A sign off, you may find a few additional factors come in. You may also find it changes over time. I can't emphasize this enough. Make sure that these reviews lead to concrete goals for the team they can measure. And tests for the team were individuals. So you can say who finally achieved maximum efficiency. Make sure your team comes up with concrete suggestions that you can move on. In fact, when I do this, I review them regularly, often during other meetings and definitely at the start of the next review 11. The 4 Core values of Agile: the first value of agile tells us that individuals and interactions matter over processes and tools. So it is getting more and more clear for people these days that the people respond to business needs and drive. The development processes are crucial next to all these processes. The context of this would also mean that process driven projects with heavy dependency on said processes offer very few options for flexibility, resulting teams feeling the strain, not being able to carry out their tasks as efficiently as they wish. The tools we use during development of on implementing organisational changes can prove that most of the time imagine you have a development and design team working closely with each other on a product. The development team is heavily reliant on the design team to provide accurate specifications and handovers if the team is stuck in processes that revolve old tools that are not as efficient as a newfound ones, that can cause a serious risk in terms of quality and timeline, not to mention Team Moreau. Second Value of Agile tells us that working software matters over comprehensive documentation from own experience. Working in waterfall projects. I've seen organisations been enormous amounts of time documenting the product for development as well as coming up with requirements list that could run up and down the skyscraper in central Hong Kong. All of these then had to go to senior stakeholders who had seen your stakeholders, and they all need to be approved one by one. This is obviously a cause for a huge delay in development. Agile, however, does not eliminate the need for documentation. It just realized it in a certain way where the project team does not get bogged down in each and every detail project difference, I'm trying to point out here is the agile documents, all of the requirements as uses story sufficient enough for the team. Start working on the Third Value of Agile tells us that customer collaboration matters over contract negotiation. This is where we can compare waterfall and agile in the clearest negotiation or, for instance, backlog. Grooming is when the product manager and the team work out the details of the delivery setting milestones, expectations and deliverables. Thes details are obviously always up for renegotiation. However, she's a development team model. Follow Wonderful. The negotiations start before the product starts and ends after the part that this means that the level of involvement is very thin or non existing during the actual development process. Agile Manifesto describes a scenario where collaboration is a key value where it makes it easier for development team to meet organisational needs. This collaborative method usually follows a certain pattern or predictability. For instance, there periodic demos as well as the ceremonies following scrum framework. Fourth Value of Agile tells us that responding to change matters over following a plan. When I started out as a project manager, I was working in an organization that was switching the organizational mindset from water hold My job before this happened, developing features or a certain type of software was regarded as an expense. Before we moved into the development phase, elaborate plans were in place everything at a high priority and could not be negotiated with that job being brought into the organization that mental priorities could not be shifted. Federations and new features will always be added into new ones. The manifesto means that the view we need to have his agile practitioners is that change provides value 12. What are Story Points and how do we work with them?: store points consists of three components that we need to consider whenever we're reviewing our users stories or wanting to estimate, and these are risk complexity and repetition. Now risk can be due to unclear demands, dependence on third party or uncertainty in the future. A couple examples are Are stakeholder hasn't signed the scope of work agreement. We still have to source additional developers or our stakeholders just completely unavailable now, going into complexity, these air efforts involved in developing in particular feature. So, for instance, before we start developing, we need to understand I was certain part of the I T infrastructure works going into repetition these air monotonous tasks without any real risk or complexity attached to them . So the examples for this is tasks that don't require much work at all, changing color on a logo or shifting a button to lower part of a box. Now, looking at the Fibonacci scale, the difference between one and two doesn't seem too great. But if you look at three upwards, you start noticing a significant difference. A general practice for developing story points and pairing them with your user stories is to draw a table. But in this table, you have your set story points 1 to 21 so zero would be very quick to deliver. We won't even include that. So Number one is quick to deliver a minimal complexity. Number two. Quick to deliver some complexity. Number three. Moderate time to deliver moderate complexity. Number five longer in time to deliver high complexity and likely unknowns. This could be that you know what needs to be done at a high level, but there's a good amount of work due to complexity of the development, and their big unknowns will discover as we get it to work. Number. Ages. Long time to deliver High complexity, Critical unknowns. 13. Long time to deliver high complexity, many critical unknowns. And when you're on 21 you're definitely doing things a little bit wrong. They need to broken down because because it will take a very long time to deliver. The 21 could actually even be seen as an epic 13. Writing user stories - INVEST: I stands for independent stories should be a Sfar as possible independence. Each of them could be developed and delivered separately and stands for negotiable use. The stories could be discussed further, and there should be space for negotiation. These things were valuable. User stories should result in adding value to the customer. E stands for estimable hears. Their stories should be understandable enough so they could be divided, divided into the task and could get estimated estimates for small users. Stories should not be too big. Usually should be done with that 40 hours of work. T is testable. User stories usually have acceptance criteria test if they fulfill the customer's needs. Now, in order for us to really cook up, this uses story properly. We need to write something called acceptance criteria. Acceptance criteria is a must have ingredient for use history. Acceptance criteria is a checklist that determines if all the parameters over uses story and determine when they use the stories completed and working before the develop breaking mark. The uses story has done so, for instance, for e commerce, mobile app, users stories, we will use our as a shopper. I want to review my cart so I can make adjustments prior to check out. As a user, I want to view a list of products so I could select some dip ridges. As a shopper, I want to check out so I can get my products shipped to me. As a user, I want to see a notification whenever a new product comes into the store. Now you see the first to use those stories about acceptance criteria is in here. We can take a look at them for the 1st 1 The 1st 1 says view quantities and items in the cart. See a total cost before tax and shipping. Remove items, just quantity of items and click to navigates a product detail. 14. User story writing: so this explore the core of agile uses. Stories here use the stories are agile themselves, and they can use for us to follow agile principles. But we need to keep three principles of mind that it here to use the story writing Working suffers the highest measure of progress, our highest priorities to satisfy the customer through early and continuous delivery of valuable software. The simplicity the art of maximizing work not done is essential. So what we need to do here is to deliver value to the customer chunks and prioritize what's valuable versus not valuable. The best way to do this is represent the work we're doing through simple stories using invest. So let's take a look at a couple of easy uses stories here. As a user, I want to change my password so I can keep my account safe. As a website visitor, I want to subscribe to the mailing list or products. I can receive new offers As an admin user, I want to disable the user so I can prevent unaltered unauthorized bargains by please. So there's something really strange about this, but we always need to cover who, what and why. Using a template is a good way of capturing with the user actually needs and what would deliver value for the users. But that's not go occupied an implementation details, because these are purely goals. But how you complete these goals when we use user stories? It supports our goals of vision. It does support development practices. Unclear stories, obviously confused the developers are designed is a result of many questions about obscure goals you'll need to explain. So one key thing to keep in mind here that always remember, is that Remember that use the story should be written in such a way that you never have to explain the goal. It should be so evident in on point that everyone's on board all good uses. Stories are written from the perspective of the user, and that's the only perspective you would use. Progress is based on what valuable actions you your user can do with software, so it's that you're working on airline booking up use. The story must reflect the problem you're trying to solve in the go. So let's say the background to this is that users had a very hard time selecting a seat in this case the users story to this would be as a user. I want to book a seat so I can choose where could sit on the flight easy, right? Well, OK, What word? Really? Creating stories that make sense for users were obviously not reaching the goal. If we don't do that, how do we handle developer story? So it's like a good example. As a developer, I want to use visual studio so I can code faster notice that the story itself is pretty bad . I mean, the idea itself is great. You do need visual studio. But why would you your entire piece of work, depend on 12? It's kind of a blocker, so it short. This story is a p requisite of independency of any other story. It's not self starting with sit somewhere in the middle where things need to happen. For this to be completed. This is called a deadlock, which is when two things depend on each other 15. Why do we use Value Points?: some examples as to why we use value points are strategic. If we don't make this, investment will no longer be able to maintain the market share on before behind compliance could be. If we don't make this investment, we could be in breach of a certain regulatory law. Revenue generation means that we don't make this investment will miss our chance of creating a significant return of investment risk management. If we don't make this investment, we could be in a position where we wind up with a dissatisfied stakeholder cost avoidance. If we don't make this investment, we could really we could realise additional costs in the future. Now, value points can offer useful tool to help with a prioritization process. For instance, you can plot effort against value to maximize delivery of those stories, delivering the highest amount of value for each unit of effort. Value Points can also, in part of the development team to identify the most appropriate solution for particular uses. Story, for instance, the values low, so I'll not spend as much time on it as one of the higher value cards 16. Let's plan our sprint: So now we're going to take our story points and had them into a value scale. So value scales I call it is called store points on access and the business value on the other axis. Now, if we look at the value scale, we're going to use Fibonacci levels from 1 to 21 of business value and 1 to 21 on story points. I know 21 seems high, but they're with me. It's just to give you guys a good range. An example how these things work again. These stories don't reflect reality. They could actually be ones or twos. But I just want to make a good spread for everyone so you can understand the width of everything. Now we look at the first card. Ah, as a user, I want to see a notification whenever a new product comes into the store. So let's say my team has estimated this test to be a 21 and this test to be a three in business value, so we will add that entire list we're looking at as a shopper. I want to check out so I can get my products shipped to me. There were looking at an eight and story point. So we're looking at 13 the business value as a shopper. I want to review my cart so I can make adjustments prior to check up. So looking at this one, we're putting it as a 13 a story point, putting it as, ah, 21 on business value because super important to be able to check out as a user, I want to do you a list of products so I can select some to purchase, Obviously very important for an e commerce store. That's all the 21 and we're looking at. A three in the story points were saying, This is going to be easy right now. Once we have all our story points and our value points, Um, we know how long something is going to take and how valuable it is that is the whole point is exercise. Moving on. This is our spread, uh, as a shop problem. To review my CART story 0.13 Business 0.21. As a user, I wanted your list of products like a select some to purchase or 0.3 21. And so on 8 13 21 3 other next following cards. Now we know our business value. We know our story points. That's great. But we also have something called Bang for the Buck. So, for instance, as a shopper, I want to check out to get so I can get my products shipped to me. What we do here to determine the bank of the book on why we do it is to determine the real granularity of this point. This is in order for us to prioritize better and easier. So what we do is we take the business point and we divided by the story point. And that's how he reached back to the book. So if we look at this table here as a shop around with the checkouts, I get my products shipped to me be business values. 13 store points. Eight bang for the buck is 1.625 Now, if you look at this list, um, when we sequenced this, you will see that the last story here has seven. The first stories 1.625 So these ones are closely aligned. So these are the ones we should be looking at now in terms of federation. We have yet to do any work, so we just do not know or velocity as of now. But we'll add these things into Federation one and see what we can deliver. So let's say two weeks down the road, we've actually managed to deliver 34 business value points, 11 story porn's and bang for the buck, 8.625 So our velocity for future sprints will be 11. 17. How does a Burndown chart work?: So if we take a look at this burn down chart that we have here, we could see that the Sprint burned down. Contains 87 to 64 56 48 40 32 24 16 and zero. That's what last burned down. So our sprint during Bernanke's blue goes to 10 days. You can see in 80 story points. That's our sprint line. It's the X axis. So why access contains the story? Point said it's 80 were burning from 80. Now let's take a look at actual velocity. We start with 80. Obviously, that's where we start. You burned down five in the second sprint in second week 70 on the third week, 58 4th week, fifth week. We go slightly lower. We go 43 six weeks. We burned down a little bit less. It took a little bit more time. So 36 seven we look at Ah, 30 going to eight. We will look at the number. Let's say 20 number nine. We will look at 18 number 10 look at zero So we actually managed to complete this sprint, but you see these over unders that we have so on spring two and three, we went over over estimated capacity. So this means that me then managed to solve 72 which was our goal. The only man I should solve five instead of eight. Now, this means that they must have been something going on. Maybe we overestimated with me. We underestimated the task. We need to take a look at how we estimate this. Whenever the red lion is over the blue, that means that we are behind the planned schedule. If we're below the blue line, that means that we are ahead of the planned schedule. You see this happening products all the time. Sometimes you're above sometimes your low. But your goal with this chart is to hit that zero spot that your sprint burned out is telling you. Some people say you have to hit 80% and that's fine. But generally speaking, if you commit a backlog that has that's 80 story points and you commit to that, you should solve those 80 story points 18. Let's look at Kanban: chemin teams generally centralized the work around the camp on board. This, too, was a white board of wall or anything you can put sticky notes on. They could be virtual or physical, but they're both a crucial feature and visualizing and tracking the amount of work in progress being made. With that being said, all blockers independence, Cesaire immediately identified as well as results. If we look at a basic Camembert like the one below, we will see that follows three columns to do in progress. And, uh, there are, however, more detail board with items such as coder view or whip. Now, the main purpose of presenting workers cards is for the whole of your team to be able to track any purpose work in a visual manner. The's cards hold critical information as well as the work that involves in creating and solving the task slash problem, as well as an estimation of how long that item of work will take to complete. Remember that the estimation we've done doesn't change. We still use story points. Cambon also allows for great planning flexibility as a product of when it came freely, add tasks or remove tasks within the backlog of work as long as we still fall. The business values were identified in the previous section. We're still sure we're maximizing value for our customers. This means that we don't generally look at fixed duration. Such a sprints. We rather look at cycles. The lead time is a time from the moment when the request was made by a client and placed on the board toe. All work on this item is completed and the request was delivered to the client. So it's a total time. The client is waiting for the item to be delivered. The cycle time is the amount of time that the team spent actually working on this item without the time that the test spent waiting on the board. Therefore, the cycle time should start being measured when the item task enters. A working called him not earlier, like everything else in my job, their principles and values to adhere to. So Cambon is a whole nine of them that we will explore the detail below. Start with what you do know. So chemin does exist on its own, but it's not mutually exclusive to other work flows. You can peacefully coexist and bring issues to light. It does not require sweeping changes just to better self organizing. You might as well run a scrum project in a camp and wait agree to pursue incremental evolutionary change. Cam Band is an approach allows for change and change management without meaning. Organisational resistance doesn't cannibalize on internal structures and introduces a way to visualize organized work. Respect the current process, roles and responsibilities. A scab in encourages incremental changes. It still does not instill fear that was like for progress and determination. It allows for broad organizational support and small course corrections that save projects for large processes. Encourage acts of leadership. You don't need to be leaders or magic directors to implement this change. Leadership comes from the teams themselves. Remember when we talked about self organizing teams? That's one of the principles this supports. Visualize the workflow. The most common way to visualize your work is to use cards and walls. Each column represents steps within this workflow, but most importantly, progress in value work in progress means that you have a back look and that things have moved from to do. The critical elements are that work in progress that each state in the workflow is limited and that new work is pulled into the next step when there's available capacity within the local would blew it. These constraints will quickly illuminate problem areas in your flows. You can identify and resolve them living, which is a cornerstone of Campbell managed float The whole point. Introducing Cambon into organization is for to grow a signal positive change. Visualize is how values flowing through the system. The journey itself is a repetition of cycles. Make processes policies explicit example of a policy coming very explicit in your project is to look at the definition of duck. In fact, it can be created for every workflow, meaning the before items can be pulled into your cycle. He needs to meet certain criteria, such as acceptance criteria. When teams were all aligned on the preferred model of working responsibilities, rolls risks, they're more likely to build a shared understanding of the problems and suggest improvements. 19. Scrum Artifacts: storm artifacts provide key information that the scrum team and its stakeholders need to be a rare of during product development. These activities being planned, the activities being done in the project at the following artifacts are defiant and scrum process framework. The product vision is an artifact to define a long term goal of the product or product, It says. The overall direction and guys this from T everyone should be able to memorize a product vision. Therefore, it must be very short and precise. The product backlog list is maintained by your product manager or product owner. It's a never moving list of features, enhancements, fixes and acts as a basis for your sprint backlog. This is your team's current of future to do list and is the subject of re prioritization. The Sprint backlog list is a list of items that you have agreed to with a product manager owner to complete within a set of time, usually within a two week sprint. During the spring planning session, your team to get the with the product manager or transfer a set of tasks from the product backlog into spring back. Your sprint goal is the value in a usable end product that has formed at the end of the sprint. During your final Sprint review, the team shows what they've accomplished, whether to be journey. The terminology for this is also doing his definition of done. This definition needs adhere to the values that has been preplanned with a product manager or owner prior to starting the project. Now we get to the definition of done. Every product backlog item has acceptance criteria that define measurably what must be met when the item is declared to be done. Many criteria applied to all or many product by four items instead of repeatedly defining these criteria with each item is proven to be useful to collect these criteria in one place . The definition of done. Thus the definition of done is a shared understanding of the scrubbing teen on the meaning of work to be complete and finished. It typically contains quality criteria, constraints and overall nonfunctional requirements. Couple examples are definition of done reviewed by someone or a particular stakeholder. Completion of quality assurance tests all issues six. Completion of all documentation related to the story. Now we get to the increments. The increment is the sum of all the product back look, I was completed during a sprint and all previous sprints at the end of the sprint. The new in current must be done, which means it must meet the scrub teams definition of Doug. It must be in a usable condition, regardless of whether the product owner decides to actually release it. Burn Down charts. This is one of the most important things I want to take you through. The burden charts are a great way for you to measure value that your team is putting out also how much effort and if they're being efficient. So Bruno charts or graphs, they give an overview of progress that your team is done as tax. Like completed, the graft burns down to zero. It's used as a tool and a guide during development to lead a team to successful completion of a sprint on time. Updated every day, it gives a good overview of the Sprint promise. Burn down charts are useful because they provide insight into how the team works. For example, if you notice that the team consistently finishes work early, this might be a sign that they aren't committing to enough work during spring planning. If they consistently missed their forecast, this might be a sign that they've committed too much toe work. If the burnout chart shows a sharp drop during the sprint, this might be a sign of work has not been estimated accurately or broken down properly. This report shows the amount of work to be done in the Sprint. 20. Scrum Ceremonies: daily scrum was is called Stand up Meeting is a daily meeting. As the title says, it's for team members to update the whole group on their latest progress. This group meeting in an agile development world is every team member. Answer three separate questions. What did you accomplish since the last meeting? What are you working on until the next meeting? What is getting in your way or keeping you from doing your job? This tells the team exactly what is getting done. What needs to improvement this thing. Any problems or issues that may have is crucial so that your team would know to help you out. And small problems should always be addressed that they don't turn into big problems. A good trick is also to have your project management tool visible. This could be in the form of a physical cam on board or software like Sprint. If I giri a, which are low, it's important for a team to see what is being finished on what is taking longer than expected. This is especially helpful for teams that spend too long answering key questions, also getting everyone into the habit of reviewing the project management tool record for the meeting results in a big efficiency boost. What about the collaborative effort? So one of the most common scrum meeting mistakes is making a term based one on one chap of the project manager or scrum master. This completely defeats the purpose of the stand up and should be avoidable. Avoided at all costs. This is valuable time that should be treated as collaborative effort for the whole team. A good way to keep scroll meetings efficient is to establish a simple rule. Everything you say should be valuable to everyone in the room. Individual talks can happen at any time of the day. Aside from the standard meeting. Also, plan the meeting around your team. We get that in the real world, it's impossible to adhere to a strict schedule, but it's important to develop some sort of routine for your standing meetings. Without a routine, procrastination will take effect. The media's will never happen. The second ceremony will discuss this spring planning. So this room meeting happens at the beginning of a new sprint and is designed for the product owner and development team to meet and review the prioritized product backlog for a series of discussions that negotiations the team should ultimately create a sprint backlog . This contains all the items air committing to complete at the end of the sprint. This is called the Sprint Gold, so Sprinkle should be a ship herbal increment of work, meaning it can be demonstrated at the end of a sprint. It needs to be agreed upon by the entire team, so the product owners responsible for I am in the product back already for review before spring playing begins. So who's in attendance that? So the scrum team, the product owner development team, all of them which formed scrum team describe Master in the end there. So how long does this thing last? The length of most scrums ceremonies is really it's the length of the sprint. In terms of Sprint planning, it should last two times the length of the sprint. For example, if your sprint is two weeks long, this print playing ceremonies should last no longer than four hours when week sprint should last no more than two hours. Now, this sounds like a huge waste of time calculating time like this. But if you sit in the scroll meeting and it might take more than two hours. You can call it because nothing more important will come out of that. So let's talk about strip spread interviews. Preparation for an agile Sprint Review meeting should not take more than a few minutes at most. So Sprint Review focuses on demonstrating what the development team is done. Knowing that completed using stories and be ready to demonstrate those stories, Functionality prepares you to confidently start to Sprint Review meeting. Preparing for the spirit of you meeting involves the product owner and the development team . The part owner needs to know which uses stories of development team completed during the Sprint Development Team. Needs to be ready to demonstrate completed ship. Full functionality for a development team to demonstrate the product in the Sprint Review, it must be complete according to the definition of done So needs to be developed, tested, integrated document that if that is your definition done as users stories of completed throughout Sprint, the product owner and development team should check that the product meets the standards. This continuous validation throughout the sprint reduces and the sprint risks and helps this time scrubbing teams spend as little time as possible preparing for the spring review . There's a few tips I have for holding a Sprint review. So Sprint Review usually takes place later in the day on the last day of the Sprint, often of Friday. One of the rules of scrums to spend no more than one hour in the Sprint Review meeting for every week of the Sprint guidelines for your Spirit review. Meeting our friends, there's no power point. Slides referred to the Sprint backlog of you to display list of completely user stories. Entire scrum team should participate in the meeting. Anyone who was interested in meeting may attend. So Project Stakeholder sponsors, uh, see yokel theoretical being this being a Sprint review as long as they add and see value. The product owner introduces a release school, so the Sprinkle and the new capabilities included. The development team demonstrates what it completed during the sprints. Typically, the development team showcases new features or architecture. The demonstration should be on equipment as close as possible to plan production apartment , for example, you for creating a mobile app, present the features on the smartphone, perhaps hooked up till monitor rather than a laptop, and stakeholders of freedoms questions and provide feedback on the demonstrated product. No non disclosed rigged functionality such as hard core values of other programming shortcuts to make the application look more mature than it currently is. So always display the real thing. The pro gona can lead a discussion about what is coming next, based on the features just presented. A new items have been added to the product backlog during the current sprint, and I just retrospective is a meeting that's held at the end of each generation agile software development. During a retrospective, the team reflects on what happened in the federation and identifies actions for improvements going forward. Each member of the team answers the following questions. What worked well for us? What did not work well for us, but actions can we take to improve our process. Going forward. Yeah, John retrospective. Give me thought of as, ah, lessons learned. Meeting the team reflects on how everything went and then decides what changes they want to make it a next generation retrospectives team driven and team members should decide together how the meetings will be run now. Decisions we made about improvements 21. Scrum Team Roles: in the original Harvard Business Review paper that inspired the Creation Scrum, the New product development game. Two professors observed that great teams were one transcendent. You have a sense of purpose beyond ordinary, so this self realized goal allows it to beyond the ordinary, into the extraordinary in a very real way. The very decision to not be average but to be great changes the way we view themselves on what they're capable of. Autonomous teams also self organizing, self managing, they have the power to make their own decisions about how they do their jobs and our empire . To make those decisions stick cross functional teams of all the skills needed to complete projects are planning design, production, sales, distribution. Those skills feed and reinforce each other, says one team member that designed a revolutionary new camera for Kennan described it. When all the team members are located in one large room, someone's information becomes yours without even trying. You then start thinking in terms off what's best or second best for the group at large, and not only where you stay. So people sometimes struggled with the idea of transcendence on transcendence can be described as a spirit of team. The first from team watched a video at the beginning of each daily meeting of museums. All Blacks Rugby team. The energy from that team is united in purpose. The first from team wanted to capture that spirit was the determination to crush any impediment spirit to celebrate every success in the golden victory that is team transcendence, whether on a sports team or delivery great products or services. Product managers work closely with the development. Imagine direction of the product based on insights or research. Customer feedback, market research theme. Agile product managers. Gold is to work with customers and company leadership to define the product direction. The product manager is responsible for representing the true voice of the customer. The best way to fully understand the customers problems is to talk to customers. Visit their sites, experienced their day to day business life and stuff. In doing this, product manager will gain firsthand insight. The customer struggles and will be able to find features and functionality. Alleviate the pain points without direct field indirection customers. That's impossible to fully understand that customer struggles and needs is also a product owner within an agile environment and this product owner works with the development team to clarify user stories, product vision and specifications manage backlogs of maximizing products value to business . College owner communicates the business intentions to development teams that they have a clear understanding of why they're being asked to do what they do. They're able to see the full picture, understanding the needs of the business and the customer, communicating with business themes in aligning technical activities in order to deliver exponential exception of product product owners typically have ah basic understanding of software development, their effective communicators and understand that we need to address the customer problems . It is common for product owners toe hold business analyst positions prior to becoming your product. Now the scrum master is at the core of the whole scrum team, so scrub masters are the facilitators extra lightweights, agile framework with a focus on time boxing orations called sprints as facilitators, scrum master's actors coaches to the rest of the team servant leaders, as this from God calls it good scrum Master's air committed to this from foundation and values remain flexible and opens opportunities for the team to the workflow scar. Masters perform a couple of tasks. So they perform standups, sprint planning meetings, sprint reviews and internal consulting retrospectives of one of one's board, administration and reporting blockers. So the score masters role is as well to protect the scrum process itself. This crime master is the expert of house from works and how it should be applied. He or she will ensure that the product owner and development team stay within this from framework By extension is from Master. King coached all the team members on how to use from in the most effective manner. Now this is a very different role from that of a traditional project manager, despite frequent comparisons being made between two. So project managers are responsible for managing the work off project team members and that guides their own day today. Work the scrum master. However, the only formal accountability is over the process. So let's take a look. A development team looking at the scrum, master responsibility, not having the today accountability, but who does have accountability and that's where the development team comes in. So a typical scripting consists of 5 to 9 people and generally includes the typical functional roles were parted company project. This offer development. For instance, that means architect's testers, developers and designers. But those titles are just relevant in establishing each individual's expertise. Now the team acts collectively to determine how to achieve your goals. The specific features they work on are determined by the priority established by the product owner. The way they work is guided by the scrum process as monitored by this firm master. Everything else is up to the team to manage, with scrum master providing as much as needed to allow that to happen. For example, each team member can take a feature from a prioritized product backlog, then decide individually how to execute that work. This level of autonomy is a cornerstone was from and encourages strong bonds between team members and helps create a positive work environment, while the idea of AH team exists in water for projects as well. In that environment, a team is functionally managed by the product project manager rather than being self managed 22. The Product Backlog: the product backlog is slightly different from the Sprint backlog. Aziz, the latter one is drawn from the 1st 1 We know by now that the way we organized working scrum is sprints and the usually last two weeks and before anyone heads into any of them, there's a need for creating that spin backlog. It's a set of tasks that aims to accomplish the Sprint goal. So says the Sprint backlog is drawn from the product backlog. The Prada back A list all the features, functionalities and research that supports product. The product owner is usually in charge of taking care of that problem backlog. Is there anything else in agile and scrum contract by values with the highest value needs to be worked off first based on business value needs research in tech trends soon awful buy in the market. A backlog has organized in that way ensures that our work and provide maximum value for organization. And as you can see, he needs to be constantly updated to manage. That process is called backlog grooming. Without updating the backlog, it can go quite stale and not stay current for very long road map that you're building should contain long term goals for several releases. In the distant future, however, the product back book should focus on listing work for the next release in greater detail. Using rolling wave planning. We ensure that the immediate sprints are addressed in Is there is possible and the far distant ones will replace lower down and details will emerge as you merge towards a specific goal. Products that you create, Let's say, right, sharing up whose ultimate purpose is ridesharing also introduces an all night wallets needs to their back. Now the benefit of using one single backlog a substantial. If your product is massive, let's say an operating system we could look at creating several backlogs. We don't want hierarchy and importance plus value lunch times that conflict with each other . Let's talk about uses to recent epics. Now this is something that we covered previously in the course, but epics is a new one, so let's go through this. We've gone through uses stories before this book, but just them put emphasis on them. They're the tasks you need to complete from the user's point of view, and these are the stories you were off Your Sprint stories are generally very large are called epics, and they could take several sprints to accomplish the's epics of generally stories that contain several stories. It could be 2050 100. Number varies These users stories, though, need to be derived off of the epic. In order for the sprint to begin, one can't work off the net just like that. So let's take a look. At example here Way have, as a large travel website, I want the system. They can determine the lowest prices, depending on variables such in seasons, so that my visitors on the website can receive the best prices now. This is obviously a huge, huge task so needs to be broken down into small uses stories. For instance, as a large travel website, I want to set the optimal rate for flights based on what flights comparable comparatively are charging again. Using rolling wave planning, we set the higher value stories is highest in the chain, but they also need to include the most details. So it's like a dig a little deeper into this and see if we can really drill down on what the users story should contain. Let's look at the use of story getting here as a large travel website, I want to set the optimal rate for flights based on what flights comparably are charging. A couple things I mean to keep in mind here is the function should check fares for all airports within 100 kilometers. The function should give me the ability to sort fares by distance, the function. She give me options to sort through price and the function. She gave me an option to sort through airports as a departure and arrival. So you see how when it's a greater detail here and I would add more value to the story. More clarifications to the story so we sometimes turn to different stories that are not needed, adds user stories. This would include work on the back end or other tasks that aren't really meant users, for instance, internal admin dashboards or de au dashboards that we need to keep it. I ought to moderate KP eyes. These tests are important to distinguish because they use something called feature driven development F double deep secrets. This is very simple, so you always have an action, have a result, and you have the object. So, for instance, If we're looking at a regular long in sequence, we will look at it like this. Validates plus password plus user. This is their only four items that we deal with in our scrum backlogs in the Sprint Press product. It's features bugs, technical work and knowledge acquisition. So these are the only really only four that we need to have our backlog. There's only categories. A good way to start building out your product backlog is to throw all of your ideas on the wall and see which ones carry the most value. As long as you have enough value driven stories for your sprint, you're fine. Keep it simple and break it down again as per value. Next up, we're gonna look at how to prioritize your product. Lifelock. 23. Prioritization: Now that we know what we need to include in a backlog, how we prioritise, let's take a look at how we build and work with a product backlog. So to do that, we're gonna go through a thorough checklist to ensure that we address all of the areas that we have. You as a product owner are solely responsible for the product back. You're in charge of maintaining it with all your research features and planning. Based on the organization's roadmap vision. Product backlog is a complete list of all users stories work items for your product. However, you can always update it with more changing requirements and that more insight as you go along, you need to be a specific as possible. With nearest prints and goals, distant ones could be shrouded in mystery. For now. Always use the user as a point of view. Include bug fixes, knowledge exchange and other technical internal works such as we mentioned before FDD stories. You rate the value in priority of all these users stories. Your research and specific insight into customer wants and needs drives the product back. You don't need to look at an estimation right now this print planning session and catch ups with your team will help you do this. Need to rank your product backlog. Your product backlog is an ever flowing list of changes and adaptions. However, your sprint shouldn't change. So the Sprint backlog is agreed upon and Onley unlocked When definition of donors finally being been met, you can always add to work into the booth, so let's take a look at how we prioritize this product backlog here. As a shopper, I want to view a list of products so I can select some to purchase, Obviously Value 21 Priority what? As a shopper, I want to review my cards that I can make adjustments prior to check out 21 2 As a user, I want to check out so I can get my probably shipped to me 13 and three. As a shopper, I want to review my order. Second, see what I purchased in the past. That's an 84 Now. The way we look at the backlog refinement process is what we referred to as the Deep Acronym. The stents were detailed appropriately so that items at the top of list have more detail than those at the bottom. Remember, this is what we call the ruling wave planning, where the immediate school immediate requirements are very well known. But the far away once let's talk six months a year down the line we don't know so much about once we keep rolling. Once we go along with a project, we find out more, more, more, and that later is not shrouded in mystery anymore. He needs to be estimates each product backlog released. Those involved in the next release should be estimated by store reports or time. As your team gets more work under its belt, its velocity, the rate at which it finishes item from their product backlog will become clearer and make estimating easier. Emergent. This means a product backlog is adapted to new items or information that emerge prioritized . All items on the product backlog are ordered with the most important ones on top. 24. Product Vision: working on the product without a recent product vision resembles going into the street with your eyes closed. So to advance a product or life direction helps keeps things going and makes actions meaningful. On the other hand, the leader has a responsibility for leading and guiding of this as well. Pios and managers need to keep business plans and customer trusts in mind while motivating everyone to work towards a common goal. But without direction, a team can't thoughtful, and that's where we're going to talk about in the product vision and how the direction helps teams move forward with an agenda with a mantra. So when we discuss vision, we have in mind a long term plan for the product. These are plans that are far away, and they are yet to materialize. These are far away goals but nonetheless prove your business ambitions. And the future problem solving aspect of vision is usually a 2 to 5 years time or even more depending on which product you're making for which industry. So what? Isn't this just a bunch of nonsense with no immediate impact? Not really. I mean, using a vision team can define the public ALS or got a strategy on how to reach in schools , device strategies and tactics and break them down within your product world map We discussed earlier. Let's take a look at Google's vision statement because I think this is a great one. Was Vision Statement is to organize the world's information and making universal of a university accessible, useful, so to look at it in a very easy way, you're a tour guide and you're hiking across MT. You have your guide group with you and you know the route you're taking direction, you're going in. Your vision is to take them to see beautiful mountain tops, waterfalls and maybe even catch some wildlife here. So without this vision, your tour guide group will be lost in their direction. It wouldn't know why they signed up for the tour where they're headed. Vision should be a basis That guy's decisions and helps prioritize features or tasks. Does this feature element at on or contribute contribute to the gold? If not, then you channel your energies into activities. The truth Motivation also plays an important role here. Reminded team that time is that the direction so they understand how their roles in daily activities contribute to the bigger picture. This helps them focus more on the work that really makes a difference in terms of product development. Motivation also plays an important role here, reminded team at times of the directions, so they understand how their roles and daily activities contribute to the bigger picture. The soapstone focus more on the work that really makes a difference in terms of product developed. So let's explore number ways of creating a product vision. First sit down and based on what problems or pains customers face and how the product solves them. Or was the production achieve those? Some might find it obvious supposes more challenges than expected. Who should take partner process? And the complex task Vision creation requires a lot of teamwork, So what you do is invite teammates or other stakeholders who can contribute to the bigger picture are providing professional knowledge, passion or visionary skills. Anyone could really join developers, designers, researchers, business or marketing People could all fit in here, but make sure to lead the creation flow of pushed a team to come to a final understanding that was thinking. Look at the questions you ask one of them is Who is your target audience? Which customer needs? Can the products satisfy which product attributes determines satisfaction of those needs? Who's competing and how did they perform internal external competitors? What time frame and product about a budget determined the project, So it together in a team of people in mind, work of the visionary statements and lead a workshop on topic formed smaller groups where people can discuss some brainstorming different questions. At the end of the first session, each team should come up with a list of agreed upon insurable ideas or answers to after every team has presented their ideas. Put the ideas of the vote. So to select only the best ideas. Use different methods against utilized teams abstract thinking and always keep your track of progress and make everyone feel involved. You also have a couple other questions you ask. We could take a look at the product vision Port Product Vision Board, made by Roman. Picture defines in a different way, so you have a vision which we will be filled out later, but you have a target group, so you define the target audience. Who needs the product will satisfy look at the needs. What do these customers? What solvable pains and challenges to the face. Look at the products that you define the product, generic attributes or futures and contribute to customer happiness. The business schools are very important, so you need to have a clear picture how the product will benefit the company and what the business goals and aspirations led to its creation. So when aiming for something short and catchy for your product vision, you can use Geoffrey Moore's product vision template as well the basic for my runs as follows for Target customer who customer that needs to be solved. The product. The name is a product category that benefits heating, selling points. Unlike competitive product, our product, I mean, difference. So with this tool, we grabbed essence in the uniqueness of the product. While they're finding the apes, this meant that can work well in an agile environment. When you start developing as well, a vision doesn't have to turn into 20 paint Bible or a shiny poster Bhutto wall make statements convincing ineffective. So the father of visions, Roma Pickler, calls the ideal product vision clear, unstable. Every participant should find it easy to understand. So avoid empty phrases that don't say anything a case and bullshit broad and engaging. So we should depict a higher picture that everyone can relate to and then inspires people to give their best to make it happen. Shorten. This week he needs to get straight to the point additional. You make it achievable. So although a vision should be futuristic, idea what the product might become cynical, they could be actually met. Insightful. So you need to craft the idea based on users needs and motives, and to find the main reason behind that others existence. Nike is vision and business idea is actually really, really cool. So at a key, um, our vision is to create a better everyday life for the many people are business Idea supports this vision by offering a wide range of well designed, functional home furnishing products at prices so low that as many people as possible will be able to afford them. Finally, you present the product vision to everyone involved. Development stakeholders must know the direction they're heading, so they can maintain confidence in the daily tasks and decisions. Share the vision any form presentations, boards, posters, one on one meetings, etcetera. You transmit the message so everybody understands that you can connect to it and be honest about it. Encourage questions and also present use cases. Sobering examples are vision effects, business strategies or lower level decisions. Speak the language of the product visions audience and show them how they can contribute to the betterment of the product. 25. Product Roadmap: product. Road maps are an important product management tool, but applying them effectively can be challenging. Road maps are too often focused on features, and product managers spend too much time getting a stakeholders to agree on one which features will be developed. A product road map is a high level strategic plan, which describes how the product is likely to develop and grow over the next months. This creates a continuity of purpose and helps their product managers and product owners a choir funding for the project, airline stakeholders and also facilities privatization. It makes it easier to coordinate the development in larger, different products, and it provides reassurance to the customers if their product roadmap is made public. Now let's take a look at what are the product road maps that we have here? Let's take a look at this chart, so the first throw off the road map depicted above contains the date or time frame. For the upcoming releases, you can work with specific dates such as first of March or a period such as first or second quarter. I find dates particularly valuable internal maps. Refuse an external one. You may want to remove the role or use loose time frame, such as in the 1st 6 months of 2014 2nd row states the name or version of the releases. For instance, I was seven or would knows Quinn won. The third row provides a specific product goal of each major release for product version, the user business benefit that should provide or the outcome you want to cheat. Sample goals are to acquire or to activate, users to retain users by hands and user experience aboard. To accelerate development by removing technical debt. Working with goals shifts the conversation from debating individual features to agreeing on desired benefits. Making strategic product decisions on a development team, key stakeholders and the management sponsor should all buy into the goals. Four. Throw here provides the features necessary to reach the goal. The features Our make means to end, but not an end in themselves. They served to create value and reach to go. You can think of the features as the output required to create desire to try to live in the number of features for each gold to three. But do not state more than five refrained from detail in the features and focus on the product capabilities. They're necessary to meet the goal. Your product robot should be a high level plan, and the details should be covered in the product backlog, including epics, and use the stories. 26. Release management: product owner, as we discussed before, is responsible for the product backlog but also ultimately responsible what you delivered to the customers. You need to plan this and also come up with a strategy on how to release what, when and how. Let's take a look at a few things to keep in mind. As mentioned by Robin Sherman from The Home a scrum you need to consider your audience so your target audience should drive all the decisions continues. Delivery of value is obviously one of the cornerstones in that job continues deliveries becoming very popular. And a lot of people want to be able to do a new deployment of software practically every minute. Of course, it's very helpful to be able to release a little effort with the push of a button. Whether or not you will actually use it depends greatly on the context. So called some context, like Amazon's releasing multiple times a minute, seems to have a lot of value in other context from working on HR payroll systems, for example, release once a month enough. At least that was back in the days. Number two is create one, releasable incorrect for Sprint. So in many organisations, teams are working very hard on a lot of different things in the sprint. This often results in the team having 100% of the work, 80% done. Bottom line. This means that a lot of work has been done and no value for customers. Users have been delivered since it's not finished. Done so help the development team offering focus with a Sprinkle. For example, support the development team to deliver a done product increment as early as possible in the Sprint, which is helpful since you will at least end up with one increment that could be released if you want to. Number three is get ownership of the release process or, better said support the development team in getting ownership over there. With these process and many organizations doing releases to production is something that is owned by a department such as policeman. These coordinators. When the development team doesn't have ownership over the release process, it is often more difficult to do release. Nothing cost you as a project manager or product manager overall valuable time, but I've experienced to be very helpful in the past is to provide a development team with ownership over the release process. This is something nor you nor the development team can often decide for yourselves. So what can you do as a product owner you can do is to create transparency about this topic . Turness primitive For example, when your steak was asked me, How can we become faster? How can we deliver more value? Then help yourself and the development team by raising awareness about the release process when we really only release work that is done in many organisations. A lot of teams are releasing undone. Work was undone work that is released a production but which isn't derived to conform definition of done. This creates technical debt, which costs you a lot of time. A lot of money to fix it would cost your valuable time. But you don't spend on delivering value for your customers and users to respect the definition of 27. Problem Solving - The 5 Whys: Hello, everyone. So in this class we're going to talk about the basics of the five wise understanding them how to work with them and what the whole golden orientation of this is. So one of the many reasons why have five wides is so popular as a root cause and analysis technique is its simplicity. So whenever an issue or problem occurs, you just ask why the problem occurred at least five times to the people working on it. There's no fantasy steps. No acronym is. There's no need for any memorization and drawing big diagrams. Five questions. Five ways, though, work on a premise that every problem has a cause behind it. But a superficial allows says for only depict symptoms, right? So persistent enquiries required to find the rial calls the route calls behind the issues that lasting solutions can be taken and the problem doesn't resurface. So now we're gonna move on to understanding our five wise with examples. So the gang example one from for instance, ah, business development domain. You're working with a client, so problem statement is, our client is refusing to pay for a website we created. First question is a wise of time refusing to pay well, because the apple too many bugs. Why didn't have too many bugs? Well, we didn't manage to regression tests. Why didn't you manage to do regression testing? Well, the timeline and launch forward set. Why was the time in launch already set? Because this is how the project was sold in. So why was the product sold in this way? Because the business development people didn't have enough inside of development to pitch a plan that allows for regression testing CC. We needed five wise to finally decipher the project was sold in with lack of knowledge about software development cycles. Let's look at another one. So this comes from you know, you 18. So why is the issue been encountered by the client? Well, according to the tech lead, the testing team has not reported any such issue to development. Okay, so why wasn't the testing team able to catch the issue? Testing team performed sandy testing and not complete regression testing. Why they only perform sandy testing because it didn't have enough time to perform a thorough, functional testing of the complete application. So why wasn't enough time for functional testing? Because it builds came only one day before you 80 timelines and they're a functional. Testing takes like three days. Why was it billed given only one day before you 80 because of Development Team took more than the estimate time, resulting some bugs. So, as you can see in this example, we see that there are two root causes, not just one. So first ones that the team members weren't able to give correct estimations around the functionalities. And there's a need for training on estimation techniques in the implementation second causes. There's an issue with the project management as ideally, a code free should have been at least four days before the U 80. But here the team was working on fixing bugs at the last day. Um sees a kind of situations that come up sometimes. So let's take a look at what we can do to actually conduct a five step analysis in a very efficient way. Number one is you obviously have to gather the relevant team members. So the rationale behind gathering every relevant team member is to get a different viewpoint of the problem at hand. So every member has his or her own way of looking at the problem and listening to the accounts of all people associated to the problem, and it gives you 3 60 degree view. This is something that's very important. We're looking at the root calls, so Number two will be to define the problem statement, right, So once the team is available, it's time for the actual problem to be defined. The scope of the problem should not be too big, or you're gonna end up having lots of root causes, and it shouldn't be too narrow as well as you might end up treating the symptom. So the problem statement should be balanced brief While giving a clear explanation of the issue being faced. For instance, the servers crashing too often. And while the finding the problem you may want the individual members to find what they feel is issue, make a list of their responsive Now these responses can then be discussed to reach a consensus of the problem statement. Now, if we look at a very, very simple, broken down version of this five step analysis is, for instance, my goal is that I want told my own business, Why do I want this task. And again, why do I want this task again? Why don't want this test? So in the end of the day, it allows me to support my family because it's the most important thing to me. That's that's court s always go to the court with five wives. You might even have to have six. If that's the case, Um, by asking why, um calls on you to ask your team members why the problem statement has occurred. You obviously know down the responses and each step, the answer should be noted down. It should form the basis of the next Y. Since five white technique depends on the cause and effect relationship, it's imperative to ensure that responds to every why is a logical answer is backed by proof . You're wondering why we have to repeat the process of asking why five times. Then here's the answer, which is asking why one or two times was equivalent to just scratching the surface and treating the initial symptoms with a problem to resurface sooner. Trying to probe the reason behind each of the answers would get you past any guesses or speculation around the problem. So once the actual root causes on earth than it should be discussed separately to find the corrective action and counter measure to ensure the problems. Finally, tackle will not happen again. This is basically the puddle on the floor situation we talked about before, so puddle on the floor is due to leaking pipes. Why the pipes thing? Because they weren't drilled? Probably. So why would they built properly? The other more problems? You won't have problems with the infrastructure at home, so always ask more wise. So a couple advantages with this is that encourages collaborative problem solving it. Agent. Reaching amicable consensus on areas with issues rather than fault finding or blaming individuals. It's simple, easy to follow process without requiring a statistical analysis, but with everything is also limitations. And you should know about these limitations. You can counter them in your meetings or mitigate them with some kind of plants. So sometimes just not possible to isolate a single root cause to this technique. So make your problem statement smaller, shorter or identify several root causes. If you're fine with that, if the product is really going to help, it's a time consuming technique, though it involves deep probing a thorough evaluation of all the facts. Um, the success of this technique is dependent upon its participants. So if relevant people are not available, the remaining group may not be able to find the correct answer to the white question. Um, so you guys, that's it. That's the five wise. And there's a sheet in the class for you to use, so go ahead of yourselves up way . 28. The Fishbone diagram: So speaking of problems now on how to solve them, let's take a look at our first solution of first tool to solve problems. It's the fish bone diagram. So one particular example that comes in mind when explaining the fish bone diagram is the puddle on the floor and its essence. It is saying that the puddle on the floor exists because of a root cause. Instead of mopping it up and buying more towels, the root cause needs to be explored and fixed. These are the steps we take to identify the root cause. Seven. Causes me to list in the Fish bowl diagram often used in marketing. These are products service price, place, promotion, people, personnel process, physical evidence. Now let's take a look at an example of a fish bone diagram, because I'm going to draw it up for you. So let's say we're behind schedule and would like to find out why we could have issues with the equipment, the process people, materials, external environment management. We look aside, the causes. We see additional issues, for instance, equipment, inferior equipment, inefficient workflow, improper training, improper materials, client delays or delayed approvals. Management might have delayed approvals as well. You might see some secondary causes in all this is well, so presence and process you might see on optimized steps. We could have a very redundant were working. You need to trim this down. Or we could be looking at a duplicate of work which causes a delay, perhaps have been right in the same code to solve the same or different problem. Maybe our materials have had poor quality. Would be using the wrong testing devices with this process. We really investigating the causes behind each of these problems within our project. If we do know how to prevent this particular issue market with a seat, if we don't know yet, we can find out, we'll mark it with an X. We can't prevent it, nor Detective will mark it with a net. See usually stands for new work procedures. X needs of research and trial and error. The end need some protection, whether it's more assaulted, school work or better contracts 29. Planning Poker: in this lecture, we're gonna talk about planning book so this can be used with Lord Porn's Ideal days or any other estimating unit that you have. Honey Poker in Scrum brings together multiple expert opinions for the address estimation of a project. So this type of agile planning includes everyone. So Programmers Tester is database engineers, analysts, user interaction designers and all other personal involved in the project. Because thes team members represent all disciplines on the suffer project, they're best suited for the estimation task. The whole point of using planning poker is that it's, ah, process that forces you to break down departments into such small parts that it becomes possible to correctly estimate the time needed for each bit. So anyone was that builders of workers at all knows the estimated time is complicated. It's not possible to estimate time for tests that are too big, so it's possible to determine approximately how long it takes for a place. A window was totally impossible to judge how long it will take to rebuild the whole house. So the activities you estimate time for planning poker must be so small that it possible to estimate how long it will take to perform them. So most teams will hold a poker planning sessions shortly after an initial product backlog is written in these sessions, which can take several days. They used to create initial estimates, which are useful in sculpting reciting your project. Um, because problem back look items, often a user's story form will continue to be at two throughout the project. Most teams find helpful to conduct subsequent agile, estimating and planning sessions once per generation, typically held a few days before the under the adoration immediately following a daily stand up. Because the whole team missed all together, so each person was a part of. The estimate team is holding a deck of cards with you, but not your values, such a 0 to 21. So I've seen planning cards go up to 100 but we're defining. Major complexity is 21 instead, so you generally don't see appointed raising higher cards of this. And the team that's estimated needs to ask product manager owners questions. If they seem very unclear. So what's clarity has swept through the room. The team present their own individual estimates by playing one card from the deck of cards . Important to note is that everyone needs to reveal their cards at the same time. If we're all playing the same number from our decks, that means that we're in agreement about the story point. Should we not play the same cards? Team needs to discussed arrest. And once the discussions led to conclusion, the team then repeats to reveal process with further story points. But for the user stories, if there's no agreement on certain uses stories than this is, the basis for further research has held off until further information is required. So with that said, let's take a look at, ah, planning poker session year old quick eso we're looking at as a user. I want to view a list of products so I can select some to purchase. So we have Joe, Michelle, Richard and Lana, and they're all going to estimate. So the estimation is Joe on five. Michelle 13 Richard five long three. Now you can see that five and three isn't that large, So a little bit of discussion could help raise the bar to five right in the three, just to add in a little bit of complexity. And they're a little bit of buffer, but 13 is kind of worried. What does that mean? That might mean that Michelle has not understood the requirements. My mean, that Michelle has a different take on what is going to happen once it reaches testing. Might be that there is a lot of complexity around the back and systems you're going to work through eso This kind of helps and I guide to say Okay, Michelle, let's have a talk about this later. So you close that right there, move onto next user stories that you want to They want to estimate. 30. Agile Transformation Challenges: When I first started out as a scrum master, I was understanding of how Mr Roll actually required of a new scar Laster leadership team structure, product strategy, technical practices, change management and coaching. I was looking at me meant toward before some scrum master's coming out. This can be a tricky path walk in many king and confused and caught up in all the skills they need to know. Today I see the same thing happening where organizations do want to go agile but don't want to put in place enough initiatives to achieve that certain agility. They focus on scrum in camera. But as we know already, Agiza philosophy and if you will scrum is just a tool. If you don't know how to build a house, the planks, concrete and glass are of no real use. Organizations may focus on improving engineering practices. They may even send people to attend training courses and there's an expectation that this will be enough. Improvements will come rolling in. This, of course, doesn't address the core of the problem There murmurings of we tried agile. It doesn't really work here. We work with a client like this. You have to dig very, very deep to understand wearing the transformation. Things got a bit skewed mostly, and I say this without most confidence is the mental part personal adaptability and ability for people to change that, go over their fears and face certain risks. Like me, my really scrum master days. Many coaches and consultants are focusing narrowly on one small piece of the puzzle. While overlooking vital pieces of information. Without bringing these into focus, Chances of improvement aren't very high. I do accept that the split about to tell you about is a larger artificial split, and one cannot address the domain in isolation. They're all highly interconnected in each domain will influence each of the other areas. So I make the split largely to raise awareness of the things which should be on the radar leading a transformation. So let's six. Let's explore each domain leadership. Organizational culture of people in the gauge meant governess of funding and ways of working. Let's start with leadership management. I often hear it said that leaders should support or buy in to the change initiative, and I agree and disagree. So, in my experience, a great deal more. The support is needed. I believe the change needs to be actively driven by leadership. These themselves need to go through deep learning and growth in the role and it all starts there. There are many ways that leadership management of a truly agile organization are unrecognisable from traditional versions of the rules. Vital shifts include a shift from Directive two supported leadership, a shift from centralized to decentralized authority, a shift from focusing on the work toe, focusing on direction and creating the environment for success not just with words but with structural of policy changes to enable the changes to happen. These changes can't be driven from the bottom up. They need to come from leadership. Let's look at organizational culture. So in the 12 version of one State of Agile Report, it says, organizational culture at odds with agile values was once again the number one challenge when adopting and scaling agile it was highlighted by 53% of the respondents, is continually emerges as a number one inhibitor to increase agility. So the first step is to understand the current and desired culture organization. THES will either be well aligned or in conflict with achieving greater levels of agility. If the desired culture is on one of those which is in conflict, then I would question where the transformation should go ahead. This can prevent a lot of waste of time, money and effort, and it tends to be better to help people improve inside the parameters of what they value when, whatever that may be. If it is decided that the culture needs to be shift, that needs to be carefully planned, one does not just change culture by trying to change the culture. Culture is a product of the behaviors, values and beliefs of the people, within an organization or within your department or with a new team. Cultures can only be shifted by changing those specific behaviors. These new behaviors must be supported with new policies. Only then will the culture shift in the way. This is another key enabler of agility, and it must not be ignored. Let's look at people in engagement. So a modern businesses, the rules of the game have changed. There is no longer any doubt about the link between employee engagement and business results. Whichever dating you look at the results are the same companies with engage employees significantly outperform their competition. Is that a managing for obedience and diligence, as was effective during the Industrial Revolution, we now need to match for creativity, initiative, passion. This will help to attract and retain the most effective employees and will give a huge competitive advantage in today's complex knowledge economy. Is it any wonder that in the state of the Global Workplace Report by Gallup 2017 only 15% of people pulled were engaged in their job organizations are wasting human potential or not getting the best other people? This is bad for people and bad for the business. So to create high performing adapter organizations actively managing for engagement is the must. This involves reinventing many outdated HR policies for the 21st century knowledge worker for governance and funding. A question I hear all the time is How can we be agile? Will need to sign off scope costs and timelines up front, and they cannot be changed without revisiting the business case. Well, you can't short answer a waterfall based governance model which insists on big upfront analysis and design. The creation of detail, business cases, strict change control and funding large batches is not a model design fragility. Quite the opposite is designed for rigidity and makes a whole lot of assumptions, which do not holding complex developments. Assumptions like we can know what to build in advance. Things won't change much as we progress and save the place big bets about their assumptions when the money spent this fundamentally incompatible with many agile a purchase. Such a scrubber camera changing how money is invested from plan and predict to experiment and adapt is a huge mindset ship. Placing many small bets and course correct and based on feedback is the least risky way to proceed. But organizations need to be set up for that. So ways of working is the domain in which most organizations dedicate the majority of focus . Whether it's implementing agile frameworks such a scramble, Cambon or the Spotify model, or even improving engineering practices. This tends to be the starting point, most for seeking increased levels of agility. The problem is that focusing on ways of working with all but guaranteeing that agile doesn't work here. The reason it won't work will be that organizational leadership changes needed to create environment physicists did not happen. The frameworks mentioned above can be very valuable wouldn't applied in the right context. So the organizational culture legend, which lends itself to a certain approach any adjunct coach or consultant to advise us starting with particular framework without understanding the context, culture, desired outcome and attitude to change. It's someone who probably does not have the experience to be advising you on your transformation. I see this all too often. It's a failure of the actual industry processes, practices and frameworks are important, but they will not achieve results in isolation. 31. Growing Great Scrum Masters: the biggest problem and fear you will face is an agile coach is to fail. Your mission in your client's a problem that leads agile transformations that are unsustainable and not flexible enough as a target organizations but misjudged during my years. I've seen this happening a few times and they can get quite rough. Therefore, I want to create a bonus lecture out of it. But I began working as a scrum master around nine years ago. Now I had attended the scrum master course, but as we all know, theory is different from practicing it in real life. I'm talking about soft skills, interpersonal skills, product knowledge, subject matter expertise. Luckily, I was working with some of the best mentors around back then who could guide me and show me where and how I can find my answers. Finding my feet is the scrum Master wasn't educational journey, but often new scrum master's choose your own adventure without proper guidance. So how do we address this issue and where do we start? Having worked across several agencies? Nigel Coach, we tend to become more of consultants within those organisations. When the project is over, we pack up and leave behind us, an organization that was highly dependent on our skills to make the problems. They've been clear, though many organizations that embark on this agile journey do not see the value in investing in a satchel journey. So leaders scrum Master's product owners team members they only to learn lots of new skills and techniques, techniques that are often different as to what they're used to to take a shortcut. Companies therefore hire consultants. Nancy Kline did put it the best way in her book, A time to Think the most valuable thing we can offer each other is a framework in which to think for ourselves. So let's take a look at how we grow in train scrum masters to deliver that value. Now the framework of independent thinking can help them grow. I strongly believe that drink my years is Grandmaster Nigel Practitioner. I have found three pillars that work well for scrap master growth. One of them is leadership who understand the importance of up Skilling. People are willing to invest in it. Second, being coaches with experience in the track record in growing a schoolmaster capability 1/3 on being a systematic program of training and on the job coaching to cover the appropriates governments or competencies. So they're all effective and how people can apply them is Lian Cambon Scrum XP. In the accompanying practice and patterns, that should be second nature, but people progress through the levels. They should begin to investigate more bodies of work, including systems thinking, complexity theory. In queueing theory, Teoh compliments broaden their knowledge base when it comes to grown organizations. Crime, Mr Capability. I tend to use a combination of teaching, mentoring and coaching majoring elementary. Given the broad scope of the scrum master roll, I've observed the best result in splitting the rollout. It's a high level competency areas. While asking 10 coaches were probably yield, I'm told answers after much experiments have found the falling split to be effected. Facilitation is something the scrum masters must quickly get good at. These could include the scrum ovens, story mapping product, world mapping workshops, backlog refinements and countless others. The ability to remain neutral and visited facilitated group discussions and decisions making is key, as is the in viable skill of designing and delivery. Engaging ineffective sprint restaurant retrospectives. Team dynamics is crucial from scrub master as protesters as they must always have their eye on the dynamics of the development in this county, they must understand how to facilitate the creation of AH team, working with an agreement, a shared goal and mutual accountability for achieving it, they must understand how to build trust, to navigate healthy conflict. They must help to build an environment of psychological safety. Social capital in collaboration. Helping individuals work effectively as a team has time and time again proved for more effective than merely hiring the best individuals. This is some product is a key responsibility of US Crow master. That means being a student of product management. This includes coaching the creation of compelling product vision strategy and a road map. In addition to this, it means helping the product owner with techniques around product backlog management like discovery and splitting user stories. Organizational changes, The most ignored aspect of the rule is always coaching the development team in the product Owner scrum masters are expected to coach organizations. In my years of scrub Master, I found this suit. This becomes the most important part of the role once the team has picked off the easy wins at a local level, the constraints tend to move to the organization. Maybe they chart policies are incentivizing individual ism over teamwork. Maybe infrastructure will not let you easily deploy to the test environment. Maybe governance policies is slowing you down. As a scrum, master, you must be willing to tackle these impediments. That means educating people way beyond your area. Now they could ate the team's agility and being an agent of change, coaching, mentoring and teaching is all about helping people to grow and develop new knowledge and skills, from the more directive side to teaching to less directive side of coaching skills a related. So I keep them together. Either way, they're all things that scrum master should be able to do to varying degrees in the spirit of helping people and teams continuously improved out this system of self assessment. Each of the above areas helps people identify their strings areas and where there's most scope for development. This then drives a constructive coaching and mentoring conversation centered on where they are now, where they would like to be and how they can work to achieve that growth Theatre count ability sits firmly in their hands were there their own targeted workshops to listen the questions, plant seeds and guide them through the process of developing themselves. We can point to books, articles and videos that you inspired me over the years we cannot do is a choose that path . 32. Congrats! You completed the course: Hey, everyone, this is the end of a course. But it's not the end of the journey cities Any more feedback that you would have anything more. They would like to know that. Please do let me know in the comments section, and I would get right to the last thing I want to see here before we get out of this course . It's really fundamental to the road. You do have to have a lot of these skills that we've been talking about in the course and don't get me wrong with very, very important. But the key skill to be an adult court or a scrum master is to pay attention to a lot of detail. Thes decisions mean the price inside the data to make tough decisions every day. And we also need to have a consulting approach to the senior management in the client working with us at this moment. I'm so glad that you guys have joined me on this journey. Uh, learning about something that I loved doing myself. So wherever you are in the world, whatever you're doing, be proud. Be happy, be motivated. Stay in touch and congrats on completing the course.