Unveiling the Agile Mindset

Agile Essentials: Exploring Fundamentals and Frameworks

Estimated read time: 1:20

Summary

In this enlightening video by OeLean, the host embarks on a comprehensive journey through the agile methodology, emphasizing that agile is not merely a methodology or framework, but a mindset characterized by a set of core values and principles. The video recaps the history of the agile manifesto, highlighting the differences between agile and traditional waterfall approaches, and explores popular agile frameworks like Scrum and Kanban. The adaptability of agile during crises like the COVID-19 pandemic is discussed, underscoring the approach's relevance in uncertain times. Overall, the video serves as a detailed guide to understanding and implementing agile principles effectively across various organizational contexts.

Highlights

Agile emphasizes human interactions and continuous improvement over rigid processes 🤝.
Scrum and Kanban are popular agile frameworks that enhance team collaboration and workflow 🚦.
User stories and backlog refinement are crucial for aligning team efforts and ensuring product quality 🔄.
Regular feedback loops in agile help teams adapt quickly to changes and client needs 🔁.
Adopting agile has shown to increase business success and employee satisfaction in numerous case studies 📊.

Key Takeaways

Agile is not just a methodology; it's a mindset focused on values and principles 🌟.
The agile manifesto, created in 2001, established four key values and twelve guiding principles 📜.
Agile methodologies like Scrum and Kanban improve flexibility, efficiency, and customer satisfaction 🏆.
Unlike waterfall, agile allows continuous user feedback and iterative product development 🚀.
Agile thrives in uncertainty, proving especially useful during crises like the COVID-19 pandemic 📈.

Overview

The video begins by challenging common misconceptions about agile, clarifying that it is a mindset rooted in flexibility and a commitment to certain values and principles. The origins of agile are traced back to the famous 2001 gathering in Utah, where industry leaders laid the groundwork for what would become the agile manifesto.

Following this historical context, the discussion turns to contrasting agile with the traditional waterfall model. While waterfall emphasizes a linear and phased approach, agile promotes an iterative, customer-focused cycle, allowing teams to incorporate feedback and adapt rapidly to new information. Notably, agile's effectiveness during times of crisis, such as the COVID-19 pandemic, is highlighted, showcasing its utility in maintaining productivity under uncertain conditions.

Towards the end, the speaker delves into practical applications of agile frameworks, focusing on Scrum and Kanban. These frameworks exemplify agile's core principles, underpinning the importance of elements such as team roles, backlog organization, and performance metrics like velocity. By embracing agile, organizations can foster innovation, responsiveness, and a heightened focus on delivering true value to customers.

Chapters

00:00 - 02:00: What is Agile? Agile is often misunderstood as merely a methodology, framework, or a specific set of practices in software development, like standing up in meetings. However, the core essence of Agile is that it is not these things. Instead, Agile is a mindset encompassed by a set of values.
02:00 - 04:00: Agile Values and Principles The chapter discusses the origins of the Agile Values and Principles, highlighting how 17 individuals convened in Utah, USA, in 2001, to develop a new methodological framework. This initiative aimed to address the limitations of traditional work methods, thereby adapting to evolving customer needs and work environments. The outcome was the creation of the Agile Manifesto, which emphasizes four core principles.
04:00 - 08:00: Agile vs Waterfall This chapter discusses the fundamental differences between Agile and Waterfall methodologies. It highlights the four core values of Agile: (1) prioritizing individuals and interactions over processes and tools, (2) valuing working software over comprehensive documentation, (3) emphasizing customer collaboration over contract negotiation, and (4) prioritizing responding to change over strictly following a plan. The significance of the word ‘over’ in these values is stressed, indicating a preference rather than a complete disregard of the latter aspects.
09:00 - 16:00: Agile in Times of Crisis In 'Agile in Times of Crisis', the focus is on understanding the balance conveyed by the Agile values and principles. The Agile manifesto acknowledges the importance of the items on the right of the values list, but places a greater emphasis on the ones on the left. The chapter begins exploring how the 12 Agile principles aim to enhance customer satisfaction, even during challenging situations.
17:00 - 24:00: When to Use Agile? This chapter explores when to use Agile methodology, highlighting its benefits such as embracing changes, speeding up delivery, enhancing collaboration and empowerment, ensuring effective communication, and using good metrics. It emphasizes operational excellence, simplicity, self-organization, and continuous improvement as key aspects.
24:00 - 27:00: Scrum Framework The chapter 'Scrum Framework' discusses the principles of the agile mindset, which are designed to be broad and flexible rather than prescribing specific methods. The focus is on providing a foundation for making informed decisions in various scenarios. Organizations of various sizes and teams engaged in diverse activities are increasingly adopting this mindset, allowing them to better embrace changes and respond effectively to customer needs.
27:00 - 34:00: Kanban Framework The chapter titled 'Kanban Framework' discusses the differences between Agile methodologies, such as Kanban, and traditional methods of project management. The transcript begins by mentioning the goal of improving needs and performance. It then refers to a previous video that explained what Agile is and hints at a further exploration into the distinctive aspects of Agile compared to more traditional approaches.
34:00 - 39:00: Scrum vs Kanban The chapter explains the concept of the waterfall model, where projects are managed in phases executed in a linear and sequential manner. Progress moves in one direction, similar to a waterfall, with each phase representing a distinct stage that must generally be completed before the next one can begin. The waterfall model organizes projects to be finished within a certain timeframe.
39:00 - 51:00: User Stories in Agile The chapter discusses the drawbacks of the traditional waterfall project management model, focusing on fixed budget, scope, and time constraints. Despite meeting these parameters, customer dissatisfaction was common, mainly due to insufficient customer involvement throughout the process. By the time the deliverable was produced, it often no longer aligned with the customer's evolving needs, highlighting a fundamental flaw in this approach.
51:00 - 60:00: Definition of Ready and Done The chapter discusses the limitations of a traditional linear approach in product development, highlighting its resistance to change and difficulty in integrating new ideas, which can negatively impact customer satisfaction and product quality. It introduces agile methodologies as a solution, emphasizing the use of its four values and twelve principles to foster a more adaptable and innovative development process.
60:00 - 70:00: Story Points and Velocity in Agile The chapter discusses the Agile methodology of product development, emphasizing incremental and iterative processes. Agile teams focus on delivering value to customers swiftly while minimizing potential setbacks. Instead of relying on a 'big bang' launch, teams deliver work in smaller, manageable pieces. The process includes various stages such as design, development, testing, and deployment, consistently applied to each small piece of work.

