This document summarizes Henrik Kniberg's keynote about applying Agile and Lean principles at home. Some examples discussed are using focus boards and burnup charts to help children with homework, implementing WIP limits to reduce clutter in bedrooms and the kitchen, and creating a kanban board to plan a big family trip. The document emphasizes how visualizing work and limiting work-in-progress can improve productivity and organization both at work and at home.
This document discusses techniques for improving productivity and focus by limiting work in progress (WIP). It recommends isolating distractions, focusing on one task at a time until it's complete, knowing your current WIP and limiting it, learning to keep your inbox empty, installing a value filter to prioritize important work, scheduling reflection time, reserving slack time for rest and exploration, noticing how you currently spend your time versus how you want to spend it, and saying no to additional work to focus on finishing existing work and limiting WIP. The overall message is to stop starting new things and instead start finishing current work.
This document provides an overview of agile concepts and the Scrum framework. It defines key roles in Scrum like the Product Owner, Scrum Master, and Development Team. It also explains common agile ceremonies like sprint planning, daily standups, sprint reviews and retrospectives. The document emphasizes the importance of collaboration, adaptive planning, and valuing individuals over processes in agile development. It includes examples of how Scrum can be applied to plan a brochure development project in a series of short sprints.
The document provides an overview of roles, artifacts, meetings, and processes in Scrum. It defines the key roles of the Scrum Team, Product Owner, and Scrum Master. It describes the main artifacts like the Product Backlog, Sprint Backlog, and Burndown Chart. It outlines the core Scrum events of Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Finally, it addresses common questions and concepts like estimating, prioritization by business value, and self-managing teams.
Certified Scrum Product Owner: class desk, posters and photosAlexey Krivitsky
The document provides an overview of agile product management and scrum. It discusses key concepts like lean, agile, scrum roles and artifacts, ceremonies like sprints and planning, and topics like minimum viable products, user stories, prioritization techniques, and product backlog refinement. The document is a training guide or presentation on agile product management best practices.
Learn more about the most popular Agile framework - Scrum. This training should be paired with the pre-training learning materials in Trello. Learn more about the Scrum artifacts (product backlog, sprint backlog, etc.), Scrum roles (Scrum Master, Product Owner, and the team), and the Sprint.
This document discusses Agile project planning and estimation techniques. It notes that estimates are often wrong due to factors like changing requirements, irrelevant information, and anchoring biases. Instead of estimating time, Agile recommends estimating the relative size of features and measuring team velocity over iterations to forecast release plans and timelines. Estimates should be done by developers and re-estimated continuously throughout the project rather than relying on early estimates.
This document discusses techniques for improving productivity and focus by limiting work in progress (WIP). It recommends isolating distractions, focusing on one task at a time until it's complete, knowing your current WIP and limiting it, learning to keep your inbox empty, installing a value filter to prioritize important work, scheduling reflection time, reserving slack time for rest and exploration, noticing how you currently spend your time versus how you want to spend it, and saying no to additional work to focus on finishing existing work and limiting WIP. The overall message is to stop starting new things and instead start finishing current work.
This document provides an overview of agile concepts and the Scrum framework. It defines key roles in Scrum like the Product Owner, Scrum Master, and Development Team. It also explains common agile ceremonies like sprint planning, daily standups, sprint reviews and retrospectives. The document emphasizes the importance of collaboration, adaptive planning, and valuing individuals over processes in agile development. It includes examples of how Scrum can be applied to plan a brochure development project in a series of short sprints.
The document provides an overview of roles, artifacts, meetings, and processes in Scrum. It defines the key roles of the Scrum Team, Product Owner, and Scrum Master. It describes the main artifacts like the Product Backlog, Sprint Backlog, and Burndown Chart. It outlines the core Scrum events of Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Finally, it addresses common questions and concepts like estimating, prioritization by business value, and self-managing teams.
Certified Scrum Product Owner: class desk, posters and photosAlexey Krivitsky
The document provides an overview of agile product management and scrum. It discusses key concepts like lean, agile, scrum roles and artifacts, ceremonies like sprints and planning, and topics like minimum viable products, user stories, prioritization techniques, and product backlog refinement. The document is a training guide or presentation on agile product management best practices.
Learn more about the most popular Agile framework - Scrum. This training should be paired with the pre-training learning materials in Trello. Learn more about the Scrum artifacts (product backlog, sprint backlog, etc.), Scrum roles (Scrum Master, Product Owner, and the team), and the Sprint.
This document discusses Agile project planning and estimation techniques. It notes that estimates are often wrong due to factors like changing requirements, irrelevant information, and anchoring biases. Instead of estimating time, Agile recommends estimating the relative size of features and measuring team velocity over iterations to forecast release plans and timelines. Estimates should be done by developers and re-estimated continuously throughout the project rather than relying on early estimates.
The Product Backlog Refinement refers to activities that help us keeping the product backlog in optimal form. This overview presents all important aspects of this important analysis activity in SCRUM.
This document outlines an agenda for a two-day Certified ScrumMaster training. Day one covers introductions, an overview of Scrum principles and roles, the Scrum flow, estimation techniques like planning poker, and retrospectives. Day two will focus on running effective sprint planning and daily scrums, scaling Scrum to larger teams, and a velocity game exercise. The goal is to teach attendees how to implement the Scrum framework and best practices.
Writing Good User Stories (Hint: It's not about writing)one80
User stories are typically the foundation of the Product Backlog. However, the original purpose has been lost. This is from a presentation that was given to help remind everyone of what User Stories are, and what they aren't. The purpose of User Stories is to drive conversations, not to hand "requirements" from one group to the next.
Prioritization Techniques for Agile TeamsTarang Baxi
Have you ever been in a prioritization discussion where the only priorities are High, Higher, and Highest? Or tried using MoSCoW to prioritize user stories only to find
that 80% of the cards are 'Must Have'?
In this tutorial, we introduce a gamut of different prioritization methods, ranging from simple techniques like stacked ranking or MoSCoW that classify items along a single dimension to multi-dimensional techniques like priority quadrants, Story Maps, and Innovation Games®. We cover pruning feature trees, spending fake currency, and using visual metaphors, while truly identifying what the most important stuff really is. This was most recently presented at the Agile India 2013 conference in Bangalore.
Agile Everywhere!
Henrik Kniberg talks about how his journey implementing agile & lean methods at Spotify and Lego helped him apply agility in new & unexpected fields. Henrik will share his vision on how agility may evolve in the future and affect various areas of our lives.
About Henrik Kniberg
Henrik Kniberg is an Agile/Lean coach at Crisp in Stockholm, working primarily with Lego and Spotify. He enjoys helping companies succeed with both the technical and human sides of software development. During the past 15 years he has been CTO of 3 Swedish IT companies and helped many more get started with Agile and Lean software development.
Henrik is former board member of the Agile Alliance and works regularly with Mary Poppendieck, Jeff Sutherland, and other thought leaders. He is the author of “Scrum and XP from the Trenches” and “Kanban and Scrum, making the most of both” and “Lean from the Trenches“. These books are available in over 12 languages, have over 500,000 readers, and are used as primary guide to Agile and Lean software development by hundreds of companies worldwide. Henrik also created the viral animated videos “Agile Product Ownership in a Nutshell” and “Spotify Engineering Culture“.
The document provides an overview of Objectives and Key Results (OKRs), including:
- OKRs are goal-setting frameworks used by large, fast-growing companies consisting of objectives (what to achieve) and key results (how to measure achievement).
- OKRs originated from concepts like management by objectives and SMART goals, and were popularized by companies like Intel and Google.
- Effective OKRs are focused, align teams/goals, have commitment to tracking results, and stretch goals. Regular check-ins help with transparency and progress.
- The document outlines best practices for writing OKRs and implementing them in organizations through quarterly and annual goal-setting.
The document provides an overview of Agile methodology and Scrum framework. It describes that Agile is an alternative project management approach that uses short iterative cycles called sprints to incrementally deliver working software. Scrum is the most commonly used Agile framework and involves roles of Product Owner, Scrum Master, and team. It uses artifacts like Product Backlog and Sprint Backlog and events like Sprint Planning, Daily Scrum, and Sprint Review.
Here are the estimated story points for the items using Planning Poker:
Spain - 13
China - 13
Luxembourg - 5
Denmark - 8
South Africa - 8 (reference point)
Belize - 3
Training materials for Agile Scrum. Starts with an overview of Agile and Lean. Followed with the Agile Scrum key concepts like Product Owner, Scrum Master, Scrum Team and Product Backlog. Theory is complemented with learnings and best practices from real life software development.
A product manager is responsible for the overall success of a product by understanding customer needs and ensuring the product delivers value. Key responsibilities include defining product requirements and strategy, building business cases, conducting user research, creating roadmaps, and tracking metrics. The role requires balancing internal needs while representing customers externally throughout the product development process.
The document discusses Scrumban, which combines elements of Scrum and Kanban. It outlines 5 guiding questions about value, flow, quality, joy, and continuous improvement. It then describes 5 steps of evolution away from sprints, including removing artificial goals and delays. Estimation is de-emphasized in favor of proper slicing and forecasting using throughput. Metrics like WIP, flow diagrams and scatterplots with cycle times are recommended. Finally, it promotes several referenced books and resources on Scrumban and Kanban.
The document outlines the rules for a team-based game where players are split into roles to collaboratively build Lego animals. The roles are legs developer, body developer, head developer and tester. The rules describe 5 rounds of play with different collaboration restrictions for each round to encourage teamwork and test different skills. The testers use dice to introduce random defects ("bugs") and determine if completed animals pass testing or must be returned to the appropriate developer role for repairs.
Overview
- What is a User Story?
- User Story template
- examples of User Stories
- User Story Checklist
- Why not tasks?
- What is Acceptance Criteria?
- Examples of Acceptance Criteria
- Acceptance Criteria checklist
The document discusses Scrum, an agile framework for project management. It describes some issues with traditional waterfall models like high risks and uncertainty. Scrum aims to address these issues by allowing for frequent delivery of working software, adapting to changes, and welcoming late changes. The document then outlines the key aspects of Scrum like product and sprint backlogs, daily stand-ups, sprint reviews, and retrospectives. It discusses how Scrum has been used successfully in various domains like software, games, websites, and more. Finally, it covers some benefits of Scrum from different stakeholder perspectives.
The document provides an overview of Scrum, an agile framework for project management. It discusses the core components of Scrum including roles, artifacts, ceremonies, and values. The key roles are Product Owner, Scrum Master, and self-organizing Team. Projects progress through a series of sprints where work is pulled from the prioritized Product Backlog to the Sprint Backlog and completed work is demonstrated at Sprint Review meetings. Daily stand-up meetings and retrospective meetings aid in transparency and process improvement.
Metrics at Every (Flight) Level [2020 Agile Kanban Istanbul FlowConf]Matthew Philip
Slides as presented on Dec 8, 2020 at FlowConf organized by Agile Kanban Istanbul. https://www.flowconf.com/
Organizational change often stalls out at departmental boundaries, whether that is IT or another division. How do we help organizations connect vertically and horizontally to realize the outcomes that they have when undertaking large-scale change efforts?
Join this session to learn from a case study of a bank that combined flight levels and metrics to bridge their departmental boundaries and recognize gains not only in software delivery effectiveness but unifying higher-level strategy.
This document provides an overview of Scrum training. It introduces the trainer, Deniz Gungor, and their background. It then outlines the agenda, which will cover Scrum fundamentals, a Scrum simulation game, and the Scrum framework. Key aspects of Scrum are defined, including self-organizing Scrum teams, iterative delivery, the Product Owner, Scrum Master, Development Team, events like the Daily Scrum and Sprint Review, and artifacts like the Product Backlog and Sprint Backlog. The training will help participants understand and apply the Scrum framework to projects.
The document discusses reversing the "tests pyramid" approach to address technical debt in legacy code. It notes that unit testing is difficult for code without separation of concerns, but refactoring without tests is risky. It proposes starting with high-level tests to gain confidence for refactoring into units and writing unit tests incrementally. However, end-to-end tests are long to maintain, and if needed, the architecture may be flawed. Reversing the tests pyramid and refactoring code in this way takes time but pays back technical debt and allows for sustainable changes. Beware of refactoring just for its own sake - focus on removing duplication and improving changeability.
Presentation from AgileEE 2012 in Kiev (October 2012) and XP Days Ukraine 2012 in Kiev (November 2012) about evolution of Agile processes in team during project lifecycle.
The Product Backlog Refinement refers to activities that help us keeping the product backlog in optimal form. This overview presents all important aspects of this important analysis activity in SCRUM.
This document outlines an agenda for a two-day Certified ScrumMaster training. Day one covers introductions, an overview of Scrum principles and roles, the Scrum flow, estimation techniques like planning poker, and retrospectives. Day two will focus on running effective sprint planning and daily scrums, scaling Scrum to larger teams, and a velocity game exercise. The goal is to teach attendees how to implement the Scrum framework and best practices.
Writing Good User Stories (Hint: It's not about writing)one80
User stories are typically the foundation of the Product Backlog. However, the original purpose has been lost. This is from a presentation that was given to help remind everyone of what User Stories are, and what they aren't. The purpose of User Stories is to drive conversations, not to hand "requirements" from one group to the next.
Prioritization Techniques for Agile TeamsTarang Baxi
Have you ever been in a prioritization discussion where the only priorities are High, Higher, and Highest? Or tried using MoSCoW to prioritize user stories only to find
that 80% of the cards are 'Must Have'?
In this tutorial, we introduce a gamut of different prioritization methods, ranging from simple techniques like stacked ranking or MoSCoW that classify items along a single dimension to multi-dimensional techniques like priority quadrants, Story Maps, and Innovation Games®. We cover pruning feature trees, spending fake currency, and using visual metaphors, while truly identifying what the most important stuff really is. This was most recently presented at the Agile India 2013 conference in Bangalore.
Agile Everywhere!
Henrik Kniberg talks about how his journey implementing agile & lean methods at Spotify and Lego helped him apply agility in new & unexpected fields. Henrik will share his vision on how agility may evolve in the future and affect various areas of our lives.
About Henrik Kniberg
Henrik Kniberg is an Agile/Lean coach at Crisp in Stockholm, working primarily with Lego and Spotify. He enjoys helping companies succeed with both the technical and human sides of software development. During the past 15 years he has been CTO of 3 Swedish IT companies and helped many more get started with Agile and Lean software development.
Henrik is former board member of the Agile Alliance and works regularly with Mary Poppendieck, Jeff Sutherland, and other thought leaders. He is the author of “Scrum and XP from the Trenches” and “Kanban and Scrum, making the most of both” and “Lean from the Trenches“. These books are available in over 12 languages, have over 500,000 readers, and are used as primary guide to Agile and Lean software development by hundreds of companies worldwide. Henrik also created the viral animated videos “Agile Product Ownership in a Nutshell” and “Spotify Engineering Culture“.
The document provides an overview of Objectives and Key Results (OKRs), including:
- OKRs are goal-setting frameworks used by large, fast-growing companies consisting of objectives (what to achieve) and key results (how to measure achievement).
- OKRs originated from concepts like management by objectives and SMART goals, and were popularized by companies like Intel and Google.
- Effective OKRs are focused, align teams/goals, have commitment to tracking results, and stretch goals. Regular check-ins help with transparency and progress.
- The document outlines best practices for writing OKRs and implementing them in organizations through quarterly and annual goal-setting.
The document provides an overview of Agile methodology and Scrum framework. It describes that Agile is an alternative project management approach that uses short iterative cycles called sprints to incrementally deliver working software. Scrum is the most commonly used Agile framework and involves roles of Product Owner, Scrum Master, and team. It uses artifacts like Product Backlog and Sprint Backlog and events like Sprint Planning, Daily Scrum, and Sprint Review.
Here are the estimated story points for the items using Planning Poker:
Spain - 13
China - 13
Luxembourg - 5
Denmark - 8
South Africa - 8 (reference point)
Belize - 3
Training materials for Agile Scrum. Starts with an overview of Agile and Lean. Followed with the Agile Scrum key concepts like Product Owner, Scrum Master, Scrum Team and Product Backlog. Theory is complemented with learnings and best practices from real life software development.
A product manager is responsible for the overall success of a product by understanding customer needs and ensuring the product delivers value. Key responsibilities include defining product requirements and strategy, building business cases, conducting user research, creating roadmaps, and tracking metrics. The role requires balancing internal needs while representing customers externally throughout the product development process.
The document discusses Scrumban, which combines elements of Scrum and Kanban. It outlines 5 guiding questions about value, flow, quality, joy, and continuous improvement. It then describes 5 steps of evolution away from sprints, including removing artificial goals and delays. Estimation is de-emphasized in favor of proper slicing and forecasting using throughput. Metrics like WIP, flow diagrams and scatterplots with cycle times are recommended. Finally, it promotes several referenced books and resources on Scrumban and Kanban.
The document outlines the rules for a team-based game where players are split into roles to collaboratively build Lego animals. The roles are legs developer, body developer, head developer and tester. The rules describe 5 rounds of play with different collaboration restrictions for each round to encourage teamwork and test different skills. The testers use dice to introduce random defects ("bugs") and determine if completed animals pass testing or must be returned to the appropriate developer role for repairs.
Overview
- What is a User Story?
- User Story template
- examples of User Stories
- User Story Checklist
- Why not tasks?
- What is Acceptance Criteria?
- Examples of Acceptance Criteria
- Acceptance Criteria checklist
The document discusses Scrum, an agile framework for project management. It describes some issues with traditional waterfall models like high risks and uncertainty. Scrum aims to address these issues by allowing for frequent delivery of working software, adapting to changes, and welcoming late changes. The document then outlines the key aspects of Scrum like product and sprint backlogs, daily stand-ups, sprint reviews, and retrospectives. It discusses how Scrum has been used successfully in various domains like software, games, websites, and more. Finally, it covers some benefits of Scrum from different stakeholder perspectives.
The document provides an overview of Scrum, an agile framework for project management. It discusses the core components of Scrum including roles, artifacts, ceremonies, and values. The key roles are Product Owner, Scrum Master, and self-organizing Team. Projects progress through a series of sprints where work is pulled from the prioritized Product Backlog to the Sprint Backlog and completed work is demonstrated at Sprint Review meetings. Daily stand-up meetings and retrospective meetings aid in transparency and process improvement.
Metrics at Every (Flight) Level [2020 Agile Kanban Istanbul FlowConf]Matthew Philip
Slides as presented on Dec 8, 2020 at FlowConf organized by Agile Kanban Istanbul. https://www.flowconf.com/
Organizational change often stalls out at departmental boundaries, whether that is IT or another division. How do we help organizations connect vertically and horizontally to realize the outcomes that they have when undertaking large-scale change efforts?
Join this session to learn from a case study of a bank that combined flight levels and metrics to bridge their departmental boundaries and recognize gains not only in software delivery effectiveness but unifying higher-level strategy.
This document provides an overview of Scrum training. It introduces the trainer, Deniz Gungor, and their background. It then outlines the agenda, which will cover Scrum fundamentals, a Scrum simulation game, and the Scrum framework. Key aspects of Scrum are defined, including self-organizing Scrum teams, iterative delivery, the Product Owner, Scrum Master, Development Team, events like the Daily Scrum and Sprint Review, and artifacts like the Product Backlog and Sprint Backlog. The training will help participants understand and apply the Scrum framework to projects.
The document discusses reversing the "tests pyramid" approach to address technical debt in legacy code. It notes that unit testing is difficult for code without separation of concerns, but refactoring without tests is risky. It proposes starting with high-level tests to gain confidence for refactoring into units and writing unit tests incrementally. However, end-to-end tests are long to maintain, and if needed, the architecture may be flawed. Reversing the tests pyramid and refactoring code in this way takes time but pays back technical debt and allows for sustainable changes. Beware of refactoring just for its own sake - focus on removing duplication and improving changeability.
Presentation from AgileEE 2012 in Kiev (October 2012) and XP Days Ukraine 2012 in Kiev (November 2012) about evolution of Agile processes in team during project lifecycle.
This document summarizes an Agile consultant's experience helping a large company survive by implementing Agile practices. It describes some initial problems like long releases, outsourcing issues, and lack of responsibility. It then discusses how the company tried different Agile techniques over the year, such as fast lane releases, multi-product ownership, and having multiple product owners. While some experiments like the architect's sandbox caused issues, overall tweaking Scrum practices and focusing on interactions helped achieve good results in a challenging environment.
Nathaniel Cadwell: The Art of Facilitation Agileee
The document discusses the art of facilitation. It begins with an introduction activity where participants discuss the worst meeting they've ever been in. It then covers the benefits of collaborative group decision making. The bulk of the document focuses on the mindset and skills of an effective facilitator, including preparing for and planning meetings, as well as tools and processes for facilitating collaborative meetings. Key aspects covered include being neutral and helping the group process rather than content. The goal is for the facilitator to help improve how groups identify and solve problems and make decisions.
Henrik Kniberg: Lean from the Trenches keynote @ AgileEEAgileee
This document summarizes a presentation about applying lean and agile principles to a large government project in Sweden called PUST. It describes how the project team used techniques like slicing work into small customer-focused stories, daily stand-ups, iterative planning and releases, continuous improvement retrospectives, and tracking metrics to successfully deliver the project on time and on budget while continuously improving their process.
Раскрась свой Бэклог! Или о том как принимать решения на основе разных типов ...Timofey (Tim) Yevgrashyn
Вы знали, что Бэклог Продукта может содержать элементы разного типа? Да-да, об этом еще дедушка Швабер говорил. Я наблюдал молодых СкрамМастеров и Владельцев Продукта, которые бьются головой об стену мучаются вопросом, что можно положить в Бэклог Продукта, а что нельзя, и если нельзя, то куда.
В докладе мы рассмотрим несколько основных типов Элементов Бэклога, на примерах посмотрим как и на что они влияют. И самое главное обсудим как принимать решения о планах итерации и выпуска, на основе комбинации разных типов.
Nick Oostvogels: 5 Arguments Against KanbanAgileee
Kanban faces several common arguments against its adoption. These include concerns that Kanban will:
1) Limit the ability to plan work.
2) Cause work to take longer to complete.
3) Result in work getting stuck if work-in-progress limits are enforced.
4) Not align with stakeholder priorities if they do not consider flow.
5) Reduce team cohesion by focusing on individual tasks rather than collaboration.
Piotr Burdylo: Managing developers is complexAgileee
Managing software developers is complex. It is best to create an environment where developers can manage themselves rather than trying to directly manage them. The document discusses frameworks like Cynefin and core values that can help guide creating a self-organizing environment for developers to be productive and contribute to the overall goals and culture of the organization.
The document discusses the evolution of management over time. It describes how early companies did not have dedicated managers, but as companies grew larger problems arose regarding quality, integration, and motivation. This led to the emergence of many specialized manager roles to address these issues. However, managing problems and people directly can fix only symptoms, not root causes. Better management focuses on enabling purpose, autonomy, and mastery for self-organizing teams. The role of managers is to coach and empower teams rather than control them.
Robin Dymond: "Your Brain and Better Product Development"Agileee
The document discusses recent discoveries in brain science and how they relate to product development. It explains that the prefrontal cortex has limited resources for problem solving and insights emerge when larger brain regions are engaged. It also discusses how the brain's threat response hinders thinking and how understanding one's internal states can help manage cognitive processes and insights. Strategies presented include practicing mindfulness, managing emotions, focusing attention on direct experiences, and using Scrum to address the brain's social needs.
Lyssa Adkins & Michael Spayd: The Essential Transformations: How Agile Calls ...Agileee
The document discusses how agile calls for change in individuals and organizations. It notes that the world is changing quickly and competition is forcing change. Agile reveals faults and opportunities for improvement. An agile coach acts as a human change specialist to guide individuals and teams through the change process from familiar ways of working to more emerging practices. The coach's model of change involves guiding people through a "zig-zag zone" of discomfort as new practices are adopted. Real-life examples are provided of how different roles undergo transformations in how they work through adopting agile. When enough individuals change, organizational transformation occurs.
Kanban implementation experience discusses reasons to convert from Scrum to Kanban including making the process more visible and allowing releases at any time. It covers Kanban features like continuous work in progress limits and how time and cost compare between Kanban, Scrum, and Targetprocess 1.0. The document also mentions tools like Git, BDD, Jenkins, and techniques like continuous integration, personal Kanban, and time tracking being turned off.
This document discusses synchronizing multiple Scrum teams using Kanban principles. It begins with an overview of Scrum and problems with multi-team coordination. It then provides a overview of Kanban and key concepts like one-piece flow and limiting work-in-progress. The document applies these Kanban concepts to Scrum by removing iterations and instead using completed stories as synchronization points between teams. It advocates for decoupling Scrum activities from iterations to allow continuous work and integration.
The document discusses how to change the world by changing social systems. It recommends considering the system as a whole, the individuals within the system, the interactions between individuals, and the environment surrounding the system. For each, it provides questions to ask and suggests focusing on a few key behaviors that can lead to widespread change if adopted by influential individuals and spread through social networks. The overall approach is to guide and encourage change while respecting the complex and adaptive nature of social systems.
This document discusses software development approaches and experiences over the past decade. It references extreme programming (XP) and pair programming. It also discusses adopting rapid feedback cycles and experimenting with different practices like promiscuous pairing to adapt quickly to changing needs and market conditions. Maintaining high efficiency while embracing instability through a "beginner's mind" is highlighted.
Agile Testing. Risks, Uncertainty and Why It All WorksAgileee
The document discusses key principles and practices of agile testing, including delivering working software frequently, adapting to changing business needs, eliminating speculation, checking alignment between intentions and actual needs, and emphasizing a whole-team approach to testing where the team succeeds or fails together. It outlines nine key agile testing practices such as acceptance test-driven development, test-driven development, exploratory testing, test automation, continuous integration, and automated deployment.
The document discusses motivation in the workplace and proposes an alternative model called Motivation 3.0. It notes that traditional extrinsic motivators like money and bonuses can actually decrease performance on complex tasks. Motivation 3.0 focuses on providing workers with autonomy, mastery, and a sense of purpose to boost intrinsic motivation. Managers are advised to treat employees like volunteers and help them connect their personal visions to the company's larger goals.
Effective Software Development in the 21st CenturyAgileee
The document discusses principles of effective software development in the 21st century. It covers topics like craft, the cooperative game nature of software development, knowledge acquisition through continuous integration, and flow management to reduce unnecessary decisions and bottlenecks. The overall message is that software development requires skills in communication, adapting to situations, learning early, and understanding how people and processes interact.
Myths, Legends and Monsters of Enterprise AgilityAgileee
The document discusses myths, legends, and monsters that may arise when scaling agile practices in an organization. Myths are used to justify the status quo and involve heroic figures, while legends spread rumors and lessons learned. Monsters represent resistance and require confronting objections. The document provides examples of each and suggests approaches like communication, negotiation, and aligning on values to address concerns raised by myths, legends, and monsters.
The document discusses the concept of software craftsmanship, which values not only producing working software but well-crafted software. It emphasizes creating software that adds value over time through change. It also stresses the importance of individuals, interactions, and building a community of professionals, as well as collaborative partnerships with customers. The document urges software developers to take pride in their work, stop writing bad software, and practice their craft as professionals.
This lightening talk presentation introduces the concept of lean startups. It advocates building a minimum viable product, measuring how customers respond to it, learning from that customer feedback, questioning assumptions, getting out of the building to observe customers, and iterating based on lessons learned. The presentation uses photos to illustrate each of these points. It concludes by recommending following thought leaders in lean startup on Twitter and reading foundational books on lean startup and customer development.
Lightening Talk: lama sutra of retrospectiveAgileee
This document provides a variety of retrospective formats and approaches for project teams to evaluate their process, including structured methods like the six thinking hats and Pomodoro techniques, question-based retrospectives, and spider web and start-stop-continue formats. It also recommends establishing action plans and appreciating successes as part of the retrospective process.
This document outlines 12 principles for software development. It emphasizes taking action over just gaining knowledge, focusing on individuals and interactions rather than processes, prioritizing working software over documentation, collaborating with customers over contract negotiation, and responding to change rather than sticking rigidly to plans. The final lines call on others to take action and lists the name of the author.
This document discusses the concept of "READY" in agile development. It defines READY as having clear goals and criteria, understanding how to complete the work, having the ability to complete it in the sprint, and managing risks and dependencies. Work that is not READY causes problems like missed deadlines and unclear acceptance criteria. The document recommends using READY as a quality gate to prevent unprepared work from being committed to sprints. It provides examples of how to structure product backlogs and incrementally prepare stories to become READY. The results section notes low adoption rates for READY compared to definitions of done.
This document discusses coaching creatives to generate new ideas by drawing inspiration from deceased artists. It touches on topics like perfectionism, passion, purpose, and using agile techniques to help creatives explore their work. The document also references hosting a Q&A and mentions the organization AgileDC.
This document provides a high-level summary of the Agile and CMMI conference held in Kiev, Ukraine on September 23-24, 2011. The conference addressed some common myths about Agile and CMMI, providing context on both frameworks. It also reviewed the history and structure of CMMI, outlining the key process areas covered at different maturity levels.
The document discusses the purpose and process of conducting a retrospective meeting. It uses a story about Santa Claus and his workshop producing toys as an analogy for the roles and goals of a Scrum team. The retrospective process involves 5 phases - establishing what was supposed to happen, what really happened, identifying differences and causes, and determining improvements for the next iteration. Conducting regular retrospectives helps teams continuously improve their process.
1. Agile @ Home
Agile Eastern Europe keynote
Keynote 2012-10-06
(annotated slides)
Henrik Kniberg
Agile/Lean coach
www.crisp.se
2. Let me show you how some of
the ideas from Agile and Lean
software development can be
used in a different context: At
Home!
We have 4 small children, age 1-8.
Needless to say, that can get
complicated sometimes.
Over the years, we’ve found that
many of the practices and ideas
from the Agile/Lean toolkit can
really improve life at home!
Here are some examples of things
that have worked particularly well.
Henrik Kniberg 2
3. Definition Travel Agile
of Done Spike party
Kitchen planning
WIP
Limit
Clothes
WIP
Limit
Homework Kitchen
Burnup Value Stream
chart Map
BigFamilyTrip
Kanban
board
3
4. This is my focus board.
Some would call it a
Personal Kanban
system.
The stickies on the
bottom half are
independent actions,
such as
”buy a new shaver”
or ”call client X”
The index cards on the top half are
”projects”, with stickies showing the
next 1-2 actions for that project.
Let’s look closer...
Henrik Kniberg 4
5. For example preparing
this talk
Or writing a foreword
to someone’s book
Or playing with my
band at a wedding
Some actions
have deadlines
The goal is to focus on
at most 1 or 2 projects
at a time, and minimize
multitasking.*
Henrik Kniberg *Multitasking sucks. See 5
www.crisp.se/henrik.kniberg/multitasking-name-game
6. This part of the board
is for practing new I try to practice one
habits new habit at a time for
several weeks...
... until it becomes,
well, a habit!
Right now I’m trying to learn to
start each day by finishing the
most important thing for that
day, BEFORE opening the inbox
and getting sucked into the
void.
Henrik Kniberg 6
7. We use focus boards for family
stuff too. Here is a party that
we were preparing. 3 sections
on the left refrigerator door
”Must be done”, ”Should be
done”, ”Bonus stuff”
As things get done, we move
the notes to the other
refrigerator door. The ”Done
Door” so to speak...
Here is when we were
preparing for Big Christmas
Invasion with lots of friends and
family staying for several days.
Henrik Kniberg This board even had a time 7
plan!
8. This board was for a BBQ party
a few years ago. Guests would
pair up with somebody they
don’t know too well, grab a
card, and get going!
I know. But seriously, guests
actually like to help :o)
To our surprise, small kids (even
3 year olds!) quickly decoded
our system and hacked it!
”Hey, things that go on the
board actually Happen!”
”We can make grownups
Do Things!”
So... ice-cream cards starting
appearing on the board...
Henrik Kniberg 8
9. So now we use this quite
often :o) As usual, things that are
Here the kids are planning Done go on the right
and preparing a birthday refrigerator door
party
Each stickynote is a
”feature” of the party.
When time started running out, the
kids automatically started descoping.
Imagine if all project
Henrik Kniberg ”What’s more important, balloons, or
managers could learn to 9
cake? We won’t have time to finish do that to! :o)
both!”.
10. Once Dave (7 yrs at the
time) was behind on his He found it hard to stay
homework, and had quite a focused and motivated
few pages to do
Henrik Kniberg 10
11. So I showed him how to
create a burnup chart.
Here’s the page numbers he
had to finish
This is the ”finish line”. If he
crosses this before bedtime, the
remaining time is play-time!
”Every 5 minutes or so, check This is the ”timebox” – bed time
the time and put and write X for at 8pm
the page number that you are
working on”
After 15 minutes he noticed
something upsetting:
”Time Keeps Going even when
I’m Not Focusing!”
Here’s the timeline. Each
number is a 5 minute interval
(big hand of the clock)
Henrik Kniberg 11
13. The chart helped him get back
into focus, without me having to
nag or remind him.
A clear and obvious
visualization, showing the
benefit of focusing.
Even project
managers can get
it :o)
Henrik Kniberg 13
14. He finished in record time, and
had time to play!
However, we should have made
sure testing & validation was
included in Definition of Done,
since there were some ”defects”...
oh well, next time :o)
Sometimes when he has very much
homework to do, he says ”Daddy, I’d
like to create one of those graph
thingies again, because I want to get
my homework done quickly!”
Henrik Kniberg 14
15. We recently came back from a
BigFamilyTrip – a 6 month trip that took
us through 8 countries.
A trip like that takes quite some
planning and preparation. We used this
planning board for the 8 months or so
we had to prepare for the trip. Very
useful.
Henrik Kniberg 15
16. We decided on a departure date (Oct 1) from the
very beginning, just to make sure the trip happens.
Timeline, with red arrow that
moves. Reminds us that time
keeps going.
Clearly defined
Yellow stickies show when we purpose of the trip
The columns are ”To do”,
”Next”, ”Ongoing”, and plan to be in which country
”Done!”
The three horizontal
swimlanes are ”Must do”,
”Should do”, and ”Bonus
stuff”
Dreams & visions. We
downloaded some inspiring
pictures from Google images,
to exemplify the type of things
we were hoping to experience
during the trip.
Henrik Kniberg 16
17. We did a ”spike” (practice
run), a 4 day trip to
London.
Our hope was that,
anything that can go
wrong, will go wrong on
this trip.
...so we can learn from it
and avoid problems during
the Big trip.
Henrik Kniberg 17
18. We learned what kind of stuff to
pack. And we learned that the kids
(even Emma, 3 yrs) can carry
their own stuff. We learned that Oh, and we had fun too :o)
our baby carriage sucked and
needed to be replaced (broke
after 1 check-in!). And more!
Henrik Kniberg 18
19. After coming we could already
cross some things off the Dream
Gallery (such as the double decker
bus)...
Henrik Kniberg 19
20. ... and we could turn our learnings
into concrete actions (such as ”buy
a better baby carriage”).
Henrik Kniberg 20
21. Oct 1 – Off we went!
Hej då, vi ses i vår!
Följ med på resebloggen: bigfamilytrip.posterous.com
Hälsningar Henrik & Sia & David & Jenny & Emma & Peter
Japan
Västindien
Peru
Nya
Zealand
Henrik Kniberg 21
22. We had an awesome trip! Read more The long-lived planning board and
on http://bigfamilytrip.posterous.com, the 4 day London ”spike” really
we wrote down we we’ve learned about helped us set the trip up for success.
travelling with kids.
22
23. When we got home, 6 months later,
we were surprised at how quickly the
They wanted to pull out all the toys
house got completely messed up,
and clothes they had missed
especially the kids’ rooms.
Just about impossible for them to
take responsibility for their own stuff.
It was just too much.
Henrik Kniberg 23
24. We didn’t really have that
problem during the trip.
... because look: the kids
could only fit so much
stuff in their bags. And
they had to carry their
own stuff!
There’s a term for that in the
lean community:
A ”WIP Limit”
(work-in-progress limit).
WIP limits stop things
from getting out of hand!
Henrik Kniberg 24
25. At home there were no
WIP limits.
So we decided to change
that.
The drawers + the closet =
The WIP limit. You can only
keep as many clothes as
you can fit there. And there
should be extra slack in
each drawer, it should not
be crammed.
Henrik Kniberg 25
26. To implement this, they put
all their clothes in one place
(a ”temporary inbox” you
might say)
Henrik Kniberg 26
27. I handed them one item at a
time and asked ”In or Out?”
”In” means: decide where
that particular thing lives,
and put it there now.
Slack rule: no drawer is
allowed to be crammed full
”Out” means: throw it in the
box (to be sold or given
away or trashed at a later
time).
I was impressed by how
much stuff the kids were
willing to do away with
(many boxes! let us know if
you need anything!)
Henrik Kniberg 27
28. Voila! Tidy room!
And, more importantly, a room
that has few enough things, so
the kids can realistically take
responsibility for keeping it tidy.
Henrik Kniberg 28
29. We had the same
problem in the kitchen
It was a mystery! Why were
we spending so much time in
the kitchen, cleaning dishes,
filling and emptying the
dishwasher, etc? Felt like
hours every day.
Why didn’t we have this
problem while travelling? Heck,
we didn’t even have washing
machines while travelling!
Answer: WIP limits! In our
rental houses and apartments,
there were only a few plates
and utensils, barely enough for
everyone in the family.
So we decided try
WIP limits in our kitchen
at home.
Henrik Kniberg 29
30. A quick calculation revealed
that each one of us uses about
8 things per meal (plates,
utensils, cups, etc).
8
With 3 meals per day,
that is about 24
things.
8
8
31. With 6 people in the
family, plus some shared
stuff like pots, that adds
8 8 8
up to over 160 things per
day!
16
8 8 8
8 160+
8 8
8 8 8
160+ things to take out,
wash up, and put back in
again. That’s a lot!
8 8 8
8 8 8
32. If we instead Limit WIP
to one ”set” per person
(one of each type of
8 thing, total of 8 things)...
16
8
And each person washes
their own stuff....
8
8
8
(except Peter, he’s only 1
yr old...).
8
34. Each person has their
own ”set” of 8 things, in
a dedicated place in the
drying tray.
Henrik Kniberg 34
35. ”Definition of Done” for a A simple rule that even a
meal is when your set of 3 year-old can learn easily
things are back in it’s
place, clean.
If you forget to wash
your stuff then, well,
you’ll regret it next ... because your plate will
mealtime. be icky and hard-to-
Henrik Kniberg clean :o) Effective feedback loops 35
beat nagging any day :o)
36. The new system worked
surprisingly well! Why?
1-2
Because with the old system, a
days!
single item, such as a cup, would
take up to 2 days (or longer!) to
make it out and back into the
cupboard.
With 160+ items in play, each taking
2 days or so to pass through the
kitchen... well, no wonder the
kitchen was often a mess!
1
Mon 7:00
3
4 Mon 11:00
Mon 22:00
2
Tue 22:00
Typically we’d take out the old
batch and insert the next batch in
the evening.
...because filling/emptying
dishwashing machines is boring, so
we resisted it ’till the last responsible
moment.
Henrik Kniberg 36
37. With the new system, we
skip the cupboard
Instead, everything lives in
the drying tray, comes out
for the meal, and is back
<1 in the drying traywithin an
hour! hour!
The kitchen mess
never has time to
1 Mån kl 7:00
build up!
Mån kl 7:30
2
... and we skip the
dishwasher! Ironic huh?
Henrik Kniberg 37
38. The new system
works great! The system is a bit
brittle though.
We spend MUCH less
time doing dishes
It breaks down when
we have guests
coming over, for
And the kitchen is example.
for the most part
nice and tidy In those cases we
temporarily revert to
the old system, with
dishwashing machine
and batching.
But the new limited-WIP
system has become our
”default system”, for
everyday use.
Henrik Kniberg 38
39. Definition Travel Agile
of Done Spike party
Kitchen planning
WIP
Limit
Clothes
WIP
Limit
Homework Kitchen
Burnup Value Stream
chart Map
BigFamilyTrip
Kanban
board
39