In this presentation, I explore many common Agile transformation issues and what you can do about them. I cover challenges with customers, technical process, organizational hurdles, prioritization, agile requirements, etc. Some of the topics include:
o No single Product Owner in Scrum.
o No on-site customer for Extreme Programming.
o The user stories are too big.
o The user stories are too vague.
o Bug count is going up or not going down.
o Customer/Stakeholders/PO never choose technical stories for next iteration/sprint.
o Customer/Stakeholders/PO won't take the time to prioritize their backlog.
o Even though story points match prior velocity, there seems to be too much work.
o Stand-up or Scrum meetings take forever.
o Stand-up or Scrum meetings are short, but no one talks about real problems.
o Management doesn't value removing impediments quickly.
o Velocity seems to be slowing down.
o So many hoops to jump through that it takes forever to get anything done.
• What is Behavior Driven Development?
• What is its value?
• How does BDD differ from Test-Driven Development?
• What is the role of the customer/product owner in BDD?
• What about teams that have traditional manual testers?
• What about teams that have developers but not testers?
• What is a good BDD test?
• What should be tested manually?
Growing Manual Testers into AutomatorsCamille Bell
Manual testing can't keep up with modern software development. Tests generated by Capture/Playback tools don't work either as these tests become brittle and break. Instead working with business and development testers need to create acceptance criteria that drives product development. To become automators testers need new tools. Testers need new ways of working. Testers need new skills. And the organization needs to support your testers growth. Here is how I and others have made it work.
Testing for Agility: Bringing Testing into EverythingCamille Bell
A testing focus can drive agility in every aspect of software development. Topics include: the cost of waiting to test, how waterfall can be transformed into agility with feedback, how testing can drive requirements discovery, testing your vision, testing during development, testing as part of integration and deployment, testing for customer acceptance, agile ratios of different types of tests, agile testing for bug fixes and maintenance, management concerns for agile testing and code coverage.
Promoting Agility with Running Tested Features - Lightening TalkCamille Bell
This short Lighting Talk introduces the Running Tested Feature (RTF) metric, a wonderfully useful metric that's easy to collect and promotes agility. It provides examples of RTF when development has steady progress and when SW breaks. This talk also discusses what happens when people try to game the RTF metric.
The Running Tested Features metric provides developers, managers and customers alike with a clear, unambiguous gauge of real software development progress. Usable on any kind of development project, RTF’s focus on outcome instead of process makes RTF especially fit for Agile projects. Because RTF can be used with both Agile and Waterfall projects, RTF makes an excellent progress metric for teams transitioning to Agile.
Even with the best agile development practices, bugs sometimes slip in. You don't want to manually wade through hundreds of commits and thousands or tens of thousands of lines of code to find your bug. See how find your bug fast using Git, the best (and free) version control software tool. If you are still using CVS, Subversion, or costly commercial version control, you are missing out.
Kanban is an Lean practice that focuses on completing work. Used alone Kanban provides an evolutionary approach to agile development and better fits many SW development teams (like maintenance or sysadmin) that don't have an iterative cadence. Used in combination with agile processes like Scrum or Extreme Programming, Kanban practices like WIP limits and Service Level swim lanes solve issues real teams and companies encounter every day. Project managers should pay special attention to Kanban Lead Time metric.
How to succeed in software development. Following agile methodology principles helps to achieve much better results. Know more about eXtreme Programming, one of the famous agile software development methodology.
• What is Behavior Driven Development?
• What is its value?
• How does BDD differ from Test-Driven Development?
• What is the role of the customer/product owner in BDD?
• What about teams that have traditional manual testers?
• What about teams that have developers but not testers?
• What is a good BDD test?
• What should be tested manually?
Growing Manual Testers into AutomatorsCamille Bell
Manual testing can't keep up with modern software development. Tests generated by Capture/Playback tools don't work either as these tests become brittle and break. Instead working with business and development testers need to create acceptance criteria that drives product development. To become automators testers need new tools. Testers need new ways of working. Testers need new skills. And the organization needs to support your testers growth. Here is how I and others have made it work.
Testing for Agility: Bringing Testing into EverythingCamille Bell
A testing focus can drive agility in every aspect of software development. Topics include: the cost of waiting to test, how waterfall can be transformed into agility with feedback, how testing can drive requirements discovery, testing your vision, testing during development, testing as part of integration and deployment, testing for customer acceptance, agile ratios of different types of tests, agile testing for bug fixes and maintenance, management concerns for agile testing and code coverage.
Promoting Agility with Running Tested Features - Lightening TalkCamille Bell
This short Lighting Talk introduces the Running Tested Feature (RTF) metric, a wonderfully useful metric that's easy to collect and promotes agility. It provides examples of RTF when development has steady progress and when SW breaks. This talk also discusses what happens when people try to game the RTF metric.
The Running Tested Features metric provides developers, managers and customers alike with a clear, unambiguous gauge of real software development progress. Usable on any kind of development project, RTF’s focus on outcome instead of process makes RTF especially fit for Agile projects. Because RTF can be used with both Agile and Waterfall projects, RTF makes an excellent progress metric for teams transitioning to Agile.
Even with the best agile development practices, bugs sometimes slip in. You don't want to manually wade through hundreds of commits and thousands or tens of thousands of lines of code to find your bug. See how find your bug fast using Git, the best (and free) version control software tool. If you are still using CVS, Subversion, or costly commercial version control, you are missing out.
Kanban is an Lean practice that focuses on completing work. Used alone Kanban provides an evolutionary approach to agile development and better fits many SW development teams (like maintenance or sysadmin) that don't have an iterative cadence. Used in combination with agile processes like Scrum or Extreme Programming, Kanban practices like WIP limits and Service Level swim lanes solve issues real teams and companies encounter every day. Project managers should pay special attention to Kanban Lead Time metric.
How to succeed in software development. Following agile methodology principles helps to achieve much better results. Know more about eXtreme Programming, one of the famous agile software development methodology.
Flexing your Agile Muscle - Agile Technical Concepts ExplainedSandy Mamoli
Continuous integration, acceptance test driven development (ATDD), specification by example and continuous deployment: The list of have-to-know concepts is growing and you have this nagging feeling that you should really get started so you won’t miss out on the fun.
Learn what basic Agile technical concepts mean, understand how you can benefit from using them and get ideas for how you might get started. Also, you will be able to explain to your boss or project manager why Agile technical concepts are well worth the investment.
This session will keep things on a strictly conceptual level - so whether you’re a developer or an interested manager please come along.
Test and Behaviour Driven Development (TDD/BDD)Lars Thorup
In this introduction to Test Driven Development (TDD) or Behaviour Driven Development (BDD) we give a high level description of what it is and why it is useful for developers. Then we go into some details on stubs and mocks, test data, UI testing, SQL testing, JavaScript testing, web services testing and how to start doing TDD/BDD on an existing code base.
As companies mature their software development practices, automated acceptance-level testing is becoming more commonplace. In particular, Cucumber and its Gherkin-based equivalents are enjoying widespread use. Through observing and facilitating the adoption and implementation of Cucumber test suites, I have found ways in which the technology has helped teams greatly, but I have also found ways in which it hindered them. I realized that Cucumber and its kin are appropriate tools in fewer situations than the ones in which they are currently employed. In other words, many teams that use such frameworks need to reevaluate whether they are right for the job, and perhaps replace them. I invite all involved in automated acceptance testing to attend as I try to build a compelling case for this notion.
Specification by Example - Agile India 2015Ankur Sambhar
We all know the importance of validating a feature before committing to getting it built. Validating assumptions help in avoiding the most frustrating and common problem – building something that nobody wants. However, validation is easier said than done. Building the right feature before we think of building the feature right is the key.
Being Agile, we always try to leverage the quick feedback loop and adapt based on the end-user feedback. That’s good but it should not be used to validate the assumptions and that too after implementing a feature based on that assumption. It’s very expensive smile
A more powerful and productive technique is to leverage Specification-by-example in defining and discovering requirements collaboratively with end-user, even before start working on the feature.
This talk will focus on highlighting key aspects of effectively adopting SBE technique based on my own experience leveraging it successfully over and over again. It not only helps in grooming the feature requirement to tell a clear , simple and compelling story but it also helps in removing what is not needed.
Anand Bagmar - Behavior Driven Testing (BDT) in AgileAnand Bagmar
I delivered this talk in SiliconIndia's SoftTec 2012 on 14th July 2012. I introduce Behavior Driven Testing (BDT) with a couple of examples, the different ways of writing the tests in Imperative and Declarative style, the value proposition of BDT, and how BDT can help you build a very good safety net using Test Automation suite.
This presentation is a part of the COP2271C college level course taught at the Florida Polytechnic University located in Lakeland Florida. The purpose of this course is to introduce Freshmen students to both the process of software development and to the Python language.
The course is one semester in length and meets for 2 hours twice a week. The Instructor is Dr. Jim Anderson.
A video of Dr. Anderson using these slides is available on YouTube at: https://www.youtube.com/watch?v=c2CTDm19Lpg
Slides with notes for the talk "Production code without tests" based on the Michael Feathers "Working Effectively with Legacy Code" book.
http://sstude.com/blog/2013/02/05/my-talk-production-code-without-tests
How Netflix tests in production to augment more traditional testing methods. This talk covers the Simian Army (Chaos Monkey & friends, code coverage in production, and canary testing.
Refactoring page objects The Screenplay Pattern RiverGlide
As seen at BDD Exchange 2016 and Selenium Conf 2016
The Screenplay Pattern, first created by Antony Marcano, is an alternative model to PageObjects. Today, it is growing in popularity with increasing tool support in popular testing frameworks.
PageObjects provide an easy-to-follow, simple structure that avoids early maintenance issues. They were introduced to help test-developers avoid mistaking flaky tests for problems with Selenium. But, PageObjects break some key OO design rules, making maintenance more difficult over time. They are a useful first step, but why do we stop there?
In this session you’ll learn about the SOLID design principles that PageObjects disregard. You’ll see why this leads to problems. You’ll see how and why PageObjects benefit from refactoring to SOLID design principles. Finally, you’ll meet the Screenplay Pattern – an alternative model based on SOLID principles that saves you the trouble.
Introduction to the fundamentals of eXtreme programming (XP). XP is a software development approach which stresses on improving software quality and respond according to changing business requirements.
Getting your mobile test automation process in place - using Cucumber and Cal...Niels Frydenholm
Taking your mobile development process cycle, and the quality of the apps, from good to great.
See how focusing on automated tests can improve app quality, time to market and much more, and learn some best practices to avoid too much trouble getting started
Presented at Xamarin Evolve 2014
Flexing your Agile Muscle - Agile Technical Concepts ExplainedSandy Mamoli
Continuous integration, acceptance test driven development (ATDD), specification by example and continuous deployment: The list of have-to-know concepts is growing and you have this nagging feeling that you should really get started so you won’t miss out on the fun.
Learn what basic Agile technical concepts mean, understand how you can benefit from using them and get ideas for how you might get started. Also, you will be able to explain to your boss or project manager why Agile technical concepts are well worth the investment.
This session will keep things on a strictly conceptual level - so whether you’re a developer or an interested manager please come along.
Test and Behaviour Driven Development (TDD/BDD)Lars Thorup
In this introduction to Test Driven Development (TDD) or Behaviour Driven Development (BDD) we give a high level description of what it is and why it is useful for developers. Then we go into some details on stubs and mocks, test data, UI testing, SQL testing, JavaScript testing, web services testing and how to start doing TDD/BDD on an existing code base.
As companies mature their software development practices, automated acceptance-level testing is becoming more commonplace. In particular, Cucumber and its Gherkin-based equivalents are enjoying widespread use. Through observing and facilitating the adoption and implementation of Cucumber test suites, I have found ways in which the technology has helped teams greatly, but I have also found ways in which it hindered them. I realized that Cucumber and its kin are appropriate tools in fewer situations than the ones in which they are currently employed. In other words, many teams that use such frameworks need to reevaluate whether they are right for the job, and perhaps replace them. I invite all involved in automated acceptance testing to attend as I try to build a compelling case for this notion.
Specification by Example - Agile India 2015Ankur Sambhar
We all know the importance of validating a feature before committing to getting it built. Validating assumptions help in avoiding the most frustrating and common problem – building something that nobody wants. However, validation is easier said than done. Building the right feature before we think of building the feature right is the key.
Being Agile, we always try to leverage the quick feedback loop and adapt based on the end-user feedback. That’s good but it should not be used to validate the assumptions and that too after implementing a feature based on that assumption. It’s very expensive smile
A more powerful and productive technique is to leverage Specification-by-example in defining and discovering requirements collaboratively with end-user, even before start working on the feature.
This talk will focus on highlighting key aspects of effectively adopting SBE technique based on my own experience leveraging it successfully over and over again. It not only helps in grooming the feature requirement to tell a clear , simple and compelling story but it also helps in removing what is not needed.
Anand Bagmar - Behavior Driven Testing (BDT) in AgileAnand Bagmar
I delivered this talk in SiliconIndia's SoftTec 2012 on 14th July 2012. I introduce Behavior Driven Testing (BDT) with a couple of examples, the different ways of writing the tests in Imperative and Declarative style, the value proposition of BDT, and how BDT can help you build a very good safety net using Test Automation suite.
This presentation is a part of the COP2271C college level course taught at the Florida Polytechnic University located in Lakeland Florida. The purpose of this course is to introduce Freshmen students to both the process of software development and to the Python language.
The course is one semester in length and meets for 2 hours twice a week. The Instructor is Dr. Jim Anderson.
A video of Dr. Anderson using these slides is available on YouTube at: https://www.youtube.com/watch?v=c2CTDm19Lpg
Slides with notes for the talk "Production code without tests" based on the Michael Feathers "Working Effectively with Legacy Code" book.
http://sstude.com/blog/2013/02/05/my-talk-production-code-without-tests
How Netflix tests in production to augment more traditional testing methods. This talk covers the Simian Army (Chaos Monkey & friends, code coverage in production, and canary testing.
Refactoring page objects The Screenplay Pattern RiverGlide
As seen at BDD Exchange 2016 and Selenium Conf 2016
The Screenplay Pattern, first created by Antony Marcano, is an alternative model to PageObjects. Today, it is growing in popularity with increasing tool support in popular testing frameworks.
PageObjects provide an easy-to-follow, simple structure that avoids early maintenance issues. They were introduced to help test-developers avoid mistaking flaky tests for problems with Selenium. But, PageObjects break some key OO design rules, making maintenance more difficult over time. They are a useful first step, but why do we stop there?
In this session you’ll learn about the SOLID design principles that PageObjects disregard. You’ll see why this leads to problems. You’ll see how and why PageObjects benefit from refactoring to SOLID design principles. Finally, you’ll meet the Screenplay Pattern – an alternative model based on SOLID principles that saves you the trouble.
Introduction to the fundamentals of eXtreme programming (XP). XP is a software development approach which stresses on improving software quality and respond according to changing business requirements.
Getting your mobile test automation process in place - using Cucumber and Cal...Niels Frydenholm
Taking your mobile development process cycle, and the quality of the apps, from good to great.
See how focusing on automated tests can improve app quality, time to market and much more, and learn some best practices to avoid too much trouble getting started
Presented at Xamarin Evolve 2014
Drivers depend on location, time and context; Policy responses need to use the right mix of carrots, sticks & sermons; Ultimately, enlightened self-interest (caring) will have to be the primary reason to keep/promote forests & trees; In the short run a combination of sparing & sharing is needed to achieve sustainable development goals
Choosing an enterprise system is never easy. Choosing a Learning Management System only adds complication, frustration, and headache! In this presentation, we discuss some do's and don'ts, building usable requirements, and some of the traps to avoid along the way.
This presentation was delivered at Learning DevCamp on June 12, 2014
Presentation on Lean Startup methodology for StartupQ8 meetup November 7th 2012. For more information on StartupQ8, visit http://startupq8.com
About the author: Mijbel F. AlQattan is a founding partner at Cubical Services, where he provides advisory and incubation services for startups (both technology and traditional). His areas of expertise include business model development, business plan analysis and financial analysis for startups. For more information, visit http://www.cubicalservices.com
IMVU: “But Does It Scale?” from Startup Lessons Learned ConferenceBrett Durrett
IMVU: “But Does It Scale?” from Eric Ries' Startup Lessons Learned Conference, April 23, 2010 in San Francisco. The video presentation is available at http://bit.ly/bBpUcm
We present to you a deck on how we increased conversions on our SaaS/Cloud application website by making small design changes. We will also share tips on how alter your product website to drive up conversions.
Slides from the "Much ado about Agile", Agile Vancouver Conference 2015. This talk is around examples of MVP on small startups and Enterprise level. What's the ultimate MVP?
Agile Test Management Using Jira and ZephyrXBOSoft
Do you have traceability where you can efficiently determine the cause of defects if there was an unclear requirement? Are you sure your test cases cover your requirements? Can you easily execute targeted regression when you’ve updated your software’s functionality? Now with software development teams mostly working from home or in dispersed geographies, supporting effective collaboration between remote workers is critical. In this XBOSoft quarterly webinar, our CEO, Philip Lew, teams up with BDQ’s CEO Chris Bland, to discuss the problems with working remotely, integrating the phases of testing in development in an Agile, and how this can be done using Zephyr, one of the predominant plugins in the Atlassian marketplace for test management. In this webinar, you will learn how to:
--Link tests with user stories and group tests within test cycles.
--Tie your results (defects) all the way back to user stories for effective defect root cause analysis.
--Classify defects to analyze and prioritize your test efforts.
--Use the traceability matrix with Zephr for deep visibility into your Agile process.
Got the pleasure of being invited to the day one / two of the #StartupWeekend were a total whirlwind.
Here, I was talking about the Business Model Canvas and why it matters!
Picture this – 40 groundbreaking ideas pitched in just 60 seconds each to a crazy room of about 80 people – we had everyone from seasoned founders to talented graduates from top Kenyan tech schools, and even Kenyans who've returned from abroad to test out their entrepreneurial skill sets, students, doctors, lawyers, etc etc.
The ideas they came up with? Among the best in my many years of participating in Startup Weekends. Folks were thinking big, tackling everything from blood donation to agritech, and mobility. There was even a proposal that felt straight out of an Elon Musk black mirror brainstorm, all about storing memories for the future. Seriously impressive stuff!!
Everyone in the room voted for their favorite ideas. From there, they grouped up into teams of 3 to 5, forming bonds with their potential new cofounders. These freshly minted teams have just 2 days to work up their prototypes. To their benefit, we have had some industry experts on hand to offer their wisdom and support.
I totally believe in this edition, we shall see some of the founders making waves in the startup world in a few years. Keep an eye out for more updates, as we're gearing up for the final day where the top 13 teams will go head to head for the winner's title of the Techstars Startup Weekend 2023. The energy is high, chaotic, fast, and we can't wait to see what happens next…
#startup #founders #future #energy Power Learn Project Moringa School Startinev Techstars Techstars Startup Weekend #innovation #startup #storytelling #foundation #sme #business
IIT Academy: Agile. Learn how to articulate customer expectations and build precisely what was intended, with the minimum of traceability issues. Acceptance Criteria (in conjunction with good agile practices) is a way to create well documented, high-quality codebase tested using the same set of standards by developers, testers, analysts, designers as well as the Product Owner. Learn good Acceptance Criteria - the keys to customer success in agile delivery!
Products and Value: An Agile Perspective BY Matt Nudelmann (GUEST PRESENTER)Samuel Chin, PMP, CSM
You may have heard of Agile methodology before, especially in the context of web development ... but can we apply Agile principles to our study of process?
In this session, guest presenter Matt Nudelman explains how to understand some core elements of process, Product and Value, from an Agile point of view. He covers a range of topics including: the difference between a product and a project, Agile project management, the 80/20 rule, what an MVP is, and defining value using the Agile framework.
We also discussed how these principles apply to the process work we've been doing, and what we can take away for practical application.
----
Matt Nudelman, Scrum Master and Project Manager, began working in digital sometime before the last Dot Com boom, and has seen the rise of development methodologies coincide with his interest in efficient work practices. He has managed projects for Morgan Stanley, the New York Times, advertising agencies, and lots of companies you never heard of. Currently, Matt works with teams at Viacom to produce great software and to maximize their Agile effectiveness.
There are some appropriate ways to deploy and implement IBM DevOps tools including Team Concert DOORs NG, Quality Manager, and the various Rational IDE's. However, there are many wrong ways to do it wrong. This presentation, from InterConnect 2016, focuses on trends that we have seen over the past few years that simply, don't work, and how to avoid the pitfalls.
Lean Startup for Healthcare: Workshop at Healthbox Orthogonal
A workshop on how the Lean Startup approach to innovation applies in a healthcare setting, delivered by Pathfinder Software CEO Bernhard Kappe to the inaugural class at the Healthbox startup accelerator
Similar to Adapting Agility: Getting your Agile Transformation Unstuck (20)
What CS Class Didn't Teach About TestingCamille Bell
Computer Science classes don't teach testing. Testing is as critical to software engineering as writing code. Here I show what CS programs should have taught, but didn't.
Mob Programming delivers the very best from your entire team, technical and business alike. Learn about mob programming and how to bring mob programming to remote teams.
Becoming a Software Craftsman takes a lot of practice. Using Code Katas in Coding Dojos is an excellent way to get that practice in a low stress fun way. Discover how to do that.
To become really good at anything takes a lot of practice. Apprenticeships and formal mentoring, common in medieval times, are rare today. To create quality code we need solid practices like Test Driven Development and Pair Programming or Mobbing. In this software craftsmanship workshop attendees practiced those skills on in a code kata.
You're a Certified Scrum Master. Perhaps you are an Agile Manger, Agile Coach or Facilitator.
Maybe you are newly minted or maybe you've been doing it a while, but either way you've noticed that not everything seems to work according the way the training or certification class implied it should.
In this pressentation, Camille Bell explores what you weren't told in training, but need to know. Such as:
o What assumptions Scrum makes that may not apply to your company or organization
o Why some types of teams should not use Scrum and what they should use instead
o How soon Scrum of Scrum stops scaling and what to use when it doesn't scale
o Why some teams don't improve despite holding retrospectives
o How to recognize the hockey stick burn down and what to do about it
o What's a WIP limit and when it can be helpful
o When estimation most helpful, when it's a complete waste and what to do instead
o Why simple prioritization of a Product Backlog won't generate a Minimal Viable Product
o Why the As a.., I want.. So that.. user story isn't enough and what you need to add
o What are the critical missing practices your development team needs
Promoting Agility with Running Tested Features - PaperCamille Bell
The Running Tested Features (RTF) metric provides developers, managers and customers alike with a clear, unambiguous gauge of real software development progress. Usable on any kind of development project, RTF’s focus on outcome instead of process makes RTF especially fit for Agile projects. Because RTF can be used with both Agile and Waterfall projects, RTF makes an excellent progress metric for teams transitioning to Agile.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Sudheer Mechineni, Head of Application Frameworks, Standard Chartered Bank
Discover how Standard Chartered Bank harnessed the power of Neo4j to transform complex data access challenges into a dynamic, scalable graph database solution. This keynote will cover their journey from initial adoption to deploying a fully automated, enterprise-grade causal cluster, highlighting key strategies for modelling organisational changes and ensuring robust disaster recovery. Learn how these innovations have not only enhanced Standard Chartered Bank’s data infrastructure but also positioned them as pioneers in the banking sector’s adoption of graph technology.
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
GraphSummit Singapore | The Future of Agility: Supercharging Digital Transfor...Neo4j
Leonard Jayamohan, Partner & Generative AI Lead, Deloitte
This keynote will reveal how Deloitte leverages Neo4j’s graph power for groundbreaking digital twin solutions, achieving a staggering 100x performance boost. Discover the essential role knowledge graphs play in successful generative AI implementations. Plus, get an exclusive look at an innovative Neo4j + Generative AI solution Deloitte is developing in-house.
GraphSummit Singapore | The Art of the Possible with Graph - Q2 2024Neo4j
Neha Bajwa, Vice President of Product Marketing, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
GridMate - End to end testing is a critical piece to ensure quality and avoid...ThomasParaiso2
End to end testing is a critical piece to ensure quality and avoid regressions. In this session, we share our journey building an E2E testing pipeline for GridMate components (LWC and Aura) using Cypress, JSForce, FakerJS…
Unlocking Productivity: Leveraging the Potential of Copilot in Microsoft 365, a presentation by Christoforos Vlachos, Senior Solutions Manager – Modern Workplace, Uni Systems
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdfPeter Spielvogel
Building better applications for business users with SAP Fiori.
• What is SAP Fiori and why it matters to you
• How a better user experience drives measurable business benefits
• How to get started with SAP Fiori today
• How SAP Fiori elements accelerates application development
• How SAP Build Code includes SAP Fiori tools and other generative artificial intelligence capabilities
• How SAP Fiori paves the way for using AI in SAP apps
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
Adapting Agility: Getting your Agile Transformation Unstuck
1. Adap%ng
Agility:
Ge0ng
your
Agile
Transforma%on
Unstuck
Camille
Bell
cbell@CamilleBellConsul0ng.com
Twi5er
@agilecamille
Agile
DC
2012
October
23,
2012
2. Audience
Some
Assump0ons
About
You:
• You
have
read
agility
books
or
a8ended
training
• You
manage,
lead,
coach
or
encourage
the
use
of
agile
prac<ces
• You,
yourself,
are
agile
• But
.
.
.
some%mes
things
could
be
going
be1er
cbell@CamilleBellConsul0ng.com
2
3. Approach
What
We’re
Going
to
Do:
• Look
at
a
few
common
agile
transforma<on
issues
• Use
my
experience
and
that
of
some
other
agile
coaches
• For
each
example
issue
– Examine
the
What,
Impact
and
Why
– Suggest
poten<al
Mi0ga0ons
(Things
to
Try)
• Provide
a
template
to
examine
issues
What
We’re
Not
Going
to
Do:
• Solve
all
Agile
issues
• Provide
all
possible
solu<ons
for
any
issue
• Promise
any
Silver
Bullets
cbell@CamilleBellConsul0ng.com
3
4. Issue
&
Mi<ga<on:
General
Template
What:
• <general
problem
descrip<on>
Impact:
• <lesser
and
greater
impacts>
Why:
• <likely
causes>
Mi0ga0on
(things
to
try
to
solve
problem):
• <target
each
cause>
or
• <some
general
op<ons
for
mul<ple
causes>
or
• <both>
cbell@CamilleBellConsul0ng.com
4
5. Issue:
Missing
Customer
What:
• No
on-‐site
customer
for
XP
– Scrum
Product
Owner
is
undesignated
or
unavailable
Impact:
• No
direc<on,
no
feedback
=>
WRONG
PRODUCT
Why:
• On-‐site
customers
are
more
the
excep<on
than
rule
• Not
available
during
business
hours
– Truly
overly
busy
-‐
running
the
business,
on
market
room
floor
– Physically
unavailable
(e.g.
in
ba8lefield,
space,
etc.)
– Specula<ve
customer
doesn’t
yet
exist
– Customer
doesn’t
see
value
in
<me
spent
cbell@CamilleBellConsul0ng.com
5
6. Mi<ga<on:
Missing
Customer
Customer
truly
overly
busy:
• Shadow
and
observe
customers
Customer
physically
unavailable:
• Use
proxies
who
have
worked
in
customer
role
Real
customer
doesn’t
yet
exist:
• Work
with
marke<ng
or
others
close
to
poten<al
customers
• Create
customer
focus
groups
Customer
doesn’t
see
value
in
0me
spent:
• Quickly
create
mini
app
based
on
best
guess
of
customer
values
(implement
one
or
two
small
features)
• Demonstrate
to
customer
in
their
space
at
their
convenience
• Get
feedback
• Repeat
un<l
customer
becomes
involved
cbell@CamilleBellConsul0ng.com
6
7. Issue:
No
Single
Product
Owner
What:
• Scrum
expects
a
single
Product
Owner
• But
you
have
many
customers
Impact:
• No
priori<za<on,
wrong
priori<za<on
and/or
import
features
en<rely
neglected
=>
WRONG
PRODUCT
Why:
• Complex
apps
have
many
types
of
users
with
different
needs
• A
single
person
seldom
knows
all
user
roles
in
detail
• A
single
person
can’t
weigh
compe<ng
needs
outside
his
exper<se
cbell@CamilleBellConsul0ng.com
7
8. Mi<ga<on:
No
Single
Product
Owner
Op<on
1:
Dividing
feature
allotment
by
ROI
– If
marke<ng
or
sales
can
determine
ROI
by
user
type
• Give
each
Product
Owner
a
propor<onal
share
of
feature
development
Op<on
2:
Dividing
feature
allotment
evenly
– If
you
can’t
determine
ROI
or
similar
weighted
value
• Give
each
Product
owner
an
equal
share
of
feature
development
cbell@CamilleBellConsul0ng.com
8
9. Mi<ga<on:
No
Single
Product
Owner
(con<nued)
Op<on
3:
Establish
Kanban
style
feature
input
queue
– Set
a
Work
in
Progress
Limit
– Let
each
Product
Owner
submit
a
story
to
the
queue
– Let
POs
horse
trade
among
themselves
for
priority
queue
posi<oning
Op<on
4:
Establish
a
Chief
Product
Owner
– Has
no
features
of
his
own;
only
priori<zes
other
POs’
features
– Could
be
dedicated
agile
coach
cbell@CamilleBellConsul0ng.com
9
10. Issue:
User
Stories
are
Too
Big
What:
• User
stories
should
be
small
enough
that
several
can
be
completed
during
a
single
itera<on
• But
your
customer’s
user
stories
take
weeks
to
complete
Impact:
• Development
cadence
is
very
uneven
• Es<ma<on
is
difficult
and
inaccurate
• Comple<on
of
any
single
user
story
is
uncertain
=>
WRONG
PRODUCT
and/or
LATE
PRODUCT
Why:
• Your
user
stories
are
complex,
compound
stories
including
many
features,
alterna<ve
flows,
mul<-‐part
condi<onals,
tackle
all
levels
at
once
or
are
one
large
general
case
cbell@CamilleBellConsul0ng.com
10
11. Mi<ga<on:
User
Stories
are
Too
Big
Split
big
stories
apart
into
many
small
stories:
• Spilt
many
featured
stories
into
separate
stories
• Spilt
condi<onal
stories
with
“and”,
“or”,
“then”
or
other
connector
words
into
separate
stories.
• Split
implied
condi<onal
stories
into
separate
stories
(e.g.
“process
all
credit
cards”
becomes
“process
American
Express”,
“process
Master
Card”,
“process
“VISA”,
etc.
• Split
complex
alterna<ve
flow
stories
into
separate
main
flow
(happy
path)
and
mul<ple
alternate
flow
stories
• Split
collec<on
stories
into
some
first
story
with
add
on
stories
• Split
recursive
general
case
stories
first
into
a
base
case,
recursive
func<onality
becomes
separate
stories
• Implement
the
simplest
stories
first
• Refactor
out
commonali<es
between
stories
on
implementa<on
of
later
related
secondary
and
ter<ary
stories
cbell@CamilleBellConsul0ng.com
11
For more ideas see:
Bill
Wake’s
3
“20
Ways
to
Split
Stories”,
&
Mike
Cohen’s
“User
Stories
Applied”
12. Issue:
User
Stories
are
Too
Vague
What:
• You
are
wri<ng
User
Stories
to
avoid
requirements
bloat
• You
even
ask
the
customer
ques<ons
as
you
go
• But
when
you
demo,
you
discover
you
are
way
off
the
mark
Impact:
• Incorrect
func<onality,
<me
wasted
correc<ng
=>
WRONG
PRODUCT
and/or
LATE
PRODUCT
Why:
• User
Stories
didn’t
provide
enough
detail
to
implement
cbell@CamilleBellConsul0ng.com
12
13. Mi<ga<on:
User
Stories
are
Too
Vague
User
Stories
didn’t
provide
enough
detail
to
implement:
• Cards
aren’t
enough:
Need
Jeffries
3
Cs*
– Card:
the
User
Story
itself
– Conversa<on:
talk,
repeat
what
the
customer
said
in
different
words,
get
feedback,
ask
clarifying
ques<ons
for
more
details,
challenge
your
assump<ons
– Confirma<on:
automated
tests
• Automated
tests
demand
precision
– Given,
When,
Then
Cucumber
tests
are
very
good
for
high
level
ATDD,
BDD
– If
possible
sit
down
with
customer
to
as
you
write
tests
– Show
the
tests
to
customer
– Drill
down
with
Rspec
or
Shoulda
– Get
test
data
input
and
expected
results
from
customer
• Run
the
tests
and
show
results
to
the
customer
– Customer
may
think
of
something
he
forgot
cbell@CamilleBellConsul0ng.com
13
Ref:
Ron
Jeffries
3
Cs
of
User
Stories
14. Customer
Collaborates
with
Dev
Team
on
Confirma<on
of
Stories
cbell@CamilleBellConsul0ng.com
14
User Story: Vetting Sighting
In order to show confirmation of a sighting,
As a US-CERT analyst,
I want to mark a sighting a vetted
• XYZ sighting is viewed by Charley US-CERT analyst
• Charley marks
sigh<ng
as
ve8ed
• Tracy from Treasury searches for sigh<ngs
ve8ed
today
• Tracy sees XYZ as
a
confirmed
sigh<ng
Ref:
Ron
Jeffries
3
Cs
of
User
Stories
15. User
Stories
Confirmed
Through
Automated
Tests
During
Itera<on
cbell@CamilleBellConsul0ng.com
15
• XYZ sighting is viewed by Charley US-CERT analyst
• Charley marks
sigh<ng
as
ve8ed
• Tracy from Treasury searches for sigh<ng
ve8ed
today
• Tracy sees XYZ as
a
confirmed
sigh<ng
User Story: Vetting Sighting
In order to show confirmation of a sighting,
As a US-CERT analyst,
I want to mark a sighting a vetted
describe ”Imports TEWI sightings" do
context "a simple line item should know its name, quanity and price" do
let(:purchase) { LineItem.new("1 book at 12.49") }
it "should have a name of 'book'" do
purchase.name.should == 'book'
end
it "should have a quanity of 1" do
purchase.quantity.should == 1
end
it "should have a price of 12.49" do
purchase.price.should == 12.49
end
end
describe ”CERT analyst finds a recent TEWI sighting" do
context "a simple line item should know its name, quanity and price" do
let(:purchase) { LineItem.new("1 book at 12.49") }
it "should have a name of 'book'" do
purchase.name.should == 'book'
end
it "should have a quanity of 1" do
purchase.quantity.should == 1
end
it "should have a price of 12.49" do
purchase.price.should == 12.49
end
end
describe ”Vets a sighting" do
context "a simple line item should know its name, quanity and price" do
let(:purchase) { LineItem.new("1 book at 12.49") }
it "should have a name of 'book'" do
purchase.name.should == 'book'
end
it "should have a quanity of 1" do
purchase.quantity.should == 1
end
it "should have a price of 12.49" do
purchase.price.should == 12.49
end
end
describe ” Trusted partner finds un-vetted sighting" do
context "a simple line item should know its name, quanity and price" do
let(:purchase) { LineItem.new("1 book at 12.49") }
it "should have a name of 'book'" do
purchase.name.should == 'book'
end
it "should have a quanity of 1" do
purchase.quantity.should == 1
end
it "should have a price of 12.49" do
purchase.price.should == 12.49
end
end
describe "Trusted partner finds vetted sighting" do
context ”a vetted sighting should be clearly vetted" do
before(:each) do
new_sighting.build_from_TEWI()
cert_user.new(‘default_cert’)
new_sighting.vet(cert_user)
new_partner.new(‘default_partner’)
end
it "should have a tag of ’vetted'" do
new_sighting.tag.should_include == ’vetted'
end
it "should be viewable by partner" do
new_sighting.accesable_by(new_partner).should == true
end
end
16. Issue:
High
Bug
Count
What:
• You
have
a
con<nuing
stream
of
bugs
• Bug
count
isn’t
going
down
and
may
be
going
up
• Some
previously
fixed
bugs
show
up
again
Impact:
• Unstable
product
=>
UNHAPPY
USERS,
BAD
PRESS,
PAYING
USERS
DEFECT
TO
OTHER
VENDORS
Why:
• Lack
of
understanding
of
end
user
• High
technical
debt
cbell@CamilleBellConsul0ng.com
16
17. Mi<ga<on:
High
Bug
Count
Lack
of
understanding
of
end
user:
• Common
problem
in
early
product
life
– Release
Beta
versions
to
prevent
– Write
RED
test,
to
prevent
bug
recurrence
(TDD
prac<ce)
before
fixing
bugs
– Help
Product
Owner
to
get
closer
to
customer
– Follow
standard
usability
guidelines
• If
usability
problems
persist,
you
may
be
building
the
wrong
product
High
technical
debt:
• Common
problem
in
mid-‐late
product
life
– Write
RED
test,
to
prevent
bug
recurrence
(TDD
prac<ce)
before
fixing
bugs
– Set
aside
a
li8le
<me
ever
itera<on
for
Refactoring
– Target
code
to
refactor
each
itera<on
(metric_fu
gem
can
help)
– Write
tests
as
safety
net
before
refactoring
code
– Write
all
new
code
following
BDD
and
TDD
prac<ces
cbell@CamilleBellConsul0ng.com
17
18. Issue:
Customers/POs
Never
Choose
Technical
Stories
for
Next
Itera<on/Sprint
What:
• User
Stories
are
wri8en
“As
a
<user>,
I
want
<feature>,
so
that
<value>”
• Some
of
the
stories
are
have
a
strong
technical
focus
• The
technical
stories
are
important
• But
the
customer
never
selects
technical
stories
Impact:
• No
technical
stories
chosen
=>
INCREASING
TECHNICAL
DEBT
• Increasing
Technical
Debt
=>
SLOWER
NEW
FEATURE
DEVELOPMENT
• Increasing
Technical
Debt
=>
INCREASING
BUG
COUNT
• Increasing
Bug
Count
=>
USER
DEFECTION
TO
OTHER
VENDORS
Why:
• Customer
priori<zes
only
by
business
value
• Technical
debt
doesn’t
seem
real
to
customer
cbell@CamilleBellConsul0ng.com
18
19. Mi<ga<on:
Customers/POs
Never
Choose
Technical
Stories
for
Next
Itera<on/Sprint
Make
con%nuous
technical
improvement
part
of
everyday
work
not
separate
stories:
• Improving
your
code
base
shouldn’t
require
permission
– You
don’t
need
permission
to
write
code,
compile
or
check
into
a
repository;
similarly
technical
improvement
is
part
of
every
techie’s
job
• Every
<me
you
touch
code
that
needs
modifica<on
for
new
features,
improve
it
technically
as
well:
– Add
acceptance,
unit,
integra<on
tests
to
the
code,
if
missing,
enhance
as
needed
– With
passing
tests
in
place,
refactor
the
code
you
have
changed
• But,
in
some
places,
the
poli<cal
culture
requires
a
different
approach
cbell@CamilleBellConsul0ng.com
19
20. Mi<ga<on:
Customers/POs
Never
Choose
Technical
Stories
for
Next
Itera<on/Sprint
Customer
priori0zes
only
by
business
value:
• The
customer
is
doing
the
right
thing
based
on
the
informa<on
available
• All
stories
need
to
clearly
state
customer
value
• The
format
of
the
user
story
is
part
of
the
problem.
Even
a
technical
story
must
include:
– Business
value
not
technical
value
– Some
business
user
not
a
technical
user
• Instead
use
this
format:
“In
order
to
<business
value>,
As
a
<
business
user>,
I
want
<feature>”
cbell@CamilleBellConsul0ng.com
20
21. Mi<ga<on:
Customers/POs
Never
Choose
Technical
Stories
for
Next
Itera<on/Sprint
cbell@CamilleBellConsul0ng.com
21
Story: Refactor Big Ball of Mud
As a programmer,
I want to refactor the ”big ball of mud" code,
So that the code is simpler
Story: Faster Features / Cheaper Maintenance
In order to deliver new features faster and lower maintenance costs,
As a program manager <or other applicable business user>,
I want the the ”big ball of mud" code refactored
Value
last
Technical
user
No
clear
business
value
Value
first
Business
user
Clear
business
value
22. Mi<ga<on:
Customers/POs
Never
Choose
Technical
Stories
for
Next
Itera<on/Sprint
Technical
debt
doesn’t
seem
real
to
customer:
• Technical
debt
is
too
abstract
• Find
a
way
to
make
the
tech
story
concrete
• Where
possible,
visualize
debt
• Or
measure
tech
debt
in
<me
or
money
• For
example,
to
visualize
a
big
refactoring
story:
– Print
out
everything
that
needs
refactoring
– Spread
it
out
where
everyone
can
see
cbell@CamilleBellConsul0ng.com
22
Photo Ref:
Henrik
Knibergm
”Lean
from
the
Trenches”
23. What:
• There
are
dozens
or
possibly
hundreds
stories
in
the
product
backlog
• Scrum
says
the
Product
Owner
should
priori<ze
all
of
them
1,
2
…
etc.
• That
isn’t
happening
Impact:
• Worst
case:
No
priori<za<on,
wrong
priori<za<on
=>
IMPORTANT
FEATURES
NEGLECTED
while
=>
WASTING
TIME
and
MONEY
Why:
• The
customer
has
limited
<me
• The
customer
doesn’t
see
the
value
in
priori<zing
everything
in
numerical
order
Issue:
Customers/POs
Won’t
Take
the
Time
to
Priori<ze
the
Backlog
cbell@CamilleBellConsul0ng.com
23
24. Mi<ga<on:
Customers/POs
Wont
Take
the
Time
to
Priori<ze
the
Backlog
If
0me
is
limited
and
there
are
too
many
stories,
you
don’t
need
to
priori0ze
them
all:
• Make
the
best
use
of
the
<me
the
customer
does
have
• The
customer
may
be
right
– If
you
have
hundreds
of
un-‐priori<zed
user
stories,
priori<zing
them
all
is
a
waste
of
<me
Use
a
progressive
triage
to
find
top
stories
cbell@CamilleBellConsul0ng.com
24
25. Mi<ga<on:
Customers/POs
Wont
Take
the
Time
to
Priori<ze
the
Backlog
Progressive
triage
to
find
top
stories:
1. Get
10
or
12
top
user
stories
in
priority
order
(or
skip
to
step
2)
– Ask
the
customer
for
the
top
10
or
12
user
stories
(this
may
not
work)
– Priori<ze
those
1,
2,
3
.
.
.
– Implement
those
stories
and
ignore
the
rest
un<l
down
to
the
3
or
4
remaining
– As
customer
to
select
and
priori<ze
few
more
top
stories
un<l
you
have
10
or
12
2. Have
customer
divide
stories
into
High,
Medium
&
Low
– Works
best
with
movable
cards
or
s<cky
notes
– There
will
be
a
dispropor<onate
number
of
highs
(this
is
normal)
– Remove
all
the
Medium
and
Low
stories
3. Repeat
step
2
un<l
down
to
10
or
12
user
stories
4. Priori<ze
those
1,
2,
3
.
.
.
cbell@CamilleBellConsul0ng.com
25
26. Mi<ga<on:
Customers/POs
Wont
Take
the
Time
to
Priori<ze
the
Backlog
cbell@CamilleBellConsul0ng.com
26
High
Medium
Low
Backlog
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
In
order
to
.
.
.
As
a
.
.
.
I
want
.
.
.
27. Issue:
Velocity
is
Con<nually
Slowing
Down
What:
• New
user
stories
with
the
same
complexity
/
story
points
take
longer
than
similar
older
user
stories
Impact:
• Slower
feature
development
=>
INCREASED
DEVELOPMENT
COST
per
FEATURE
and
FEWER
FEATURES
or
LATE
PRODUCT
Why:
• Task
switching
• Change
in
staffing
• Increasing
technical
debt
cbell@CamilleBellConsul0ng.com
27
28. Switching
between
three
one
week
tasks
means
none
of
them
get
done
in
three
weeks.
Week 1 Week 2 Week 3 Week 4
Task A
Task B
Task C
Dev
completes
task
before
star<ng
next
one
Dev
switches
between
tasks
Ref:
Mary
and
Tom
Poppendieck
on
Lean
cbell@CamilleBellConsul0ng.com
28
29. Mi<ga<on:
Velocity
is
Slowing
Down
Task
switching:
• Set
strict
Work
in
Progress
Limits
to
prevent
task
switching
– Recommended
Max
WIP
limit
=(
#
Developers
/
#
Developers
per
Story)
+
1
(
if
stories
get
blocked)
– e.g.
XP
Team
of
6
Developers:
6/2
+
1
=
WIP
of
4
– Lower
WIP
limit
further
may
have
benefits
Change
in
staffing:
• Staff
turnover
slows
velocity
as
new
members
spin
up
• Use
pair
programming,
etc.
to
spin
up
faster
and
lessen
Truck
Factor
• Work
to
make
your
team
a
place
people
want
to
stay
Increasing
technical
debt:
• Use
“High
technical
debt”
mi<ga<on
from
“High
Bug
Count”
cbell@CamilleBellConsul0ng.com
29
30. cbell@CamilleBellConsul0ng.com
30
Story
Board
with
WIP
Limits
Ref: Reconstructed Kanban board used at Yahoo
Note: the absolute limit to
the number of stories in
progress at one time for
each activity
Note: only one Expedite story
at a time -- no room for more!
31. Issue:
Too
Much
Work
in
Itera<on
Despite
Story
Points
Matching
Prior
Velocity
What:
• The
es<mated
story
point
for
an
itera<on
are
iden<cal
to
prior
itera<ons
• But
.
.
.
comple<ng
commi8ed
stories
is
hit
and
miss
• And
.
.
.
the
team
when
the
team
misses,
the
team
misses
by
a
lot
Impact:
• Missed
commitments
=>
LOST
TRUST,
LATE
PRODUCT
Why:
• Underes<mated
stories
• Some
stories
“too
small”
to
es<mate
• Staff
availability
varies
• Too
many
fire
fights
• Change
in
staffing
• High
technical
debt
• Too
much
task
switching
cbell@CamilleBellConsul0ng.com
31
32. Underes0mated
stories:
• If
poli<cal
pressure
is
causing
team
to
lower
es<mates,
stand
firm,
tell
the
truth
and
provide
op<ons
to
those
pressuring
the
team
– Some<mes
it
is
very
hard
to
tell
management
or
business
how
much
work
something
is,
but
it
will
be
worse
when
your
team
doesn’t
deliver
– Suggest
to
management
implemen<ng
best
value
split
first
Some
stories
“too
small”
to
es0mate:
• Team
has
a
number
of
“0”
point
stories
– e.g.
“fix
spelling
error”,
“change
font
size”,
“change
background
color”,
etc.
• Individually
they
aren’t
worth
es<ma<ng,
but
together
they
add
up
– Lump
a
similar
group
together,
un<l
worth
1,
2
or
3
story
points
Staff
availability
varies:
• Some
variability
is
normal,
lower
commitments
accordingly
• Remember
to
account
for
vaca<ons,
holidays,
training
and
other
predictable
staff
absences
(ask
every
itera<on,
don’t
assume
you
know)
cbell@CamilleBellConsul0ng.com
32
Mi<ga<on:
Too
Much
Work
in
Itera<on
33. Mi<ga<on:
Too
Much
Work
in
Itera<on
Too
many
fire
fights:
• Avoid
fire
fights
if
you
can,
but
oven
you
can’t
• Consider
using
Kanban
with
mul<ple
input
queues
to
handle,
Expedite,
Bug
Fixes,
New
Development
and
other
Levels
of
Service
• If
“surprise”
work
is
seasonal
or
predictable,
lower
other
commitments
during
those
<mes
Change
in
staffing:
• Use
“Staff
is
changing”
mi<ga<on
from
“Velocity
is
Slowing
Down”
Increasing
technical
debt:
• Use
“High
technical
debt”
mi<ga<on
from
“High
Bug
Count”
Task
switching:
• Use
“Task
switching”
mi<ga<on
from
“Velocity
is
Slowing
Down”
cbell@CamilleBellConsul0ng.com
33
34. Issue:
Standup
Mee<ng
Take
Forever
What:
• Standup
mee<ngs
are
supposed
to
be
short;
usually
15
minutes
max
• Your
standup
mee<ng
take
much,
much
longer
Impact:
• Standup
is
dreaded,
poorly
a8ended,
not
held
daily
• A8endees
space
out
missing
important
informa<on
=>
STANDUP
FAILS
PURPOSE,
WASTES
TIME
Why:
• Team
members
focus
and
<me
management
is
poor
• Management
and
others
hijack
standup
• Team
is
too
large
cbell@CamilleBellConsul0ng.com
34
35. Mi<ga<on:
Standup
Mee<ng
Takes
Forever
Team
members
focus
and
0me
management
is
poor:
• Remove
all
chairs
and
force
a
real
standup
• Hold
mee<ng
daily
to
keep
it
short
and
<mely
• Time-‐box
mee<ng
and
each
speaker
with
<mers
• Use
talking
s<ck
• Un<l
team
gets
really
focused
limit
to
only
the
3
Ques<ons
• Hold
break
out
sessions
averwards
(for
those
interested)
on
topics
you
had
to
halt
discussion
during
standup
Management
and
others
hijack
standup:
• First
ensure
team
member
focus
(above)
• Remind
others
that
standup
is
for
the
technical
team
only
• Remind
observers
to
be
quiet,
if
they
interrupt
• Deal
with
the
poli<cs
cbell@CamilleBellConsul0ng.com
35
36. Mi<ga<on:
Standup
Mee<ng
Takes
Forever
Team
is
too
large:
Op<on
1:
Scrum
Solu0on
– Divide
technical
team
into
mul<ple
teams
• Hold
separate
Scrum/Standup
for
each
team
• Hold
Scrum
of
Scrums
to
roll
up
progress
&
impediments
Op<on
2:
Kanban/Scrumban
Solu0on
– If
applicable,
divide
technical
team
into
mul<ple
teams
• Hold
joint
Kanban
board
session
of
en<re
large
team
• If
needed,
hold
separate
small
team
stand
ups
averwards
cbell@CamilleBellConsul0ng.com
36
37. Issue:
Standup
Mee<ngs
Don’t
Discuss
Real
Problems
What:
• Standup
mee<ngs
are
short
and
follow
Scrum
rules
• But
real
issues
aren’t
discussed
Impact:
• Development
is
slowed
by
late
discovered
impediments
&
risks
=>
LATE
PRODUCT
Why:
• Team
member
embarrassment,
lack
of
awareness,
etc.
• Team
members
don’t
believe
underlying
problem
are
solvable
• Facilitator
lacks
insight
into
hidden
road
blocks
• Team
members
don’t
feel
comfortable
calling
each
other
on
behavior
cbell@CamilleBellConsul0ng.com
37
38. Mi<ga<on:
Standup
Mee<ngs
Don’t
Discuss
Real
Problems
Team
members
and
facilitator
need
non-‐threatening
prac0ce
:
• Read
up
on
Bill
Wake’s
“Scrum
from
Hell”
exercise
– h8p://xp123.com/ar<cles/scrum-‐from-‐hell/
• If
needed
invent
a
“neutral
example
app”
for
exercise
– e.g.
resume
site,
travel
site,
etc.
– Don’t
build
anything,
just
pretend
• Choose
misbehavior
cards
that
highlight
teams
problems
– e.g.
hidden
impediment,
not
answering
3
ques<ons,
etc.
– Add
a
few
good
behavior
cards
to
deck
– Add
unique
team
misbehavior
cards
if
needed
• Run
“Scrum
from
Hell”
as
a
game
(about
15
minutes)
• Reveal
cards
and
talk
about
experience
• Repeat
periodically,
changing
Scrum
Master
and
team
roles
un<l
everyone
has
experience
with
different
roles
and
cards
cbell@CamilleBellConsul0ng.com
38
39. Issue:
Management
Doesn't
Value
Removing
Impediments
Quickly
What:
• Your
team
tells
management
about
the
impediments
blocking
progress
• But
.
.
.
li8le
is
done
and
what
is
done
happens
slowly
Impact:
• Impediments
are
removed
slowly
or
not
at
all
=>
TEAM
PRODUCTIVITY
IS
A
FRACTION
OF
WHAT
IT
COULD
BE
Why:
• Management
is
new
to
their
agile
role
of
road
block
remover
• Management
unaware
of
the
impact
of
impediments
and
blockers
• Middle
management
doesn’t
have
the
power
to
remove
blockers
• Removing
some
impediments
do
take
a
long
<me
in
your
organiza<on
cbell@CamilleBellConsul0ng.com
39
40. Mi<ga<on:
Management
Doesn't
Value
Removing
Impediments
Quickly
Management
is
new
to
their
agile
role
of
road
block
remover:
• Educate
your
management
team
on
Agility
– If
possible
get
management
in
Scrum
Master
or
Kanban
training
– Give
open
brown
bags
and
other
“byte
sized”
training
– Offer
to
give
short
agile
presenta<ons
at
management
retreats
– Speak
at
PMI
mee<ngs
(Scrum
especially
has
become
very
popular)
• Coach
your
managers
Management
unaware
of
the
impact
of
impediments
and
blockers:
• Use
burning
visibility
– Post
Impediments
Lists
–
with
names
when
needed
– Use
Kanban
boards
to
highlight
blocks
• Keep
metrics
on
wait
<me
• Show
impact
of
wai<ng
in
Time
and
Money
cbell@CamilleBellConsul0ng.com
40
41. Mi<ga<on:
Management
Doesn't
Value
Removing
Impediments
Quickly
Middle
management
doesn’t
have
the
power
to
remove
blockers:
• Gain
power
for
manager
– Determine
what
blocks
your
manager
from
having
the
power
he
needs
– Examine
official
(org
chart)
and
un-‐official
(buddies
network)
– Brainstorm
with
manager
to
determine
strategy
to
gain
needed
power
• Go
around
the
system
– “It’s
easier
to
ask
forgiveness
than
to
get
permission”
–
Admiral
Hopper
– But
you
have
to
be
right
(and
not
illegal)
Removing
some
impediments
do
take
a
long
0me
in
your
organiza0on:
• Problem
is
most
common
in
large
organiza<ons
with
<ers
of
compe<ng
managers,
too
many
checks
and
no
real
sense
of
balance
• Use
all
mi<ga<ons
from
“So
Many
Hoops”
(next),
that
apply
cbell@CamilleBellConsul0ng.com
41
42. Issue:
So
many
hoops
to
jump
through
that
it
takes
forever
to
get
anything
done
What:
• Your
company
has
many
departmental
teams
which
you
depend
on
and
which
depend
upon
one
another
for
equipment
and
services
• Each
has
lengthy
and
complex
approval
processes
• Each
has
overworked
staffs
and
long
wait
queues
Impact:
• Extremely
poor
overall
efficiency
=>
LATE
PRODUCT
Why:
• Each
sub
group
is
a8emp<ng
to
locally
op<mize
itself
to
100%
efficiency
• Excessive
local
op<miza<on
harms
global
op<miza<on
• No
charts
or
metrics
alert
the
CIO
of
the
magnitude
and
impact
of
queuing
delays
cbell@CamilleBellConsul0ng.com
42
43. Mi<ga<on:
So
many
hoops
.
.
.
Each
sub
group
is
a5emp0ng
to
locally
100%
op0mize
itself:
Excessive
local
op0miza0on
harms
global
op0miza0on:
• Top
level
management
(e.g.
CIO,
etc.)
is
tracking
the
wrong
things
and
providing
the
wrong
incen<ves,
un<l
CIO
becomes
aware,
li8le
will
change
No
charts
or
metrics
alert
the
CIO
of
the
magnitude
and
impact
of
queuing
delays:
• Track
wait
<mes,
create
Value
Stream
Maps
of
worst
problems
and
publish
findings
within
company
• Educate
management
on
Lean,
Kanban,
Push
vs.
Pull
&
Value
Stream
• Provide
metaphors
that
middle
and
top
management
relate
too
cbell@CamilleBellConsul0ng.com
43
44. Request
Approve
&
Priori<ze
Technical
Assessment
Code
&
Test
Verify
&
Fix
Deploy
To
Verifica<on
To
Opera<ons
Form
sent
to
Queue
Form
sent
to
Queue
Form
sent
to
Queue
Weekly
Review
Wait
for
Architect
Wait
for
Developers
15
m
½
w
5
m
2
w
15
m
2
m
2
w
3
h
45
m
1
w
2
h
3
m
15
m
6
w
+
4
h
Biweekly
Release
½
w
2
h
+
40
m
1%
Efficiency
Using a Value Stream Map
Big Delays are Reducible
Ref:
Mary
and
Tom
Poppendieck
on
Lean
cbell@CamilleBellConsul0ng.com
44
45. Request
Approve
&
Priori<ze
Technical
Assessment
Code
&
Test
Verify
&
Fix
Deploy
To
Verifica<on
To
Opera<ons
E-‐mail
Tech
Lead
E-‐mail
Supervisor
Assign
Developer
2
h
5
m
2
h
15
m
2
m
1
h
2
h
3
m
15
m
325
m
Developer
available
10
m
160
m
33%
Efficiency
15
m
Efficiency Radically Improved by
Shortening Wait Queues
Ref:
Mary
and
Tom
Poppendieck
on
Lean
cbell@CamilleBellConsul0ng.com
45
46. • Imagine
a
bridge
or
road
trying
to
carry
cars
on
100%
of
its
surface
(any
rush
hour
in
Washington,
DC)
Use Relatable Metaphor
– More
cars
push
to
get
on
the
bridge
than
it
can
possibly
handle
– Cars
back
up
for
miles
– The
rate
of
cars
crossing
the
bridge
is
very
low;
commutes
are
horrible
– If
the
traffic
limited
itself
to
capacity
of
the
road
or
bridge
the
rate
of
cars
crossing
would
vastly
increase
and
commutes
improve
Ref: David J. Anderson - ”Kanban"cbell@CamilleBellConsul0ng.com
46
47. Don’t
Go
It
Alone
Become
ac0ve
in
local
user
groups:
• Agile
Leadership
Network
(meets
monthly
in
Tysons)
• Technology
Specific
Groups
Read
about
several
agile
prac0ces:
• Lean
&
Kanban
• Scrum
• eXtreme
Programming
A5end
conferences
and
training
Bring
in
consultants,
where
appropriate
Share
your
knowledge
and
experience
cbell@CamilleBellConsul0ng.com
47
48. Camille
Bell
Agile
Coaching
&
Consul<ng
Retrospec<ves
Agile
Boot
Camps
Agile
Training
Updated
Slides
or
just
to
chat
about
things
agile
cbell@CamilleBellConsul0ng.com