Agile Essentials: Exploring Fundamentals and Frameworks Transcription

00:00 - 00:30 what is agile there is law of misunderstanding nowadays around agile a lot of people will say it's a methodology a framework or a specific way of developing software where we all have to stand up in our meetings but the truth is agile is not a methodology nor a specific way of developing software agile is a mindset a set of values and
00:30 - 01:00 principles that help organizations create great products back in 2001 17 people gathered in utah in u.s they were looking to define common grounds and the new way of thinking they needed something different to the traditional way of working in order to keep up with customer needs and our evolving work and this is where the agile manifesto was born the agile manifesto focuses on four
01:00 - 01:30 values and twelve principles the four values of agile are one individuals and interactions offer processes and tools two work in software over comprehensive documentation three customer collaboration over contract negotiation four responding to change over following a plan one of the most important word in these four values is the word over
01:30 - 02:00 the agile values don't imply that we need to stop using the elements on the rights indeed the agile manifesto says that while there is a value in the items on the right we value the items on the left more now let's take a look to the 12 agile principles that supports the agile values these principles are about customer satisfaction
02:00 - 02:30 embrace changes speed delivery collaboration empowerment effective communication good metrics steadiness operational excellence simplicity self-organization and continuous improvement
02:30 - 03:00 these principles are very general and are less about giving you a specific way to do things but more about giving you the foundation to make use decisions in different situations today several organizations of different sizes and several teams working on different activities are adopting the agile mindset and thanks to that they are able to embrace changes and respond to customers
03:00 - 03:30 needs and also improve their performance thank you hi in one of my previous videos i was talking about what is agile let's take a look now at the differences between agile and traditional way of
03:30 - 04:00 working also called waterfall several years ago projects were managed in waterfall where tasks are executed in phases in a linear and sequential way progress flows downwards in one direction like a waterfall each of these phases represents a distinct stage and each stage generally finishes before the next one can begin waterfall was organized in such a way that projects have to be finished within a certain
04:00 - 04:30 budget fixed scope fixed time and a good quality which was almost never the case and the customer was always unhappy in fact even when the project respected the budget scope time and quality the customer was still unhappy but why as waterfall does not require a huge deal of customer involvement so by the time we deliver what we thought the customer needed
04:30 - 05:00 it's not necessarily what he needs anymore and because of its linear approach and its rigidness towards changes in the development of the product and the process itself it makes it almost impossible for new ideas to be included which clearly impacts the customer satisfaction as well as the quality of the final products agile came to solve these issues with the 4 values and the 12 principles we create things differently in agile
05:00 - 05:30 we build products incrementally and iteratively which helps teams deliver value to their customers faster and with fewer headaches instead of betting everything on a big bank launch an agile team delivers work in small but consumable increments we start with a small piece of work and we go through the design development testing and deployment
05:30 - 06:00 the feedback from the customer and stakeholders is then collected and fed back into the cycle with agile changes are welcome the rapid delivery of the value in small increments allow teams to change their products based on customer feedback frequently and with lower costs this help them to keep up to date with the user's needs and the constantly evolving world
06:00 - 06:30 let's take an example our customer needs a car to be able to go to work if we decide to build this product in a waterfall way we will start by defining what the ideal car should look like after several weeks or months of thinking and once this phase is done we start building the car first the wheels then the engine the frame then we assemble everything and deliver it to the
06:30 - 07:00 customer what happens here is that during the first phases the customer is not receiving anything for a long period of time if we are optimistic he is happy with the car you gave him but the customer might say that this is not the car he was expecting and he doesn't like this design in this case changing the design will be very expensive if we decide to build this car in an agile way we will involve the customer on a
07:00 - 07:30 regular basis and we will ask him for input and feedback while building his car we can start with the minimum viable products the least expensive products that can allow us to test our idea and for him to try it based on his feedback we can improve it and add new functionalities at the end and as the customer was involved all the time and his feedback was act on
07:30 - 08:00 we know we are delivering exactly what he expects there is one important thing between these two ways of working in waterfall we cannot stop before we deliver the full products defined at the beginning in agile as we are delivering each iteration a functioning product the customer might say that he is happy with what you just presented and he doesn't need more so we don't have to spend more money to add
08:00 - 08:30 additional features that the customer doesn't need as a summary one of the most notable differences between agile and waterfall is the level of flexibility involved in each one of them where agile prides itself as being an approach that is flexible and continuously evolving waterfall is known to be more rigid and stricter in terms of process structure
08:30 - 09:00 thank you why organizations that adopt the agile mindset can survive during the covet-19 pandemic agile is an iterative based approach to create products and one of the best and most important ways of working that is already used in several organizations [Music] but how does it apply in time of crisis like the one we are facing today
09:00 - 09:30 in what ways is it relevant during the covet-19 pandemic the ongoing spread of coffee 19 has created a level of business uncertainty and seems since the great recession in order to understand the impact we need to take into consideration the length of the crisis and how long before this pandemic is contained which is a big unknown
09:30 - 10:00 a child is a mindset a set of values and principles that was born in 2001 with the development of the agile manifesto the agile mindset and the different frameworks have a lot to teach us about how to work most effectively in uncertain environments agile became more and more popular now and it started being used by companies seeking speed innovation and greater customer focus
10:00 - 10:30 companies are adopting the agile mindset not only in i.t departments but also in business departments and all functions across the organization and a lot of studies have shown that organizations that embrace agile most comprehensively are the most successful ones the actual mindset has significant benefits at any time and in these period of high uncertainty this mindset is even more impactful
10:30 - 11:00 these are some reasons why when adopting the anti-mindsets and using one of the agile frameworks such as scrum it provides rhythm and cadence for work when things are unclear and nothing feels certain agile gives an environment for team and organizations to move work forward will the team are meeting in virtual daily standup or reviewing their work together each screen these frequent checkpoints are positive for the team's mood
11:00 - 11:30 one of the agile values is respond to change over following a plan agile allows for quick change when organizations need to change priorities and make quick adjustments agile is the answer it gives an opportunity to change directions when needed and especially in crisis situations like the coronavirus as work has been planned in smaller portions and over shorter time box
11:30 - 12:00 agile teams have empowered to take decisions when needed rather than waiting for approvals with an agile leaders provide a shared vision and support team members as they fulfill it the ability for team members to make the necessary calls as they work through projects helps ensure speed and responsiveness to customer needs which is highly important in such time where we need to be able to react even more quickly than usual [Music]
12:00 - 12:30 but how can agile be relevant in this work from home situation everyone knows that collocated teams teams who are able to have close connections and plenty of face-to-face interaction are in general a lot more productive than distributed teams but this isn't always the case there is several examples of companies where team members are not only working from different offices but even from different countries one big example for this is scrum inc
12:30 - 13:00 let's look at some tips that can help any organization succeed with distributed agile teams in any situation video is your friend human being are visual creatives our brain is wired to read emotions and thoughts by looking at another person's face faces speaks much more than the voice so phone calls and texts and other chat tools are great but nothing replaces the human face [Music]
13:00 - 13:30 time box your work establish a fixed maximum time during which you and your team will accomplish certain tasks in general work expands to fit available time so if we plan a two hours meeting for a half an hour discussion it will still take us two hours time boxing sets limits on timing for tasks and helps ensure nothing takes longer than it should [Music] the third point is the tooling and
13:30 - 14:00 accesses everyone needs access to the same tools and to the work that needs to be done people need to be able to access it remotely so be sure that if you have any tool they should be easy accessible without extra effort from your employees and if you don't have any then it's the best time to find out what your organization can use [Music] speaking about tools one more important thing that we need to have
14:00 - 14:30 is a transparent clear and accessible backlog working remotely means there is a big need of using electronic tools for communicating about the backlog this means that having a prioritized backlog where the team know both what the product's owner wants and why is crucial it will bring a sense of clarity to all parties involved in the scope of work [Music] this is a great opportunity for people
14:30 - 15:00 to start paving up on tasks paving will allow people to work together on getting things done they will be able to constantly inspect their work for quality and adapt according to the changing needs and most importantly it will help them not to feel alone and isolated which is one of the biggest things organizations will have to deal with in this time of crisis there is here also several tools that will let people work on the same document at the same time so giving people the ability to work
15:00 - 15:30 together on a common task is a great way to collaborate innovate and share knowledge amongst team members one last important thing is for us to know when we should step back and learn views and retrospectives are great opportunities for any team to take a step back and look at the work they have accomplished during the time box sets rather than checking a box and rushing to the next task
15:30 - 16:00 teams are encouraged to take a break reflect and ensure they are constantly learning and adjusting as necessary inspecting and adapting constantly is a major part of team's work during time of crisis [Music] agile gives any organization and team members a good environment and creates the conditions for everyone to bring their greatest talents and think into complex problems a child can help us succeed today in
16:00 - 16:30 this crisis and even after the world is no longer based on individual work and the agile mindset embraces teams and more and more of these teams are working remotely from different locations so this is our time to accept that the world is changing and adapt our behaviors accordingly thank you
16:30 - 17:00 [Music] one of the first decisions we face for any project implementation is which way of working should we use the two basic most popular ways of working are first waterfall which might be more properly
17:00 - 17:30 called the traditional approach where work is done in distinct phases and then agile an iterative team-based way of working this approach focuses on the rapid delivery of the value in small increments choosing one or the other depends on the complexity level of the problem you are trying to solve one way to understand complexity is through the stacey matrix
17:30 - 18:00 developed by ralph stacy this model is designed to support decision making and choose appropriate way of working depending on each situation the status matrix has two dimensions the first axis is the requirement axis or the watts on the bottom of the axis we know exactly what we want to build and we all agree on the goals and have the same understanding of the expected outcome on top it's the opposite no aggravated
18:00 - 18:30 requirements and no alignment on expectations the second one is the implementation axis or the how the more we are close to the left side the more we know how to build this product and we can learn from past experiences if we go to the right side these problems are required to deliver something that is new and innovative let's take a look now to the four areas of the stacy matrix on one side of the station matrix we
18:30 - 19:00 have simple problems simple problems are well defined and easy to solve we know exactly what we have to do and how we can do it any size projects with clear activities and repeatable results fits in this category it has been done multiple times before and best practices exists in this area traditional methods and approaches such as waterfall are most effective an example could be built in a swimming
19:00 - 19:30 pool we need to first get a permit then create a layout then make a hole plumbing tiles and so on this work has been done so many times and it's clear what we need to do and how to do it at the other side of the matrix this is the chaos area in this area there is no agreement on what we want to do and no certainty on how to do things plans are useless we can observe two
19:30 - 20:00 situations in this area either we are in chaos because of a for example a natural disaster stock markets are going down the corona virus hit our planet and it's a general panic we don't know really what to do nor how to do things in these situations someone needs to take a decision to act fast like selling or buying stocks or putting people in quarantine another situation could be that we are trying to build a new product
20:00 - 20:30 but we don't know what we can have in it know how to do things and in this case by using some well-known technologies such as limb startup experimentation and design thinking we can create more clarity in the requirements and move out of this area between these two extreme ends of the matrix there is a large area called complexity zone in this area the traditional approaches are not effective as there is a high level of
20:30 - 21:00 unpredictability here we have the complicated zone and the complex zone complicated problems means they are less simple but still somewhat predictable the complicated zone is segmented into politically complicated and technically complicated the politically complicated projects are those where we might have several stakeholders with conflicting requirements in this case we have the choice between using a traditional approach
21:00 - 21:30 to get clearance on the why and the what or we can use an agile mindset that could help confronting stakeholders to come to a common agreement and to smooth the further requirements discussion with this kind of problems the team needs to focus on getting early agreements between stakeholders before they start in technically complicated contexts we know why and what we want to achieve still the how is not clear an agile
21:30 - 22:00 iterative approach helps the team to inspect and adapt and find new ways to bring the right value to the customer through a fast feedback loop then we have the complex area this area stands for high risk and uncertainty and requires a high feedback frequency there is a high level of uncertainty in terms of what you have to do and how you want to do it this context we should use a more explorative
22:00 - 22:30 approach with transparency frequent inspection and adaptation this is why we should work in small incremental steps using every step to determine if we have moved closer to solving our problem or away from it scrum as an agile framework is a good example for such process i like to call the complexity zone the sweet spot for agile as it requires fast feedback and a close collaboration with the customer [Music]
22:30 - 23:00 an example for this area could be building a car for a customer we can start with the minimum viable products and then with the feedback we can improve it and add new functionality to the car until the customer is satisfied in an adapted version of the stacy matrix a third axis is often added to the model and it presents the number of people involved the idea is that the more we add people on a certain activity the more complex it becomes a task that
23:00 - 23:30 is simple for one person may be very complex for a group picking a movie to watch is easy on your own but which may become very complex with a group of friends this is an easy way i used to explain when to use agile to different stakeholders in different organizations i hope this short video gave you an idea about when to use agile and when not to please leave us a feedback if you want to know more and follow us to see more of our videos
23:30 - 24:00 thank you scrum is one of the most popular agile framework it describes a set of meetings roles and artifacts that help teams structure and manage their work
24:00 - 24:30 at its heart scrum works by breaking large products and services into small pieces that can be completed by a cost functional team in a short time frame called sprint so how does scram work it all starts with a vision the product owner has the responsibility to speak with stakeholders and customers and translates their wishes into the product's backlog a prioritized list of items that the
24:30 - 25:00 team should work on we call these items user stories the team can start their sprint sprint is a time-boxed iteration between one to four weeks maximum the first meeting in the sprint is the sprint planning based on their capacity the development team will pull the highest priorities user service from the product's backlog into their sprint backlog the development team will then break down these user stories
25:00 - 25:30 into smaller tasks and discuss how they want to achieve the work every day the team will meet in the daily scram a short communication meeting of 15 minutes maximum the team members will discuss quickly and transparently the progress of their work and solve any impediments that prevent them from delivering on the sprint goal at the end of the sprint the team invites the stakeholders to the sprint review this is their time to showcase their
25:30 - 26:00 potentially shippable product and get feedback on the work accomplished the feedback will be translated to new user service in the products backlog the team then will have their final meeting of the sprint which is the sprint retrospective they will discuss what went well what didn't go well and how they can improve their process in the next sprint the cycle will start again and the team will pick up the next priority from the products backlog
26:00 - 26:30 the scrum master will have the responsibility to facilitate the process and to help the team perform at the highest level this may include removing impediments facilitating meetings and helping the product owner refine the backlog one activity that the scrum team can hold during their sprint is the backlog refinement this can happen any time the team needs to work on their product's backlog to clarify some use of service and estimate them
26:30 - 27:00 the team will also create a definition of ready a checklist that will help them define whether a user story is ready to be taken and worked on in a sprint or not they will also create a definition of done that can be used at the end of the sprint this definition of done will help them to have a shared understanding of what it means for work to be completed because scrum teams are continuously creating only the highest priority
27:00 - 27:30 chunks of work it ensures that they always deliver on customer expectations and the business is assured a maximum return on investment a lot of people think that scrum is only for software development team but in fact the screen values principles and lessons can be applied to all kinds of teamwork and organizations that have adopted the scrum framework have experienced many benefits such as faster innovation
27:30 - 28:00 higher productivity better quality products avid used time to markets better team dynamics and increased employees happiness i hope you enjoyed this video please subscribe to our channel to receive more videos on this topic thank you
28:00 - 28:30 hi in this video we will be discussing huawei's kanban kanpai is one of the most popular agile framework the first kanban system was developed by taishi ono for toyota in japan in the 50s its main purpose was to optimize their production capacity and to be competitive with american companies the goal of kanban is to improve the flow identify potential bottlenecks in
28:30 - 29:00 your process and fix them so work can flow through it effectively at an optimal speed like scrum company is a process designed to help teams work together more effectively it is a good way to organize the process by visualizing and making the need for prioritization transparent and clear work items are represented visually on a kanban board each team can draw their own process and visualize all the steps they go through when
29:00 - 29:30 producing items which help them to see the state of every piece of work at any time each step of the process has a work in progress limits which is the maximum number of tasks that we can have in each step if the team has too much work in progress they risk decreasing the quality of the product in kanban the team start working on the highest priority items based on a pull system which means we can't push an item into the next step
29:30 - 30:00 but the process will pull items when needed and based on the work and progress limit for each step team members can't pull more items than their capacity this will help them to discover bottlenecks and find ways how to improve the process and maybe start helping each other in the different steps to remove these impediments and let the workflow these items on the content board will allow each team to measure their cycle time which is the total time from when the
30:00 - 30:30 team started working on an item to the time they delivered it and they can measure also their lead time which equals the total time it takes from receiving an order to delivering the item these are two important metrics that will help the team find bottlenecks and define their improvement plan the kanban method is a process to gradually improve whatever you do whether it's software development it management as well as business processes such as
30:30 - 31:00 staffing recruitment marketing and sales procurement and many more in fact almost any business function can benefit from applying the principles of the kanban framework the kanban method follows a set of principles and practices for managing and improving the flow of work it is a non-disruptive method that promotes gradual improvements to an organization's processes kanban has four foundational principles
31:00 - 31:30 start with what you are doing now do not make any change to the existing process right way kanban must be applied directly to your current workflow and any changes needed should be done over a period of time at a pace the team is comfortable with agree to pursue incremental evolutionary change as employees are generally resistant to radical changes kanban encourages making small changes over time
31:30 - 32:00 rather than big ones that might lead to resistance within the team and organization respect current roles responsibilities and job titles in order to facilitate future changes the fear of change must be eliminated this can be done by maintaining and respecting each other's current roles responsibilities and professional titles these three first principles help the organizations overcome the typical emotional resistance
32:00 - 32:30 and the fear of change that usually follow any change initiatives in an organization the last principle is leadership at all levels leadership acts don't have to come from senior managers only people at all levels can provide ideas and show leadership to implement changes and continually improve the way they deliver their products and services let's take a look now to the six core practices of the kanban method visualize the flow of work to understand
32:30 - 33:00 how the process in place works and how this work is delivered limit work in progress each stage of the workflow can only contain a maximum number of tasks at the same time this helps the team members first finish what they are doing before taking up new tasks manage flow by showing the different steps of the workflow and the status of work in each stage once the workflow is defined
33:00 - 33:30 and the work in progress limit is set the team will observe either a continuous flow of work or tasks will start piling up as something gets blocked and starts to slow down the process make process policies explicit and visualize how the work is done this will create a common basis for teams and the whole organization for how to do any type of work in the system implement feedback loops once the team understands the theory of the job
33:30 - 34:00 the processes and the risks they will be able to discuss problems or bottlenecks they are facing and find improvements to put in place improve collaboratively evolve experimentally teams needs to have a psychologically safe environment where experimentation is welcome and it is safe to fail otherwise no one will try to make any effective changes if you follow these principles and practices you will successfully be able to use
34:00 - 34:30 kanban for maximizing the benefits to your business process and build sustainable competitive advantage organization will also be able to improve flow and visibility reduce cycle time by removing bottlenecks inquiries values the customer with great predictability and creating more motivated empowered and high performance teams that will be able to accomplish more and faster all of which are crucial to any business today
34:30 - 35:00 thank you for following this video we hope that we answered all the questions you have around kanban please subscribe to our channel if you want to see more of our videos hi we will be discussing in this video the difference between scrum and kanban if you are new to scrum and kanban
35:00 - 35:30 please check our other videos explaining them previously we have discussed what agile is a mindset with a set of values and principles that help organizations create great products kanban and scrum and many more are frameworks that help teams follow the actual principles and get work done kanban and scrum at their core are summarized by the premise
35:30 - 36:00 stop starting start finishing all team members focus on giving all the tasks they are working on to done kanban is all about visualizing your work limiting work in progress and managing flow kanban teams focus on reducing the cycle time the time it takes a task to go from start to finish they do this by using a kanban board and continuously improve their flow of work scrum teams commit to deliver a working
36:00 - 36:30 product in short iterations called sprints at the end of each sprint the team invites the customer and show their products goal in scrum is to create quick learning loops to gather and integrate customer feedback in scrum teams adopt specific roles create special artifacts and hold regular ceremonies to keep things moving forward in a nutshell scrum and kanban have differences in many areas
36:30 - 37:00 in terms of cadence scrum has fixed duration from one to four weeks and kanban is based on a continuous flow and not enforcing any time limits scrum has three recommended roles product owner scrum master and the development team kanban has no predefined roles and it promotes to maintain and respect each other's current roles responsibilities and professional titles instagram
37:00 - 37:30 once a sprint has started the sprint's backlog cannot be altered until the end of the sprint so teams should not make any changes during the sprints while in kanban it is based on flexible scoping scope can be modified at any time but the number of tasks is limited at each stage with the work in progress limit for the way how these frameworks release their work in scrum work is delivered in batches at the end of each sprint
37:30 - 38:00 in kanban as it is a continuous flow process each task is delivered when it's completed teams in scrum uses velocity as a measure to define their predictability it guides how much work the scrum team takes on in future sprints in kanban they use cycle time and lead time which is a measure on the average amount of time that we take for a task to move from start to finish kanban teams strive to improve cycle time by working together on removing bottlenecks
38:00 - 38:30 scrum is used when the product scope is almost clear and work can be planned it is more appropriate in situations where work can be prioritized in batches company is used when there is very frequent changes in scope it is more appropriate in operational environments with a high degree of viability and priority while it is easy to point out the differences between scrum practices and kanban practices
38:30 - 39:00 their principles are largely the same both frameworks will help you build better products both scrum and kanban work by breaking down large and complex tasks in smaller ones to be completed efficiently they place a high value on continuous improvement optimization of the work and the process and both share the focus on transparency and making the work visible that keeps all team members aligned so before thinking whether you should choose scrum or kanban
39:00 - 39:30 don't ask kanuban versus scrum but instead ask kanban or scrum or even kanban and scrum make us more about the principles than the practices thank you for following this video please follow us for more content
39:30 - 40:00 a key element of the agile mindset is putting people first agree is a user-centered approach it shifts the focus from just coding and designing to delivering real value to your end users use of stories puts actual end users at the center of the conversation
40:00 - 40:30 [Music] user stories use non-technical language it provides context for the teams and let them define what benefits the products will bring to their target audience use of stories drive collaboration and creativity and a better product overall after reading a user story the team knows why they are building what they are building and what value it creates in this video we will be discussing 5 points related to the user stories
40:30 - 41:00 what is a user story why do we write you to stories how do we write user stories who write them and when do we write them so let's get started a user story is the smallest piece of work that represents some value to an end user it contained the following elements title description and acceptance criteria
41:00 - 41:30 the title of a user story follow a basic formula as a role i want an objective so that i can achieve a motivation the use of stubby defines a functionality it is expressed as a persona the role who are we doing this for that is performing an action an objective so he can satisfy a need the motivation
41:30 - 42:00 an example of a use of story could be as an uber passenger i want to see several available drivers in my area so that i can choose the closest one to me we must remember that the title of a user story must map a single functionality of our product or service let's look at the description the description of a user story helps to give context to that story
42:00 - 42:30 the description may contain a small explanation of the user journey some use cases and in general any explanation that helps to better understand the title the description should not be thousands of words but it should contain any good context that help clarify what is being expressed such as pictures or links to the design now along with the title in the description one last important element that should be included in the use of story is the
42:30 - 43:00 acceptance criteria these are a set of conditions that helps us to validate the implementation of our user story and to confirm when it is completed if we take our previous example as an uber passenger i want to see several available drivers in my area so that i can choose the closest one to me acceptance criteria for this user survey could be the app shows only the drivers that are within an area of four kilometers from the customer the app shows maximum 10 drivers that
43:00 - 43:30 are in the same area as the customer a customer can check the profile of these drivers including their picture and rating we are able to understand the value of a user story with the title and description and the acceptance criteria help us understand some key characteristics that require special attention during implementation so going through the acceptance criteria with the team at the time of writing the user story is the best way to fully develop the
43:30 - 44:00 functionality [Music] so what is the benefit from writing a user story use of stories emerged as a result of a need to break down projects into smaller incremental segments for sprints and iterations if you were ever involved in working with agile framework you already know that both scrum and kanban teams greatly benefit from writing user stories in scrum use of stories are added to the
44:00 - 44:30 sprint backlog and worked on over the duration of the sprint in kanban teams accumulate stories in a backlog and then run them one by one through their workflow [Music] working on use of stories helps chrome teams make estimations prioritize and plan sprints leading to more flexibility and greater agility and thanks to stories compile teams learn how to manage work in progress which help them to constantly stay on track
44:30 - 45:00 and refine their workflows user stories have other benefits that are common to all agile teams they keep you focused on the user and the business value it helps to make your product not only well built from the technical perspective but also useful to the end users user stories enable collaboration with the end goal defined the team can work together to decide how best to serve the user and meet that goal
45:00 - 45:30 it enable creativity stories encourage the team to think critically and creatively about how to best solve the end goal [Music] your project becomes more manageable user stories is the best way to work with small and estimatable elements rather than with big complex tasks and finally the inspired team and create momentum with each story closed the team loves this sweet feeling of a small win
45:30 - 46:00 which motivates them to work even harder [Music] let's look at how to write a good user story the common use of story templates include the user the action and the value and it typically looks like this as a type of user i want an action so that i can achieve a reason of a value before writing a user story you should know who the end users
46:00 - 46:30 or the persona of your product are and more important what needs to have which you are trying to cover it is all about the user not about the developers and not even about the product owner each story should bring a value to some group of your end users feel some empathy give your user a name think of his habits what issue your app is going to get resolved for him and how you're going to make this path
46:30 - 47:00 easier and faster now that we have a few groups of end users the next step to do is define what functionality each user expects how he's going to use the products some basic rules to remember when writing an action for a user story is to have one action per story if you want to write something like as a customer i want to browse items and then add them to the cart it is better to split it into two different
47:00 - 47:30 tutor stories one as a customer i want to browse items and the other one as a customer i want to add items to the cart describe an intention not a feature for example instead of i want to manage my profile create a few stories like i want to be able to register my profile i want to be able to upload my profile photo i want to link my credit card to my profile each user story will have a different
47:30 - 48:00 value finally the last piece of our user story someplace is dedicated to the value the value that the users will get after performing an action what's the overall benefits they are trying to achieve what is the big problem that needs solving each story should contribute to the general goal of your products and if you can't answer what value this user story brings to the end users and your products as well then you're doing something wrong
48:00 - 48:30 use of surveys are an essential element of the agile approach that can bring many benefit to your project however it's important to write them correctly which requires some time and skills a good use of stories meets the invest criteria meaning that they are independent of other user stories user stories can be developed in any sequence user stories are negotiable there must
48:30 - 49:00 be a conversation between client and development team not a closed contract valuable each user story must add a value to the product estimatable its user story must be able to be estimated in relative sizing such as story point or t-shirt sizing small enough to fit in one sprint and to be completed and finally testable each user story
49:00 - 49:30 must be able to be validated and tested writing use of stories that follow the user's topic format is a good starting point evaluating them for effectiveness against the invest goals keep the use of stories small functional and testable [Music] so who writes the user stories the product owner has the responsibility to make sure a product backlog of use of
49:30 - 50:00 service exists however it doesn't mean that the product's owner is the one who writes them the more people join in the conversation the better and anyone can contribute and write user stories the responsibility of the product owner in this case is to confirm that they are matching the invest criteria and to prioritize those user stories in the backlog finally when do we write the user stories
50:00 - 50:30 user stories are written during the whole life of the product usually a stubby writing workshop is held at the start the team members will participate with the goal of creating a product's backlog that describes the functionality to be added over the course of the product development some of these user stories will be big ones that will later be split into smaller ones and that can fit into a single iteration on top of that new user service can be
50:30 - 51:00 written and added to the product backlog at any time and by anyone [Music] i hope this video gave you a good understanding of user stories please leave us a comment and follow us for more content thank you [Music]
51:00 - 51:30 in scrum and any other framework based on agile we need a clear and agreed definition on what constitutes a ready scope item to go into the development cycle and what criteria needs to be met to consider it done one of the key artifacts of scrum is the
51:30 - 52:00 idea of backlog both at the product level as well as the sprint level all the features and requirements that a team may deliver in order to achieve a specific outcome are in the product backlog an ordered list of elements this order is decided by the product owner and usually driven by business value the product's backlog is the source for the sprint backlog the products backlog represents all the
52:00 - 52:30 user stories for the product while the sprint backlog is the list of the use of stovies that the team will work on during the upcoming sprints as described in the scrum framework during the sprint planning the product owner will present the list of top prioritized items in the product backlog and the team needs to pick the use of stovies that will be able to work on during the sprint based on their capacity however
52:30 - 53:00 in order to successfully pull items into the current sprint it is important that the defined user stories are ready putting non-ready use of stories into a sprint causes problems during the implementation cycle if developers work on insufficiently detailed or undefined use of stories they are unlikely to produce high quality code let's take the example of a customer going to our restaurant
53:00 - 53:30 he is asking the chef to make him a burger with a slice of cheese and fries before the chef starts cooking he needs to check if he has all the necessary element to stop the order does he have all the ingredients for a burger and fries does he have a cooking stove a pan kitchen utensils these are the elements that the chef cannot start without and this represents the definition of
53:30 - 54:00 ready for the chef to be able to cook any dish for his customers the definition of ready is the checklist of what needs to be done on a user story before the team can start implementing it in the next sprint note that the definition of ready is not part of the scrum guide and that is for a good reason the definition of ready should not be used as a phase gate for sprint planning or as a way to push away
54:00 - 54:30 responsibility it should rather be a guideline for the theme of what needs to be done during the backlog refinement most teams start out with an empty definition of ready and then add elements to it when it's needed it should grow and develop as the team evolves in terms of the working pace and the understanding of what makes a good user story a typical definition of ready might look like this example the user story is understood by the team
54:30 - 55:00 user story has clear business value the user story is estimated all the dependencies are identified the user story is small and the use of story has acceptance criteria defined at the end of the sprint the team would invite the stakeholders to the sprint review to show them the completed user stories these completed use of starviews should
55:00 - 55:30 fulfill the definition of done a checklist that defines when a use of sturvey is considered done if we take the previous example with the chef at the restaurant once he has completed the customer's order we need to check if the order is really completed by checking all the necessary elements to close it did he deliver the order as per the acceptance criteria of the customer
55:30 - 56:00 is it warm delicious delivered on time well cooked is the food served in a nice plate if the pan and the kitchen is stencil are cleaned are the remaining ingredients put back to their place so this is the checklist that says that the chef is done with this order and it has been completed having a definition of done helps the
56:00 - 56:30 team to make sure that the built product doesn't have any undone work and it is ready to be shipped definition often is a checklist of the work that the team is supposed to finish successfully before declaring the work to be potentially shippable an example of the definition of done the use of story is built without errors the user story is tested against the acceptor's criteria
56:30 - 57:00 it is demos to the stakeholders accepted by the product owner the documentation is updated one important thing to keep in mind is that the definition of done and the acceptor's criteria are not the same the difference between these two is that the definition of done is common for all user stories while the acceptance criteria is applicable to a specific user story acceptance criteria of each user story
57:00 - 57:30 will be different based on the requirements of that user story but in all cases both definition of done an acceptance criteria must be met in order to complete the user story both definitions of done and definition of ready are typically discussed during revit perspective the team then can edit them and extend them based on new knowledge they have
57:30 - 58:00 in my experience it's based to start with a very simple and basic definition of ready and definition of done and most teams quickly will write this down collaboratively during an initial meeting before the project starts thank you for following us do not hesitate to leave us a comment if you would like to know more
58:00 - 58:30 in a previous video we have discussed the story points estimation and how to estimate user stories stopping points are very useful as it helps the team to define their velocity the velocity is the measure of how many stubby points the team can take into a single sprint and is the key metric in scrum velocity is calculated at the end of the
58:30 - 59:00 sprint by totaling the points for all fully completed user stories the velocity will be used during the sprint planning to define how many user services the team can take on during the sprint and striking the team's velocity helps predicting the team's capacity for the upcoming sprints by experience teams take three to four iterations to find their stable velocity
59:00 - 59:30 tracking your team's velocity helps you turn your estimation units into actual time and cost for the business this can be simply done when we know the velocity of the team another advantage i'll point out about using study points and tracking velocity is the way they naturally account for the difference between an ideal eight hours work day and the interrupted full of meetings day team velocity represents the team's capacity
59:30 - 60:00 with all the messy details of real work situations already accounted for beside the velocity scrum team uses story point to track their progress using the burn down chart on one axis it represents the number of starving point the team took during a sprint and the other axe represents the number of days in one sprint a burn down chart is a graphic representation of how quickly the team
60:00 - 60:30 is working with their user stories the ideal flow of completing the use of stories in the sprint is by having this straight line in this example the team has 25 stubby points in their sprint and will run a sprint of 2 weeks which is 10 days sprint every day during the daily scrum the team will discuss how many story points they have accomplished in the previous day
60:30 - 61:00 and then draw the line by removing the amount of story points completed sprint burn down will help the team to see very quickly whether they are on track or not if after a couple of days the team see that they are above the ideal line they need to find ways to come back on track otherwise they will not be able to finish their user stories and if they are way below the ideal line that means they might finish their views
61:00 - 61:30 of service before the end of the sprint and they can ask the product's owner to take on another user story story points are also useful for product owners when discussing planning and cost with the stakeholders through the use of the burn up charts on one x we have the number of story points we have in the product backlog the other x represents the sprints
61:30 - 62:00 i said earlier teams needs three to four sprints to have a stable velocity and enough good data the product owner can use this data on the predictability of the team let's take this example the team has delivered a team stopping point in the first sprint 20 in the second 15 in the third sprint and 22 on the fourth sprint
62:00 - 62:30 in this example we see that the team has delivered in average 18.75 story points as a minimum they delivered 15 story point and as a maximum they delivered 22 story points based on this data the product owner can draw the predictive line if the team always delivers on average every sprint another line if they always deliver the minimum and the last line if they always deliver
62:30 - 63:00 on the maximum now there is two ways product owners can engage with stakeholders using the burn up charts we either speak about date driven planning the stakeholder asks what can be delivered in sprint 7 for example by simply drawing the lines at the intersection of each other delivery line the product's owner can tell the stakeholders that by sprint 7
63:00 - 63:30 the team will be able to deliver between 108 and 158 story points the product owner can then show to the stakeholders the use of stories from the products backlog that will fit in this estimation another way to use the sprint burn up chart is with the scope driven planning if the stakeholder asks the product owner by when the team can deliver the minimum viable product the product owner can then look at the
63:30 - 64:00 use of service that's fit in the minimum viable product and see how many story points assuming it is 155 we draw the lines to the intersection of the delivery lines the product owner can then tell the stakeholder that the mvp will be delivered between sprint 7 and sprint 9. a very important point to not forget when showing these data to your stakeholders is that this is not exact science but
64:00 - 64:30 predictions based on the data you have today the more you work on your product the more data you get and the more precise you can be based on this burn up chart the product owner can give an estimation of budget required for the minimum viable product for example as shown in the scope driven planning we see that the mvp can be delivered between sprint 7 and sprint 9 and knowing the number of people working
64:30 - 65:00 in the team during the sprint we can have the cost of this print we simply need to multiply the cost of this print by the number of sprints required to deliver the mvp to half the cost of the mvp i hope this video gave you a good understanding about the importance of using the story points and how to use the different metrics to engage with your stakeholders and have good conversations
65:00 - 65:30 follow us for more contents thank you you