Deze presentatie heb ik op Eurostar2010 gegeven en op de Ordina InnoveerJijMee sessie op 31 jan 2011. Het gaat over hoe je een proces opzet waarbij kwaliteit vooropstaat en hoe je je team \'test-infected\' krijgt.
Quality is not the responsibility of testers alone, but of the whole agile team. It should be a shared mindset and definition agreed upon by the team. Several techniques can help build quality in, including defining acceptance criteria through conversations between product owners, developers and testers; practicing test-driven development; and ensuring story kick-offs and "shoulder taps" between team members to facilitate collaboration and catch issues early. The document discusses the importance of collaboration, automation, and not trading off quality to deliver features quickly.
The document argues that the term "Quality Assurance" (QA) is a misnomer for testers' actual work, and should be replaced by "Quality Intelligence" (QI). QA implies that testers assure quality, but they actually provide information about quality through testing. This information role is analogous to Business Intelligence. The document proposes replacing QA with QI to better reflect that testers transform raw product data into useful quality information through techniques like testing.
Team Playbook – Practices to increase the performance of your teamDeiser
This document outlines techniques and activities for improving team effectiveness contained in the Team Playbook. It includes workshops for assessing team health, building connections between customers and teams, and improving work techniques. Specific plays and examples provided include aligning teams around shared values, demonstrating trust through a pre-mortem activity, and a 24-hour innovation project called ShipIt. The goal is to provide teams with the right tools, practices, and people to unleash their potential through great teamwork.
Software Testing’s Future—According to Lee CopelandTechWell
The original IEEE 829 Test Documentation standard is thirty years old this year. Boris Beizer’s first book on software testing, Software Testing Techniques, also passed thirty. Testing Computer Software, the best-selling book on software testing, is more than twenty five. During the past three decades, hardware platforms have evolved from mainframes to minis to desktops to laptops to smartphones to tablets. Development paradigms have shifted from waterfall to agile. Consumers expect more functionality, demand higher quality, and are less loyal to brands. The world has changed dramatically—and testing must change to match it. Testing processes that helped us succeed in the past may prevent our success in the future. Lee Copeland shares his insights into the future of testing, including his views in the areas of technology, organization, test processes, test plans, and automation. Join Lee for a thought-provoking look at creating a better testing future.
The document discusses the Agile methodology for project management. It began in 2001 with the Manifesto for Agile Software Development. Agile is a mindset and way of working together to deliver value to customers through principles like welcoming changing requirements, frequent delivery of working software in small batches, collaboration between business and development teams, and responding to change. Common Agile methods in use today include Scrum, Kanban, XP (eXtreme Programming) and Lean. The document emphasizes that Agile is not just for software but can be applied to any type of work.
Many of today's large organisations are complex (sometimes even hostile) environments where status-quo, fire-fighting and conformity crush most chances for innovation and growth.
Like Mars, they are turning into desolate, lifeless places with seemingly little to offer humans.
But it doesn't have to end this way.
In this session, Claudio will illustrate stories, strategies, katas, workflows and tools to bring "learning streams" to the surface, dramatically accelerate the rate of change and form the conditions for teams and individuals to flourish and bring the best of their work to the world.
Quality is not the responsibility of testers alone, but of the whole agile team. It should be a shared mindset and definition agreed upon by the team. Several techniques can help build quality in, including defining acceptance criteria through conversations between product owners, developers and testers; practicing test-driven development; and ensuring story kick-offs and "shoulder taps" between team members to facilitate collaboration and catch issues early. The document discusses the importance of collaboration, automation, and not trading off quality to deliver features quickly.
The document argues that the term "Quality Assurance" (QA) is a misnomer for testers' actual work, and should be replaced by "Quality Intelligence" (QI). QA implies that testers assure quality, but they actually provide information about quality through testing. This information role is analogous to Business Intelligence. The document proposes replacing QA with QI to better reflect that testers transform raw product data into useful quality information through techniques like testing.
Team Playbook – Practices to increase the performance of your teamDeiser
This document outlines techniques and activities for improving team effectiveness contained in the Team Playbook. It includes workshops for assessing team health, building connections between customers and teams, and improving work techniques. Specific plays and examples provided include aligning teams around shared values, demonstrating trust through a pre-mortem activity, and a 24-hour innovation project called ShipIt. The goal is to provide teams with the right tools, practices, and people to unleash their potential through great teamwork.
Software Testing’s Future—According to Lee CopelandTechWell
The original IEEE 829 Test Documentation standard is thirty years old this year. Boris Beizer’s first book on software testing, Software Testing Techniques, also passed thirty. Testing Computer Software, the best-selling book on software testing, is more than twenty five. During the past three decades, hardware platforms have evolved from mainframes to minis to desktops to laptops to smartphones to tablets. Development paradigms have shifted from waterfall to agile. Consumers expect more functionality, demand higher quality, and are less loyal to brands. The world has changed dramatically—and testing must change to match it. Testing processes that helped us succeed in the past may prevent our success in the future. Lee Copeland shares his insights into the future of testing, including his views in the areas of technology, organization, test processes, test plans, and automation. Join Lee for a thought-provoking look at creating a better testing future.
The document discusses the Agile methodology for project management. It began in 2001 with the Manifesto for Agile Software Development. Agile is a mindset and way of working together to deliver value to customers through principles like welcoming changing requirements, frequent delivery of working software in small batches, collaboration between business and development teams, and responding to change. Common Agile methods in use today include Scrum, Kanban, XP (eXtreme Programming) and Lean. The document emphasizes that Agile is not just for software but can be applied to any type of work.
Many of today's large organisations are complex (sometimes even hostile) environments where status-quo, fire-fighting and conformity crush most chances for innovation and growth.
Like Mars, they are turning into desolate, lifeless places with seemingly little to offer humans.
But it doesn't have to end this way.
In this session, Claudio will illustrate stories, strategies, katas, workflows and tools to bring "learning streams" to the surface, dramatically accelerate the rate of change and form the conditions for teams and individuals to flourish and bring the best of their work to the world.
Tom Morgan - July 29, 2014 - From Chaos to Collaborative CommunitiesJAX Chamber IT Council
This document summarizes the transformation of an organization from dysfunctional and chaotic processes to collaborative agile communities. It describes how the organization realized their old ways were no longer working, tried quick fixes that failed, and saw evidence of problems like being unable to fix dysfunction and considering killing products. They started transforming by learning agile practices, preparing leaders as agents of change, and penetrating the organization. Their transformation roadmap involved team kickoffs and boot camps to learn. They saw positive results like improved customer satisfaction, being under budget, and releasing software monthly instead of 3 times per year. Through collaborative cross-functional teams and focusing on work items instead of tools, chaos was replaced with predictability, quality, costs down, and happier individuals and
Building lean products with distributed agile teamsIgor Moochnick
- The document discusses principles for building lean products with distributed agile teams, emphasizing constant communication, feedback, transparency, and flexibility.
- Key aspects include prioritizing customer needs, continuous integration and deployment, minimizing waste and bureaucracy, and making decisions at the last responsible moment based on ongoing learning.
- Success requires open communication across all teams, with a focus on removing impediments, capturing feedback, and constantly improving through retrospectives.
The document contains questions about how teams are organized, whether they use a backlog or requirements document, how often they deliver value through sprints, who is assigned roles like Scrum Master and Product Owner, who is invited to sprint reviews, and the length and attendees of daily standups. It emphasizes the importance of continuous delivery, having people in agile roles, inviting everyone to reviews, and using a backlog to get more feedback and keep customers happy. It also discusses how work should flow through determining goals, creating ideas, prioritizing in a backlog, inviting all teams to plan, and implementing solid agile practices.
Павел рассказал о методологии Spotify Squad Health Check Model и как он использует ее в EPAM.
✔Сначала мы решили понять какие проблемы нас окружают и анализировать их.
✔Вам, как проектному менеджеру нужно оправдать доверие сотрудников, поэтому не обязательно проводить интервью с сотрудниками, можно просто за чаем или в курилке спросить их мнение.
✔Мы получили полную картину о том, что происходит на проекте, тренды, многие негативные тренды мы убрали и ключевые моменты улучшили.
Павло Камишов “Health check model: refined edition” Lviv Project Management DayLviv Startup Club
This document summarizes Pavel Kamyshov's approach to conducting health checks for teams working on projects. Some key points:
- The model is refined from Spotify's squad health check model and focuses on collecting feedback from individuals rather than just the team level.
- Feedback is collected anonymously on topics selected jointly by the team and coach. Checks are done once every 1-2 months through individual conversations.
- Characteristics like code quality, development process, team atmosphere, and overall satisfaction are evaluated. Trends over time can be identified from the collected data.
- Previous health checks helped improve areas like codebase health, suitable processes, and overall project satisfaction. Initiative groups were formed to address issues
Organisations must celebrate failure to achieve success Aidan Casey
This document discusses how organizations can achieve success by embracing failure. It recommends establishing a growth mindset culture where failure is viewed as an opportunity to learn and improve. Key aspects include shifting from only focusing on delivering features to prioritizing experimentation, establishing trust so teams feel safe to fail, and regularly reviewing failures to learn from mistakes. Metrics like the ICE score and AARRR can help evaluate experiments and determine their potential impact. Overall, the document argues that failure is inevitable and should be seen as a starting point for growth rather than something to avoid.
Beyond Value Streams: Experimental Evolution in ActionClaudio Perrone
These are the slides from my keynote for Lean Agile Scotland 2013. In this session, I shared stories, workflows and practical thinking tools that illustrate how the act of deliberately capturing and evolving "learning streams" (as opposed to - or rather in addition to - the more conventional value streams) can lead to surprising consequences.
The document discusses the Context Driven School of Testing. It outlines the seven basic principles of the Context Driven School, which focus on the importance of context, the unpredictability of projects, solving problems rather than following practices, testing as an intellectual process, and cooperation throughout projects. It also briefly describes five schools of testing - Analytical, Factory, Quality Assurance, Context Driven, and Agile - and notes that the Context Driven community values challenges and debate. The document emphasizes finding community and understanding different perspectives to improve testing practices.
Ho Chi Minh City Software Testing Conference January 2015
Software Testing in the Agile World
Website: www.hcmc-stc.org
Author: Lee Copeland
The IEEE 829 Test Documentation standard is thirty years old this year. Boris Beizer’s first book on software testing also turned thirty. Testing Computer Software, the best selling book on software testing, is twenty-five. During the last three decades, hardware platforms have evolved from mainframes to minis to desktops to laptops to tablets to smartphones. Development paradigms have shifted from waterfall to agile. Consumers expect more functionality, demand higher quality, and are less loyal to brands. The world has changed dramatically and testing must change to match it. Testing processes that helped us succeed in the past may prevent our success in the future. Lee Copeland shares his insights into the future of testing, sharing his Do’s and Don’ts in the areas of technology, organization, test processes, test plans, and automation. Join Lee for a thought provoking look at creating a better testing future.
The Leader's Guide Workshop - Pivotal Labs TokyoJeana Alayaay
These are the slides that were used for the 3rd Leader's Guide Workshop that was help at Pivotal Japan on Friday, 6/17/16. The content was developed by Janice Fraser, the Director of People for Pivotal. It is based on The Leader's Guide by Eric Ries and is officially endorsed by him.
Lean startups fuse customer development, lean production, and continuous delivery. They follow four steps: customer discovery to identify problems, customer validation to test solutions, customer creation to begin sales, and company building. The methodology emphasizes eliminating waste and continuous learning through building minimum viable products and validating assumptions with customers via a "pivot" as needed. Key techniques include agile development, continuous integration and deployment to learn quickly through fast iterations.
My take on Eric Ries' book The Lean Startup, as presented to my colleagues at XING Barcelona.
DISCLAIMER: This is a sketched presentation. Can be disappointing.
This document describes Sprintz.Work, a 5-week program that provides trained remote teams and coaching to help companies innovate. It addresses challenges like getting innovation teams to focus remotely. The program is based on design sprints but lasts 5 weeks instead of 5 days, allowing more time to develop ideas. Managers work with a certified team for 10-15 hours per week and receive training, tools and lifetime access to innovation resources. The goal is to achieve more innovation results in 5 weeks than traditional short sprints through this structured remote process.
This presentation was presented in Unicom World Business Summit Conference 2015. It talks about using Lean Startup method for situation where both the problem and solution is not clear. Team can using Lean Ux and Lean analytics techniques. We presented our experience about using Lean Startup and Lean Ux techniques in one of our product development. In this development we iteratively developed the product using the Lean startup method. We covered the experience of how Lean Ux methods like ethnographic studies, Wireframing, Landing pages can be used effectively to get feedback
This document discusses technical debt and strategies for managing and selling technical debt rearchitecture projects. It defines technical debt as work that is postponed to a later time, such as lack of testing or architecture planning. While some debt can be useful for time to market goals, ignoring debt accumulation can slow a project over time. The document provides examples of technical debt elements to examine in a codebase and recommends conducting due diligence to understand existing debt. It also presents stories and metaphors to help explain the risks of debt to business stakeholders and the value of rearchitecture projects when needed.
This document discusses how to effectively adopt an agile mindset and practices. It begins by looking at the original goals of going agile but finds that in reality, many agile adoptions face problems and challenges. It discusses the "broken windows theory" - how small issues can lead to bigger ones if not addressed. However, instead of focusing on problems, it recommends taking an Appreciative Inquiry approach through retrospective meetings. This focuses the team on successes and strengths, envisioning future improvements through positive dialogue to act as a continuous engine for agile transformation.
1) The document discusses the Minimum Viable Product (MVP) process which helps entrepreneurs test new products and gather feedback to make improvements.
2) An MVP is not a finished product but a process to validate critical assumptions as efficiently as possible to improve chances of success.
3) Common MVP methods mentioned include fake door product videos, landing pages, piecemeal launches, and the wizard of OZ technique.
This document discusses balanced teams and their importance for delivering value to users. It outlines the roles of designers, developers, and product managers in a balanced team. Each role has obligations to understand customers, envision solutions, make decisions, and facilitate balance within the team. Balanced teams value multi-disciplinary collaboration and iterative delivery focused on customer value. The document advocates for empathy, trust, mutual respect between roles, and acting as one product team to achieve business value.
This document discusses building a culture of self-governance at a company. It outlines four types of organizational culture and advocates for the fourth type, self-governance, where employee values guide their own behavior. The document then discusses establishing shared values, principles, and practices at the company to achieve this culture. It provides examples of values and principles for the product and engineering team, such as "Clear the Path" and building products customers love. Finally, it encourages being prescriptive, applying constant gentle pressure, being patient, and appreciating those who provide feedback to help build this culture.
Anko Tijman - Building a Quality Driven Team - EuroSTAR 2010TEST Huddle
EuroSTAR Software Testing Conference 2010 presentation on Building a Quality Driven Team by Anko Tijman. See more at: http://conference.eurostarsoftwaretesting.com/past-presentations/
Good agile / Bad agile: Proving the value of Agile to a skeptical organizationAlan Albert
Is Agile worth it?
What value can being Agile bring to your organization?
Done right, Agile software development methodologies can help your organization deliver greater value to customers and other stakeholders more efficiently and with reduced risk.
Done wrong, Agile methodologies become an endlessly iterating feature factory, facing an ever-growing backlog.
In this interactive session, attendees discussed:
- How to identify what’s most valuable to build next
- How to ensure that the features you build are not just functional, but used and valued
- How to measure and effectively communicate the value that you create
Led by Alan Albert of MarketFit, this session at Agile Vancouver explored theory, examples, and exercises showing how to unlock the power of discovering, creating, and communicating value.
Measuring team performance at spotify slideshareDanielle Jabin
How do we actually know if our teams are doing well? Is gut instinct enough? Furthermore, in a rapidly growing organization such as Spotify, how can we ensure some sort of consistency in our baseline level of Agile knowledge across the technology, product, and design organization?
In this presentation, I’ve shared techniques we have developed and use at Spotify to benchmark health and performance for our teams and some tactics we use to bring them closer to—and beyond!—being the best teams they can be.
Tom Morgan - July 29, 2014 - From Chaos to Collaborative CommunitiesJAX Chamber IT Council
This document summarizes the transformation of an organization from dysfunctional and chaotic processes to collaborative agile communities. It describes how the organization realized their old ways were no longer working, tried quick fixes that failed, and saw evidence of problems like being unable to fix dysfunction and considering killing products. They started transforming by learning agile practices, preparing leaders as agents of change, and penetrating the organization. Their transformation roadmap involved team kickoffs and boot camps to learn. They saw positive results like improved customer satisfaction, being under budget, and releasing software monthly instead of 3 times per year. Through collaborative cross-functional teams and focusing on work items instead of tools, chaos was replaced with predictability, quality, costs down, and happier individuals and
Building lean products with distributed agile teamsIgor Moochnick
- The document discusses principles for building lean products with distributed agile teams, emphasizing constant communication, feedback, transparency, and flexibility.
- Key aspects include prioritizing customer needs, continuous integration and deployment, minimizing waste and bureaucracy, and making decisions at the last responsible moment based on ongoing learning.
- Success requires open communication across all teams, with a focus on removing impediments, capturing feedback, and constantly improving through retrospectives.
The document contains questions about how teams are organized, whether they use a backlog or requirements document, how often they deliver value through sprints, who is assigned roles like Scrum Master and Product Owner, who is invited to sprint reviews, and the length and attendees of daily standups. It emphasizes the importance of continuous delivery, having people in agile roles, inviting everyone to reviews, and using a backlog to get more feedback and keep customers happy. It also discusses how work should flow through determining goals, creating ideas, prioritizing in a backlog, inviting all teams to plan, and implementing solid agile practices.
Павел рассказал о методологии Spotify Squad Health Check Model и как он использует ее в EPAM.
✔Сначала мы решили понять какие проблемы нас окружают и анализировать их.
✔Вам, как проектному менеджеру нужно оправдать доверие сотрудников, поэтому не обязательно проводить интервью с сотрудниками, можно просто за чаем или в курилке спросить их мнение.
✔Мы получили полную картину о том, что происходит на проекте, тренды, многие негативные тренды мы убрали и ключевые моменты улучшили.
Павло Камишов “Health check model: refined edition” Lviv Project Management DayLviv Startup Club
This document summarizes Pavel Kamyshov's approach to conducting health checks for teams working on projects. Some key points:
- The model is refined from Spotify's squad health check model and focuses on collecting feedback from individuals rather than just the team level.
- Feedback is collected anonymously on topics selected jointly by the team and coach. Checks are done once every 1-2 months through individual conversations.
- Characteristics like code quality, development process, team atmosphere, and overall satisfaction are evaluated. Trends over time can be identified from the collected data.
- Previous health checks helped improve areas like codebase health, suitable processes, and overall project satisfaction. Initiative groups were formed to address issues
Organisations must celebrate failure to achieve success Aidan Casey
This document discusses how organizations can achieve success by embracing failure. It recommends establishing a growth mindset culture where failure is viewed as an opportunity to learn and improve. Key aspects include shifting from only focusing on delivering features to prioritizing experimentation, establishing trust so teams feel safe to fail, and regularly reviewing failures to learn from mistakes. Metrics like the ICE score and AARRR can help evaluate experiments and determine their potential impact. Overall, the document argues that failure is inevitable and should be seen as a starting point for growth rather than something to avoid.
Beyond Value Streams: Experimental Evolution in ActionClaudio Perrone
These are the slides from my keynote for Lean Agile Scotland 2013. In this session, I shared stories, workflows and practical thinking tools that illustrate how the act of deliberately capturing and evolving "learning streams" (as opposed to - or rather in addition to - the more conventional value streams) can lead to surprising consequences.
The document discusses the Context Driven School of Testing. It outlines the seven basic principles of the Context Driven School, which focus on the importance of context, the unpredictability of projects, solving problems rather than following practices, testing as an intellectual process, and cooperation throughout projects. It also briefly describes five schools of testing - Analytical, Factory, Quality Assurance, Context Driven, and Agile - and notes that the Context Driven community values challenges and debate. The document emphasizes finding community and understanding different perspectives to improve testing practices.
Ho Chi Minh City Software Testing Conference January 2015
Software Testing in the Agile World
Website: www.hcmc-stc.org
Author: Lee Copeland
The IEEE 829 Test Documentation standard is thirty years old this year. Boris Beizer’s first book on software testing also turned thirty. Testing Computer Software, the best selling book on software testing, is twenty-five. During the last three decades, hardware platforms have evolved from mainframes to minis to desktops to laptops to tablets to smartphones. Development paradigms have shifted from waterfall to agile. Consumers expect more functionality, demand higher quality, and are less loyal to brands. The world has changed dramatically and testing must change to match it. Testing processes that helped us succeed in the past may prevent our success in the future. Lee Copeland shares his insights into the future of testing, sharing his Do’s and Don’ts in the areas of technology, organization, test processes, test plans, and automation. Join Lee for a thought provoking look at creating a better testing future.
The Leader's Guide Workshop - Pivotal Labs TokyoJeana Alayaay
These are the slides that were used for the 3rd Leader's Guide Workshop that was help at Pivotal Japan on Friday, 6/17/16. The content was developed by Janice Fraser, the Director of People for Pivotal. It is based on The Leader's Guide by Eric Ries and is officially endorsed by him.
Lean startups fuse customer development, lean production, and continuous delivery. They follow four steps: customer discovery to identify problems, customer validation to test solutions, customer creation to begin sales, and company building. The methodology emphasizes eliminating waste and continuous learning through building minimum viable products and validating assumptions with customers via a "pivot" as needed. Key techniques include agile development, continuous integration and deployment to learn quickly through fast iterations.
My take on Eric Ries' book The Lean Startup, as presented to my colleagues at XING Barcelona.
DISCLAIMER: This is a sketched presentation. Can be disappointing.
This document describes Sprintz.Work, a 5-week program that provides trained remote teams and coaching to help companies innovate. It addresses challenges like getting innovation teams to focus remotely. The program is based on design sprints but lasts 5 weeks instead of 5 days, allowing more time to develop ideas. Managers work with a certified team for 10-15 hours per week and receive training, tools and lifetime access to innovation resources. The goal is to achieve more innovation results in 5 weeks than traditional short sprints through this structured remote process.
This presentation was presented in Unicom World Business Summit Conference 2015. It talks about using Lean Startup method for situation where both the problem and solution is not clear. Team can using Lean Ux and Lean analytics techniques. We presented our experience about using Lean Startup and Lean Ux techniques in one of our product development. In this development we iteratively developed the product using the Lean startup method. We covered the experience of how Lean Ux methods like ethnographic studies, Wireframing, Landing pages can be used effectively to get feedback
This document discusses technical debt and strategies for managing and selling technical debt rearchitecture projects. It defines technical debt as work that is postponed to a later time, such as lack of testing or architecture planning. While some debt can be useful for time to market goals, ignoring debt accumulation can slow a project over time. The document provides examples of technical debt elements to examine in a codebase and recommends conducting due diligence to understand existing debt. It also presents stories and metaphors to help explain the risks of debt to business stakeholders and the value of rearchitecture projects when needed.
This document discusses how to effectively adopt an agile mindset and practices. It begins by looking at the original goals of going agile but finds that in reality, many agile adoptions face problems and challenges. It discusses the "broken windows theory" - how small issues can lead to bigger ones if not addressed. However, instead of focusing on problems, it recommends taking an Appreciative Inquiry approach through retrospective meetings. This focuses the team on successes and strengths, envisioning future improvements through positive dialogue to act as a continuous engine for agile transformation.
1) The document discusses the Minimum Viable Product (MVP) process which helps entrepreneurs test new products and gather feedback to make improvements.
2) An MVP is not a finished product but a process to validate critical assumptions as efficiently as possible to improve chances of success.
3) Common MVP methods mentioned include fake door product videos, landing pages, piecemeal launches, and the wizard of OZ technique.
This document discusses balanced teams and their importance for delivering value to users. It outlines the roles of designers, developers, and product managers in a balanced team. Each role has obligations to understand customers, envision solutions, make decisions, and facilitate balance within the team. Balanced teams value multi-disciplinary collaboration and iterative delivery focused on customer value. The document advocates for empathy, trust, mutual respect between roles, and acting as one product team to achieve business value.
This document discusses building a culture of self-governance at a company. It outlines four types of organizational culture and advocates for the fourth type, self-governance, where employee values guide their own behavior. The document then discusses establishing shared values, principles, and practices at the company to achieve this culture. It provides examples of values and principles for the product and engineering team, such as "Clear the Path" and building products customers love. Finally, it encourages being prescriptive, applying constant gentle pressure, being patient, and appreciating those who provide feedback to help build this culture.
Anko Tijman - Building a Quality Driven Team - EuroSTAR 2010TEST Huddle
EuroSTAR Software Testing Conference 2010 presentation on Building a Quality Driven Team by Anko Tijman. See more at: http://conference.eurostarsoftwaretesting.com/past-presentations/
Good agile / Bad agile: Proving the value of Agile to a skeptical organizationAlan Albert
Is Agile worth it?
What value can being Agile bring to your organization?
Done right, Agile software development methodologies can help your organization deliver greater value to customers and other stakeholders more efficiently and with reduced risk.
Done wrong, Agile methodologies become an endlessly iterating feature factory, facing an ever-growing backlog.
In this interactive session, attendees discussed:
- How to identify what’s most valuable to build next
- How to ensure that the features you build are not just functional, but used and valued
- How to measure and effectively communicate the value that you create
Led by Alan Albert of MarketFit, this session at Agile Vancouver explored theory, examples, and exercises showing how to unlock the power of discovering, creating, and communicating value.
Measuring team performance at spotify slideshareDanielle Jabin
How do we actually know if our teams are doing well? Is gut instinct enough? Furthermore, in a rapidly growing organization such as Spotify, how can we ensure some sort of consistency in our baseline level of Agile knowledge across the technology, product, and design organization?
In this presentation, I’ve shared techniques we have developed and use at Spotify to benchmark health and performance for our teams and some tactics we use to bring them closer to—and beyond!—being the best teams they can be.
Huib Schoots Testing in modern times - a story about Quality and Value - Test...FiSTB
Huib introduces himself as an experienced IT professional with over 25 years of experience in roles such as developer, tester, consultant, manager, trainer, and coach. He currently works as a managing consultant and senior consultant focused on quality and testing.
The document discusses testing and quality, noting that quality is defined by the value provided to stakeholders rather than conformance to requirements. Testing is described as evaluating a product through experience and exploration to build understanding.
It emphasizes the importance of learning for both individuals and organizations. High-performing teams and organizations are able to learn continuously and adapt their processes accordingly. Continuous learning is key for developing complex software products and keeping up with changing needs.
I’m an Agile Test Manager:Do I really exist?elliando dias
The document discusses the role of an Agile Test Manager and whether it truly exists. It questions traditional assumptions about test management and proposes that the Test Manager focus on delivering business value to the Agile project by understanding when to take different roles, amplifying quality information to stakeholders, and not trying to own quality but enabling the team to take responsibility for it. The document concludes by thanking the audience and providing contact information for further discussion.
This document provides an overview of practical scrum. It discusses the three scrum roles of product owner, scrum master, and team. It also describes the four scrum ceremonies and three artifacts. Key principles of scrum include self-organizing teams, empirical process, and delivering working software frequently. The document contrasts command-and-control with self-management and explains how the manager's role changes in an agile environment.
Building Blocks of a strong Experimentation Program (1).pdfVWO
In this upcoming webinar, Nils will discuss the importance of focusing on the process of experimentation rather than simply pursuing the “next best idea”. While generating new ideas is certainly an important aspect of innovation, it is equally important to have a structured and disciplined approach to experimentation to maximise those ideas’ impact.
The process of experimentation involves identifying a specific hypothesis or problem, designing experiments to test that hypothesis or solve that problem, gathering and analyzing data from those experiments, and then using that data to iterate and improve the initial idea. This approach helps to ensure that new ideas are grounded in empirical evidence and are more likely to have a meaningful impact on the business.
During the webinar, Nils will discuss best practices for designing and conducting experiments, as well as strategies for embedding experimentation into the culture of the organization. We will also explore case studies of companies that have successfully implemented a process-focused approach to experimentation and its impact on their business.
This document outlines the culture of a company focused on helping small businesses succeed. It begins by defining culture and explaining why a clearly defined culture is important for success. The company's mission is to make getting customers as simple as running water. It values customer obsession, striving for greatness, radical transparency, ownership, speed, simplicity, full commitment, efficiency, questioning assumptions, and outcomes over excuses. It aims to hire "A players" who actively improve the company and allow context-based decision making with accountability. The goal is to promote from within based on alignment with values over just skills.
This presentation goes into details about impediments, how to identify them, how to create a strategy for, escalate, and ultimately - if not removing them entirely - moving the needle to improve the situation. Apologies for the outdated styling - it's on my backlog to improve it!
Lean on Agile: Getting the Best of Both WorldsSam McAfee
It's 2017, and we're all bought in to the notion of using Agile and Lean Startup principles. But how do we mix them together? For many product and engineering teams, balancing the technical excellence of Agile with the experiment focus of Lean Startup has proven quite challenging. This session will provide the basic principles, a high-level process, and several real world examples (from both enterprise and startups) of product teams successfully balancing these two great philosophies.
Agile Gurugram 2016 | Conference | What agile really means ? | KE SiewAgileNetwork
1. The document discusses the differences between traditional and agile approaches to product development. Traditional approaches use defined sequential processes while agile approaches are empirical, incremental, and iterative.
2. It outlines 12 principles of agile development including continuous delivery of working software, welcoming changing requirements, self-organizing cross-functional teams, trusting teams to get the job done, and continuously improving.
3. The document describes how one company transitioned from a traditional to an agile approach, which improved productivity, quality, and morale through new processes, problem solving techniques, tools, leadership, and learning.
The document discusses whether Agile practices are effective or not. It questions if the reader's team is performing well with Agile and what practices may have failed. It acknowledges that while Agile can be problematic, the principles may not be the root cause and introspection is needed. The document advocates focusing on people, processes, and tools holistically. It suggests educating oneself on successful teams and reflecting on one's own practices rather than blindly following Agile. Overall, it argues that Agile success depends more on individuals' mindsets and adaptiveness than any defined processes.
This document provides tools and strategies for developing business agility. It discusses establishing a clear vision and priorities, aligning stakeholders, and using empirical data to understand customer needs. The document emphasizes creating a learning culture, continuous innovation, and scaling down processes. Critical success factors include sustainable culture change, collaboration, and emphasizing people over processes. Tools presented include lean canvases, customer journey maps, and design thinking techniques to help organizations focus on customer value and adapt quickly to changing conditions.
Maurizio Mancini is an agile coach with over 10 years of experience helping teams deliver quality software using agile practices. He advocates establishing a test-first mindset to build quality in from the start by breaking down walls between development and QA, setting common quality goals, and using techniques like ATDD/BDD. Scaling quality requires continuous integration and testing, integrating and testing often at both the team and application levels. It is more cost effective to build quality in from the beginning than to test it in later.
This document discusses how to grow a culture of quality in software development. It begins by defining quality as meeting customer needs and defining a culture of quality as having quality as the highest priority across teams. It then addresses common misconceptions about testing and quality assurance. The document advocates defining a quality narrative for how quality is perceived and measured in an organization. It provides an example of transforming a quality narrative from seeing quality assurance as a regulatory burden to advocates for quality. Key strategies discussed for growing a quality culture include empowering teams, engaging them in quality discussions, finding allies, speaking the language of the business, and continuously improving processes. The overall message is that developing a quality culture is a ongoing journey.
Measuring Team Happiness – A Real-Life Journey of Fostering an Engaging Worki...Agile Montréal
There is no team more productive than a healthy, engaged team. Unfortunately, some organizations still use bottom line metrics to drive performance, which typically hurt more than they help. In this talk we’ll focus on an alternative approach to fostering a great working environment, looking at how we can leverage Spotify’s “Squad Health Check Model” and Patrick Hanlon’s “Primal Branding” to build strong foundations and feedback mechanisms that set the stage for high-performance Agile Teams.
Daniel Tardif
This document discusses how agile principles can help teams that are facing challenges or are in "fire fighting" mode. It recommends focusing on eliminating waste, building quality in, reducing cycle times, continuously learning and improving, making data-driven decisions, engaging everyone on the team, and optimizing the entire system. When coming in to assist a struggling team, the author recommends directly observing the team to understand their needs and culture, using visual tools, gaining management support, establishing a consistent cadence for iterations and reflection, managing interrupts, and celebrating results. The overall message is that agile principles of inspecting and adapting the process as needed can help rescue teams facing difficulties if implemented correctly.
Similar to Building A Quality Driven Team - InnoveerJijMee 31 jan 2011 (20)
Devops is about 3 things: 1) Automation of IT 2) Cross disciplinary teams and 3) Learning from production. These 3 elements support organizations directly in becoming digital, client-driven and data-oriented enterprises.
Workshop with an introduction to Scaling Agile, the different axes when scaling, risks on scaling Agile and a compact solution to a transparant, flexible and easy-to-use format for Program, Portfolio and Project management within a Scalig Agile context. We called this the Submay map:)
This session is an overview on what DevOps is (to me) and how it impacts traditional organizations the most. DevOps is way more than just continuous delivery! From an Agile (synergetic) mindset, DevOps takes a step beyond and focusses on automation, collaboration and learning. Apart from that I also look forward to what oppurtunities lie ahead when implementing DevOps.
On March 2nd I presented this DevOps Unraveled session for abt 40 IT-managers at business university Nyenrode. This was part of the Masterclass Agile management
(Dutch website http://www.executiveeducation.nl/open-programmas/programmadetails/masterclass-agile-management/sectie/introductie.html ).
Op het BPUG seminar van 3 juni werd in een interactieve sessie aan de hand van sketches het dilemma tussen Agile en Controle gedemonstreerd door Anko Tijman, Marcel Faber en Tilman Jakobs (allen Ordina).
Presentatie zoals ik die gegeven heb op het Agile People event op 26 april, bij Ordina. Het evenement werd georganiseerd door het Agile Consortium en AgileOverheid.
Als je samenwerken als norm neemt, kom je tot verrassende ontdekkingen. Bijvoorbeeld in ICT-projecten waarin het faciliteren ervan (in het proces) nog amper gebeurt. Deze presentatie geeft daar een licht over.
3. 3 ACCEPTANCE TESTS You will have learned: What a quality driven, every-step-is-the-right-step approach looks like Ways to help your team getting ‘test-infected’ To achieve that, it is necessary to have an out-of-the-testing-box, people centric view on doing projects
10. How to build your teamWhat customers expect: Full scope delivered on time Within budget Without ‘surprises’ in planning or quality As a team: Every step should be the right step With a production-level quality mindset As a sustainable service
36. Achieving change“Communication is: to misunderstand each other as little as possible” “It’s not about what you say, it’s about what they understand.” “Seek first to understand, then to be understood” (Stephen Covey) “Be nice to nerds. Chances are you’ll end up working for one. “ (Bill Gates) "None of us is as smart as all of us" (Gerald Weinberg) "No matter what they tell you, it’s always a people issue" (Gerald Weinberg)
64. Achieving changeYou have learned: What a quality driven, every-step-is-the-right-step approach looks like Ways to help your team getting ‘test-infected’ To achieve that, it is necessary to have an out-of-the-testing-box, people centric view on doing projects Agiletesternl Mail: anko.tijman@ordina.nl Ordina Ringwade 1 3439 LM Nieuwegein Tel. +31 30 663 7000 www.ordina.nl/agiletesten Please fill in the evaluation form!