Annotated slides from my "Behavior Driven Development" course. Released under Creative Commons share-alike, commercial and derivatives allowed: http://creativecommons.org/licenses/by-sa/3.0/
Behaviour-driven development (BDD) started as an improved variation on test-driven development, but has evolved to become a formidable tool that helps teams communicate more effectively about requirements, using conversation and concrete examples to discover what features really matter to the business. BDD helps teams focus not only on building features that work, but on ensuring that the features they deliver are the ones the client actually needs.
Learn what BDD is, and what it is not
Understand that the core of BDD is around conversation and requirements discovery, not around tools.
Understand the difference and similarities between BDD at the requirements level, and BDD at the coding level.
Learn what BDD tools exist for different platforms, and when to use them
A common perception of behavior-driven development (BDD) focuses on test automation with Cucumber-style “Given..When..Then” scenarios. But this is just the tip of the iceberg: in fact BDD ranges from requirements discovery and description through to driving technical design and implementation; helping testers focus their testing efforts more effectively; and even providing reliable, useful, and accurate technical documentation.
This session discusses what BDD is about, its benefits, and how it affects development teams and processes. You will see how JVM teams can effectively implement BDD with tools such as JBehave, Cucumber, Thucydides, and Spock. Come learn how much more there is to BDD than just “Given..When..Then.”
Ever wondered about Developer Experience (DevEx) and how it can truly impact your work? Join us for a chat where we break down what DevEx is and why it's relevant for everyone, not just devs. DevsOps and productivity expert Dr. Nicole Forsgren will reveal how DevEx can ignite cultural change and deliver real results in today's rapid software development landscape, backed by the latest research findings. She will share how Microsoft is leveraging a DevEx perspective to drive cultural shifts and enable AI-powered innovations that make expertise available to all teams. It's not just about code; it's about fostering better vibes and achieving outstanding outcomes for all. Don't miss out on this journey into the magic of DevEx.
An introduction to the concepts behind Continuous Delivery as well as an introduction to some of the tools available for implementing continuous delivery practices on a new project. This presentation is geared towards Java developers, but is applicable to all.
It's usually not enough time for improving comfort of code writing and product monitoring. But this is an important thing for making software products with high quality. IT society even made awesome tools for making our life easier and culture of software engineering continue growing.
YouTube Link: https://youtu.be/8Xo3l1zv41I
**DevOps Certification Courses - https://www.edureka.co/devops-certification-training **
This Edureka PPT on ‘Git Interview Questions’ will discuss the most frequently asked questions that you might face in an interview.
Follow us to never miss an update in the future.
YouTube: https://www.youtube.com/user/edurekaIN
Instagram: https://www.instagram.com/edureka_learning/
Facebook: https://www.facebook.com/edurekaIN/
Twitter: https://twitter.com/edurekain
LinkedIn: https://www.linkedin.com/company/edureka
Castbox: https://castbox.fm/networks/505?country=in
Behaviour-driven development (BDD) started as an improved variation on test-driven development, but has evolved to become a formidable tool that helps teams communicate more effectively about requirements, using conversation and concrete examples to discover what features really matter to the business. BDD helps teams focus not only on building features that work, but on ensuring that the features they deliver are the ones the client actually needs.
Learn what BDD is, and what it is not
Understand that the core of BDD is around conversation and requirements discovery, not around tools.
Understand the difference and similarities between BDD at the requirements level, and BDD at the coding level.
Learn what BDD tools exist for different platforms, and when to use them
A common perception of behavior-driven development (BDD) focuses on test automation with Cucumber-style “Given..When..Then” scenarios. But this is just the tip of the iceberg: in fact BDD ranges from requirements discovery and description through to driving technical design and implementation; helping testers focus their testing efforts more effectively; and even providing reliable, useful, and accurate technical documentation.
This session discusses what BDD is about, its benefits, and how it affects development teams and processes. You will see how JVM teams can effectively implement BDD with tools such as JBehave, Cucumber, Thucydides, and Spock. Come learn how much more there is to BDD than just “Given..When..Then.”
Ever wondered about Developer Experience (DevEx) and how it can truly impact your work? Join us for a chat where we break down what DevEx is and why it's relevant for everyone, not just devs. DevsOps and productivity expert Dr. Nicole Forsgren will reveal how DevEx can ignite cultural change and deliver real results in today's rapid software development landscape, backed by the latest research findings. She will share how Microsoft is leveraging a DevEx perspective to drive cultural shifts and enable AI-powered innovations that make expertise available to all teams. It's not just about code; it's about fostering better vibes and achieving outstanding outcomes for all. Don't miss out on this journey into the magic of DevEx.
An introduction to the concepts behind Continuous Delivery as well as an introduction to some of the tools available for implementing continuous delivery practices on a new project. This presentation is geared towards Java developers, but is applicable to all.
It's usually not enough time for improving comfort of code writing and product monitoring. But this is an important thing for making software products with high quality. IT society even made awesome tools for making our life easier and culture of software engineering continue growing.
YouTube Link: https://youtu.be/8Xo3l1zv41I
**DevOps Certification Courses - https://www.edureka.co/devops-certification-training **
This Edureka PPT on ‘Git Interview Questions’ will discuss the most frequently asked questions that you might face in an interview.
Follow us to never miss an update in the future.
YouTube: https://www.youtube.com/user/edurekaIN
Instagram: https://www.instagram.com/edureka_learning/
Facebook: https://www.facebook.com/edurekaIN/
Twitter: https://twitter.com/edurekain
LinkedIn: https://www.linkedin.com/company/edureka
Castbox: https://castbox.fm/networks/505?country=in
Docker 101 - High level introduction to dockerDr Ganesh Iyer
This deck will help you understand the basics of Docker. It introduces dockers and containers, gives a comparison with virtualization and gives some getting started guides.
DevOps has become possible largely due to a combination of new operations tools and established agile engineering practices, but these are not enough to realise the benefits of DevOps. Even with the best tools, DevOps is just a buzzword if you don't have the right culture. Join Rouan as he explores what DevOps culture looks like and how it supports rapid, scalable production releases. He'll talk about collaboration and how important shared responsibility is to enable it. He'll cover the cultural shifts that need to happen within an organisation in order to support DevOps, including supporting autonomous teams and breaking down silos. He'll also provide some insight into the culture of successful teams in a DevOps environment, by showing you how they build quality in, focus on feedback and automate (almost) everything.
2022's Most Popular Programming Languages for UI Test AutomationApplitools
See what this panel of industry experts has to say as they discuss the current landscape of programming languages used for automated testing. Get insights about the most popular programming languages and test frameworks in 2021, and hear predictions and recommendations for 2022.
Continuous Lifecycle London 2018 Event KeynoteWeaveworks
Today it’s all about delivering velocity without compromising on quality, yet it’s becoming increasingly difficult for organisations to keep up with the challenges of current release management and traditional operations. The demand for developers to own the end-to-end delivery, including operational ownership, is increasing. A “you build it, you own it” development process requires tools that developers know and understand. So I’d like to introduce “GitOps”- an agile software lifecycle for modern applications.
In this session, I will discuss these industry challenges, including current CICD trends and how they’re converging with operations and monitoring. I’ll also illustrate the GitOps model, identify best practices and tools to use, and explain how you can benefit from adopting this methodology inherited from best practices going back 10-15 years.
Kubernetes is designed to be an extensible system. But what is the vision for Kubernetes Extensibility? Do you know the difference between webhooks and cloud providers, or between CRI, CSI, and CNI? In this talk we will explore what extension points exist, how they have evolved, and how to use them to make the system do new and interesting things. We’ll give our vision for how they will probably evolve in the future, and talk about the sorts of things we expect the broader Kubernetes ecosystem to build with them.
This is a presentation I put together for a conference in 2011. It gives a fast, high level view of where Agile Software Development came from, its core values and principles, and its core practices. It is structured as 7 PechaKucha decks in a row, with short breaks in between, which requires high energy, intensity, and a sense of humor. :)
The business analyst (BA) role seems conspicuously absent from most agile methods. Does agile make the BA role obsolete? Certainly not! But how does a BA exploit the short cycle times and collaborative nature of agile methods? Drawing from the principles of lean product development flow, Steve Adolph introduces five principles for the agile BA—Open the Channels, Chart the Flow, Generate Flow, Lean Out the Flow, and Bridge the Flow. As a communicator, the BA must Open the Channels and Chart the Flow to align all stakeholders. BAs can leverage traditional tools such as use cases to Generate Flow and feed user stories to fast moving agile teams. However, large backlogs of stories are wasteful, so lean principles are applied to Lean Out the Flow. Finally BAs may need to Bridge the Flow between more traditional elements of the organization and its agile teams. Whether you are a BA new to agile or struggling to find the right fit in your team, join this highly interactive session to “get your flow” going.
In this session we will take an introduction look to Continuous Integration and Continuous Delivery workflow.
This is an introduction session to CI/CD and is best for people new to the CI/CD concepts, or looking to brush up on benefits of using these approaches.
* What CI & CD actually are
* What good looks like
* A method for tracking confidence
* The business value from CI/CD
We are more than thrilled to announce the second meetup on 10 December 2022 where we discuss GitOps, ArgoCD and their fundamentals. Inviting SREs, DevOps engineers, developers & platform engineers from all around the world.
Agenda:-
1. GitOps Overview
2. Why and What is GitOps
3. Opensource GitOps tools
4. What is ArgoCD, Architecture
5. Let's Get our hands dirty on ArgoCD
6. Q&A
Think that DevOps is just for product? Think again.
In this webinar, ITSM expert John Custy shows you how to apply DevOps principles to your IT org. This event is for anyone involved in the support and development of IT systems and services. The keys to higher-performing services are so simple, they might surprise you.
Watch the full webinar here: http://atlassian.com/help-desk/how-to-run-it-support-devops-way
Brought to you by JIRA Service Desk. Learn more: http://atlassian.com/service-desk
During this talk, Bilgin will take you on a journey exploring distributed application needs and how they evolved with Kubernetes, Istio, Knative, Dapr, and other projects. By the end of the session, you will know what is coming after microservices
Kubernetes Interview Questions And Answers | Kubernetes Tutorial | Kubernetes...Edureka!
( Kubernetes Certification Training: https://www.edureka.co/kubernetes-certification )
This Edureka tutorial on "Kubernetes Interview Questions" will help you crack interviews on various Kubernetes related roles in the industry. The different types of questions included in this session are:
1. Basic Kubernetes Interview Questions
2. Kubernetes Architecture-Based Interview Questions
3. Scenario-Based Interview Questions
4. Multiple Choice Questions
DevOps Tutorial Blog Series: https://goo.gl/P0zAfF
Docker 101 - High level introduction to dockerDr Ganesh Iyer
This deck will help you understand the basics of Docker. It introduces dockers and containers, gives a comparison with virtualization and gives some getting started guides.
DevOps has become possible largely due to a combination of new operations tools and established agile engineering practices, but these are not enough to realise the benefits of DevOps. Even with the best tools, DevOps is just a buzzword if you don't have the right culture. Join Rouan as he explores what DevOps culture looks like and how it supports rapid, scalable production releases. He'll talk about collaboration and how important shared responsibility is to enable it. He'll cover the cultural shifts that need to happen within an organisation in order to support DevOps, including supporting autonomous teams and breaking down silos. He'll also provide some insight into the culture of successful teams in a DevOps environment, by showing you how they build quality in, focus on feedback and automate (almost) everything.
2022's Most Popular Programming Languages for UI Test AutomationApplitools
See what this panel of industry experts has to say as they discuss the current landscape of programming languages used for automated testing. Get insights about the most popular programming languages and test frameworks in 2021, and hear predictions and recommendations for 2022.
Continuous Lifecycle London 2018 Event KeynoteWeaveworks
Today it’s all about delivering velocity without compromising on quality, yet it’s becoming increasingly difficult for organisations to keep up with the challenges of current release management and traditional operations. The demand for developers to own the end-to-end delivery, including operational ownership, is increasing. A “you build it, you own it” development process requires tools that developers know and understand. So I’d like to introduce “GitOps”- an agile software lifecycle for modern applications.
In this session, I will discuss these industry challenges, including current CICD trends and how they’re converging with operations and monitoring. I’ll also illustrate the GitOps model, identify best practices and tools to use, and explain how you can benefit from adopting this methodology inherited from best practices going back 10-15 years.
Kubernetes is designed to be an extensible system. But what is the vision for Kubernetes Extensibility? Do you know the difference between webhooks and cloud providers, or between CRI, CSI, and CNI? In this talk we will explore what extension points exist, how they have evolved, and how to use them to make the system do new and interesting things. We’ll give our vision for how they will probably evolve in the future, and talk about the sorts of things we expect the broader Kubernetes ecosystem to build with them.
This is a presentation I put together for a conference in 2011. It gives a fast, high level view of where Agile Software Development came from, its core values and principles, and its core practices. It is structured as 7 PechaKucha decks in a row, with short breaks in between, which requires high energy, intensity, and a sense of humor. :)
The business analyst (BA) role seems conspicuously absent from most agile methods. Does agile make the BA role obsolete? Certainly not! But how does a BA exploit the short cycle times and collaborative nature of agile methods? Drawing from the principles of lean product development flow, Steve Adolph introduces five principles for the agile BA—Open the Channels, Chart the Flow, Generate Flow, Lean Out the Flow, and Bridge the Flow. As a communicator, the BA must Open the Channels and Chart the Flow to align all stakeholders. BAs can leverage traditional tools such as use cases to Generate Flow and feed user stories to fast moving agile teams. However, large backlogs of stories are wasteful, so lean principles are applied to Lean Out the Flow. Finally BAs may need to Bridge the Flow between more traditional elements of the organization and its agile teams. Whether you are a BA new to agile or struggling to find the right fit in your team, join this highly interactive session to “get your flow” going.
In this session we will take an introduction look to Continuous Integration and Continuous Delivery workflow.
This is an introduction session to CI/CD and is best for people new to the CI/CD concepts, or looking to brush up on benefits of using these approaches.
* What CI & CD actually are
* What good looks like
* A method for tracking confidence
* The business value from CI/CD
We are more than thrilled to announce the second meetup on 10 December 2022 where we discuss GitOps, ArgoCD and their fundamentals. Inviting SREs, DevOps engineers, developers & platform engineers from all around the world.
Agenda:-
1. GitOps Overview
2. Why and What is GitOps
3. Opensource GitOps tools
4. What is ArgoCD, Architecture
5. Let's Get our hands dirty on ArgoCD
6. Q&A
Think that DevOps is just for product? Think again.
In this webinar, ITSM expert John Custy shows you how to apply DevOps principles to your IT org. This event is for anyone involved in the support and development of IT systems and services. The keys to higher-performing services are so simple, they might surprise you.
Watch the full webinar here: http://atlassian.com/help-desk/how-to-run-it-support-devops-way
Brought to you by JIRA Service Desk. Learn more: http://atlassian.com/service-desk
During this talk, Bilgin will take you on a journey exploring distributed application needs and how they evolved with Kubernetes, Istio, Knative, Dapr, and other projects. By the end of the session, you will know what is coming after microservices
Kubernetes Interview Questions And Answers | Kubernetes Tutorial | Kubernetes...Edureka!
( Kubernetes Certification Training: https://www.edureka.co/kubernetes-certification )
This Edureka tutorial on "Kubernetes Interview Questions" will help you crack interviews on various Kubernetes related roles in the industry. The different types of questions included in this session are:
1. Basic Kubernetes Interview Questions
2. Kubernetes Architecture-Based Interview Questions
3. Scenario-Based Interview Questions
4. Multiple Choice Questions
DevOps Tutorial Blog Series: https://goo.gl/P0zAfF
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.
Presentation from RTP AEM / CQ5 Meetup by Sagar Sane. This presentation provides some of the challenges and benefits of applying Test Driven Development principles to Adobe Experience Manager (AEM)/CQ5 based projects and overview of some of the tools and technologies, including Spock & Geb, which can be used for automating test cases & execution.
Described as a "woolly, fluffy, boring talk" by some and "amazing and lifechanging" by others, this talk brings the patterns of BDD - testing, and learning through the definitions of those tests - to real life and the pursuit of our personal goals.
Please see the Notes (next to Comments) - I have annotated these for easy reading.
BDD is a technique for helping team members collaborate and discover requirements in their project. It uses examples to illustrate the intended behavior of systems before they're implemented, so that the team can discover more examples and develop a shared understanding of the requirements. In this talk Liz will show why conversations are the most important aspect of BDD, how examples can help you discover things early, and why discovery is an inevitable part of software development.
Modelling by Example Workshop - PHPNW 2016CiaranMcNulty
Modelling by Example is a set of practices that combine BDD (Behaviour Driven Development) and DDD (Domain Driven Design) techniques to create a workflow that directly drives code from a starting point of user requirements. We define a feature via conversation with stakeholders, capture it as automatable requirements, then express it in code using Behat and PhpSpec.
From the book: 50 Proven Ways to Be PersuasiveHüseyin Ergin
Here is a brief presentation for a book "50 Proven Ways to Be Persuasive". Book is copyrighted, so if authors will not let me to put it here, I will take it away.
First 32 pages are examples of presentation ZEN. (or at least I tried).
CYCLES Course (4): Communication and CheckBryan Cassady
If you’re looking to build bigger and better ideas, you need to get feedback.
To get effective feedback you need to be able to explain your ideas clearly, really listen (listening is not just hearing!), slow down to make sure you are on the right path and most importantly be ready to kill bad ideas.
Deliverable: Do people understand the idea, what do they think of the idea, are we making progress. If there is no good hope of progress, kill the idea
Exploring the Essence of Mark-on,Mark-down and Mark-up.Unfooledbyu
This is a sample of Power point presentation of differentiating and obtaining Mark-on,Mark-up and Mark-down. This is a simple presentation on the concept of these three. Various activities were added, like price tag challenge, exploring mark-on,mark-up and,mark-down and the like. Mark-on is the difference between the selling price of a product or service and its cost price, expressed as a percentage of the cost price. It represents the gross profit margin on the product. Mark-on is commonly used in retail and wholesale businesses to assess profitability. Markdown refers to a reduction in the selling price of a product or service below its original price. Markdowns are often used in retail to stimulate sales, clear inventory, or respond to changes in market conditions. Markdowns can be temporary or permanent and are usually expressed as a percentage of the original selling price. Markup refers to the increase in price or value of a product or service above its production or acquisition cost. It's commonly expressed as a percentage of the cost. Markup is typically used in retail and business settings to determine the selling price of goods or services. Additionally, it shows various activities that will enhance the comprehension skills of the learners. Furthermore this presentation can offer a real-life application of Mark-on,Mark-down and Mark-up. These terms are fundamental in pricing strategies and financial analysis, particularly in retail and business operations. Understanding them helps businesses make informed decisions regarding pricing, profitability, and sales strategies.
Greenfield projects are awesome – you can develop highest quality application using best practices on the market. But what if your bread actually is Legacy projects?
Does it mean that you need to descend into darkness of QA absence? Does it mean that you can’t use Agile or modern communication practices like BDD?
This talk will show you how to be successful even with the oldest legacy projects out there through the usage of Agile processes and tools like Impact Mapping, Feature Mapping, Example Workshop, Story and Spec BDDs.
The Million Dollar Case Study - Outreach to SuppliersGen Furukawa
We have done the research, and found hooded baby towels as the flagship product of the Million Dollar Case Study.
But we now need to find a supplier to help us get to a million dollars in sales. Join this live webinar as we see what we can find on Alibaba. Who will be our long term business partner in this venture?
Applied Data Science for monetization: pitfalls, common misconceptions, and n...DevGAMM Conference
This talk guides us through modern twists on classic user-oriented data science tasks, such as churn prediction, clusterization, calculating user metrics, and others. We will discuss unusual angles for solving these tasks; how and why they can be used to improve player experience and monetization; the intuition behind these methods, and insights into inner machinery; and why conventional methods work poorly. Finally, I'll show you how you can apply this knowledge to improve your users' playing experience, and streamline analytics; and we'll talk general situation of applied data science and analytics in the industry.
A fairly long talk which I did at BDD London, on using scenarios in different ways and for TDDing stuff which isn't code (people, lives, organizations, etc.)
A while back a client asked me to help him persuade a development team to pay for my coaching out of their budget, and to show them why it might be worth doing. It turned out that they trusted me enough that I didn't need to persuade them (and I didn't cost them £100k either!) but the challenge stuck with me, and this is the presentation I made as a result. It also serves as a note of the kind of financial benefit you can get from doing Agile well.
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.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
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.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
4. An Example of an Example
Given Fred has bought a microwave
And the microwave cost £100
When we refund the microwave
Then Fred should be refunded £100.
5. An Example of an Example
Given baby rabbits cost £10
When we sell Snowy the Baby Rabbit
Then the customer should be charged £10.
7. “Given Scenario” – an antipattern
Given Fred puts a microwave in the basket
And the microwave cost £100
When Fred buys the microwave
Then he should be charged £100
When we refund the microwave
Then Fred should be refunded £100.
8. Cucumber
Feature: Addition
In order to avoid silly mistakes
As a math idiot
I want to be told the sum of two numbers
Scenario: Add two numbers
Given I have entered 50 into the calculator
And I have entered 70 into the calculator
When I press add
Then the result should be 120 on the screen
This is what most people
associate with BDD
18. Boring!
Given Fred bought a microwave
And has receipt number 1857123
And receipt 1857123 lists it at £100
When we scan the receipt
Then the screen should show the list of items
When we select the microwave
And we refund it
And scan Fred’s credit card
Then Fred should be refunded £100.
22. Is there a context in which
this event will create
a different outcome?
23. Examples
Given Fred has bought a microwave
And the microwave cost £100
And the microwave was on 10% discount
When we refund the microwave
Then Fred should be refunded £90.
24. Examples
Given Fluffy the baby rabbit
is 1 ½ months old
When we try to sell Fluffy
Then we should be told he’s too young
25. Is this the only outcome
that matters?
If we could achieve it with pixies,
would it be enough?
26. Examples
Given Fred has bought a microwave
And the microwave cost £100
When we refund the microwave
Then the microwave should be
added to the stock count.
27. Examples
Given each rabbit eats an average of
20g of carrots a day
When we sell 10 rabbits
And 5 rabbits are born
Then our order for carrots should
go down by 700g a week
28. Same scenario?
Then Fred should be refunded £100
Then the microwave should be added
to the stock count
30. Then my eyes glaze over…
When we select “baby rabbit” from the list of pets
And the customer declines all special offers
And we want a VAT receipt
And we select payment by credit card
And the customer is present
Then the receipt should say £10
And we should have £10 more takings
And the number of rabbits in stock should
decrease
And …
31. Then my eyes glaze over more
When we click the “Pets” drop-down
And we select “baby rabbits”
And we click “No”
And we check “VAT receipt”
And we click “Pay”
And we select “Credit Card”
And we click “Yes”
And …
32. Exercise
Come up with
two scenarios
with
two outcomes
from your own work,
one of which can be split
and one of which can’t.
(They don’t have to be about software)
33. And you can keep going…
Given Fred has bought a microwave
And the microwave cost £100
And the microwave is faulty
When we refund the microwave
Then a fault ticket should be printed.
35. Acceptance criteria vs. Scenarios
Given Fred has bought a microwave
And the microwave cost £100
And the microwave was on 10% discount
When we refund the microwave
Then Fred should be refunded £90.
36. Acceptance criteria vs. Scenarios
Given an item was sold
with a discount
When a customer gets a refund
Then he should only be refunded
the discounted price.
37. Acceptance criteria vs. Scenarios
Items should be refunded
at the price at which they were sold.
38. Acceptance criteria vs. Scenarios
Given Fluffy the baby rabbit
is 1 ½ months old
When we try to sell
Fluffy the baby rabbit
Then we should be told
that he’s too young
39. Acceptance criteria vs. Scenarios
Given a pet is below
recommended selling age
When we try to sell
that pet
Then we should be told
that the pet is too young
40. Acceptance criteria vs. Scenarios
We shouldn’t be able
to sell pets
younger than the
recommended
selling age
41. Exercise
Can you derive some scenarios
from these acceptance criteria?
The user should be able to add and remove bold,
italics and underlines.
When browsing an item, users should be able to see
what other users who browsed the item bought.
Pets shouldn’t be listed for sale
until they’re old enough.
85. We’re uncovering better ways of
developing software by doing it
Vision
Goal
Goal
Goal
Capability
Capability
Feature
Feature
Feature
Story
Story
Story
Scenario
Scenario
Code
Code
Code
86. We’re discovering how to
discover stuff by doing it
Whoops,
forgot
Oops, didn’t
know about
that…
Look what I
found!
Don’t need
this…
Can’t
remember
what this
was for…
Um…
Er…
Oh!
Oh F…
Dammit!
Hmm!
That’s
funny!
Ooh, look!
Interesting!
Sh..!
Oops!
97. Exercise
Can you derive a more interesting scenario
from these acceptance criteria?
The user should be able to add and remove bold,
italics and underlines.
When browsing an item, users should be able to see
what other users who browsed the item bought.
Pets shouldn’t be listed for sale
until they’re old enough.
Given, When and Then are the key bits here. Using “and” or “but” signifies that the step is the same type as the previous one.
Given, When and Then are the key bits here. Using “and” or “but” signifies that the step is the same type as the previous one.
This is actually two scenarios.The first scenario is concerned with payments. The second scenario is concerned with refunds. The first scenario is setting up the context for the second scenario.Talking through scenarios like this is absolutely fine. If you capture them, you might want to separate the two scenarios. As we’ll see later when we start looking for different outcomes and more interesting scenarios, once things start getting complicated these scenarios can be hard to maintain.Usually, if you see this, you’ll find there are either two different concerns in play, or that one of the scenarios is redundant.
There are tools available which will take your English-language steps and turn them into real automated regression tests! Cucumber, Cucumber for the JVM, SpecFlow and JBehave are all examples of system-level BDD tools. There are others which run against smaller elements of code or classes, such as RSpec and MSpec, but you don’t have to worry about those unless you’re a developer.
However, the conversations are the most important bit, so start with those.
Remember that the point of BDD is to create working software. If you find that it’s getting in the way of that, you’re probably focusing too much on the process, and too little on the goal.
A lot of teams that use BDD insist on having very clear examples for everything they attempt. As we’ll see later, some things resist well-defined outcomes, especially when they’re very new or innovative. BDD should be a collaboration tool, not a contractual one; it’s about trying to understand what the business want, not making it “their fault” if we end up producing the wrong thing.
We should always be looking for what we want next, or what we’ve got wrong, or what we could do differently.
These were some of the ideas I came up with. Others might be relevance, unexpectedness and surprise, being funny… these can all come into your scenarios, too. Make them memorable.How many people said, “These are things I value in conversations…” and started listing them, and how many shared stories of conversations they’d had? We are “homo narrans”; we learn best from stories.
When I spoke to the Head of Client Management, I said, “Given a client manager has some clients, when he logs in, then he should see his clients. Given he has no clients, what should he see when he logs in then?” I was thinking about the case when they had an empty list of clients.But the Head of Client Management said, “If you’re a client manager and you have no clients, I’m about to fire you! Get on the phone and get some clients!”From my dev perspective, I was worried about empty lists. From his perspective, an empty list was a business about to be bankrupted. So that taught me quite a bit about the domain!
If you find yourself talking in ways that seem unnatural, you’re probably thinking too hard about the solution, rather than the problem. This is a very solution-focused scenario. Also try and avoid any reference to the UI, as that’s part of the solution space too.
“Should” is a magic word that allows us to question whether an example really should happen.
Should it happen now, or should it happen later? Or at all? Should it always happen? Is there a context in which it doesn’t happen?
This is the pattern I call “context questioning”.
This is the pattern I call “outcome questioning”.A pixie is a small person. If you’ve ever read Terry Pratchett’s “Discworld” novels, you’ll know that when you take a photo in the Discworld, a little goblin or person inside the camera quickly paints the picture for you! I sometimes find it helpful to imagine that there are similar tiny people inside all of our machines, painting on the inside of our computer monitors and sitting crouched in our cash machines.As a developer, I love writing code. I can’t help it! So as soon as you start talking to me about the problem, I start writing software in my head – moving to the solution space. If I can imagine that pixies are going to do the job instead, it makes it much easier to think about, and question, what the pixies should do, instead of the implementation of it.
I also introduced the example of a cash machine. What else needs to happen if there’s a pixie in the machine giving me my £20? Oh, yes, it needs to debit the account! Now, we know that for a cash machine the two scenarios *cannot* be shipped separately. But for this, they probably can. So talking through scenarios can help you to decide what your scope is, too, as well as uncovering extra scope.
I also introduced the example of a cash machine. What else needs to happen if there’s a pixie in the machine giving me my £20? Oh, yes, it needs to debit the account! Now, we know that for a cash machine the two scenarios *cannot* be shipped separately. But for this, they probably can. So talking through scenarios can help you to decide what your scope is, too, as well as uncovering extra scope.
These are two separate aspects of behaviour, so you probably want to put them in different scenarios. It’s OK to get this wrong, though, and if someone comes up with an interesting outcome, it’s probably better just to capture it quickly. Remember that it’s more important to keep the conversation fluid and allow ideas to flow than to do it “right”.
These are not two separate aspects of behaviour. This is one transaction. It needs to happen in the same scenario, because we can’t ship one without the other. That just isn’t useful.
If you have a scenario that gets like this, you might want to start splitting it up. Nobody is really interested in talking about all these outcomes at once.
This is even worse. Focusing on the GUI ties you to a particular GUI. If you ever have a search box instead of a drop down, this is going to be a maintenance nightmare. I can tell from this scenario that whoever wrote it hasn’t actually had any conversations with anyone!
Transactional outcomes often have two different outcomes for two different stakeholders.Imagine paying someone money online. You want to have some kind of confirmation, don’t you? Would it be OK to pay the other person without getting that confirmation? Or get the confirmation when you haven’t paid? These kind of outcomes have to be shipped together.
As you talk through different scenarios, you’ll find new requirements. If you’re after an MVP (Minimum Viable Product) – the smallest thing that you could usefully ship and make money from or learn from – then think about whether you really *need* to ship the scenario or not. For instance, you could usefully deploy a cash machine which doesn’t work for people who have overdrafts, and it will still cut the bank queues down.
Another benefit we talked about is that developers start using the language in the code, so that they can talk more easily to the business and their code is easier to read and more maintainable.
This is a scenario with specific data. We can’t tell from this what the actual rules are. It’s an exemplar; an example made to *illustrate* behaviour. It’s not really a description of the behaviour.
This isn’t a scenario, even though it’s phrased as GWT. It’s acceptance criteria. It’s a description of the behaviour which is true for all the contexts mentioned… unless you can think of another context which changes this!
We don’t need to phrase things as GWT if the scenarios can easily be derived.
This isn’t a scenario, even though it’s phrased as GWT. It’s acceptance criteria. It gives us the rules for all pets, not just rabbits. If someone started with this, we could ask them, “Can you give us an example?” Using concrete examples with real baby rabbits entices our imaginations in a way that abstractions don’t. I bet you even have an image in your head of what colour Fluffy is too!
There are multiple ways of phrasing acceptance criteria. If we can’t imagine scenarios from the criteria then we can create some to help illustrate the behaviour. It’s perfectly OK to capture obvious scenarios in this form – you don’t have to write *everything* down! The trick with BDD is to get to the things we’re discovering which are new as quickly as possible.
When we talked through the examples, a lot of them read as acceptance criteria. I ask concrete questions like, “What’s his name? Can you think of an example of text that Fred might want to make bold? Can you think of an example of that?” Even just repeating “Can you give me an example of that?” usually helps reduce abstract acceptance criteria to something that really fires the imagination.
When Chris Matts taught me Feature Injection, he explained it in much the way I explained it to you. However, he has some different emphasis that’s worth reading, and is strongly aligned with the later sections on differentiation. Here’s his article on it: http://www.infoq.com/articles/feature-injection-success
There’s always someone who cares about the project; who has fought to get the budget for it, or perhaps funded it directly. This is the project owner. Everyone else is a proxy.
As well as the project owner, there will be several other stakeholders whose needs have to be met in order to go live. Often these are “gatekeeping” stakeholders – security, support, audit, legal, etc. You can engage these stakeholders before-hand and get some tests for their goals.Tom Gilb is pretty big on quantifying goals. Here’s a good article on it: http://projectmanagement.atwork-network.com/2012/03/20/qa-tom-gilb-on-quantifying-project-objectives/You may also find my blog post on identifying stakeholders across the whole value stream useful: http://leansystemssociety.org/value-streams-are-made-of-people/
To deliver the stakeholder goals, we look to see what capabilities are needed. A capability is “the capability to do something”. For instance:The capability to trade copperThe capability to book a holidayThe capability to comment on an articleThe capability to calculate counterparty exposureetc. We can also find smaller capabilities within larger ones if we need to. A 1-year, enterprise-wide project in a trading company we used this in had about 30 capabilities for the whole project, some of which were – in a rough estimate – 10 times smaller than others. Capabilities may also be principles that extend across the whole project (security, performance, etc.) They *all* have stakeholders, even the ones we refer to as “non-functional” or “technical”. Working out who the stakeholder for a requirement is, and phrasing it in terms of the business benefit, can really help to narrow down what actually *needs* to be delivered.
Some capabilities will be delivered in the form of software features. There may be one or many features related to a capability. For instance, in order to comment on an article we may need user registration, comment reporting (in case of spam, vulgarity or libel), and the comment box itself.The features that we choose to implement may change frequently during a project, especially if the capabilities we’re delivering are new. Capabilities don’t change often, though, so one trick is to find the newest capabilities, and work out a way to get feedback on those quickly!More on that in the differentiation / Cynefin section.
The reason we split features into stories is to get feedback and trust. Showing that you’ve delivered *something* that the stakeholders can see and play with is usually more valuable than trying to get a whole “complete vertical slice”. If there’s a way to show progress or get feedback more quickly, do that. Why code an entire slice if you can throw something smaller away?
Scenarios can be used to help discover the scope of features and capabilities, and to split features into stories. If we can’t think of an example in which a capability or feature proves its value to the business, maybe it won’t…
And finally, we get to code.
And later on in this talk, I show why this doesn’t actually work as neatly as this diagram shows But it’s a useful model to bear in mind for the moment.
We focus on the capability wherever possible because it gives us options for changing the lower-level steps beneath. The features we use to deliver a stakeholders’ goals often change, but the capabilities the business needs to meet those goals rarely do.
We focus on scenarios in BDD because it’s the place where the technical, problem-solving developers and the non-technical business analysts and problem-finding testers meet.
Who are the stakeholders for your project?Are there any which are missing? Are there capabilities that are simply delivered as an industry standard? Do you actually need them?
Remember the “context questioning” question? (Do you?)This is what it looks like when we apply it at the stakeholder level.
This is what outcome questioning looks like (do you remember that?)We can also do this for the other levels. Is there some context in which this feature won’t be usable? Is there some market context in which we won’t make money with this?
Testers are “whattabout” people. They ask, “What about this scenario? Or this one?”They can do this while devs are thinking about the solution, and analysts are trying to help them with it. This keeps us in the problem space for a bit longer, and helps us avoid that premature commitment. Conversations aren’t very expensive.
Here’s how evil testers are. Adev once asked me, “Why do we need testers, if we’re doing automated testing and having conversations around scenarios?” So I wrote this on a napkin. “What’s in the middle?” I asked.
“It’s a 3,” he said.“Put your tester hat on. What’s in the middle now?”
“I don’t know,” he said. “I mean, it might be a 3. But if I’m a tester, I’ll ask.”“That’s why we need testers. Of course it’s a 3, but a tester thinks about what really ought to be there, and we devs just fill in the gaps.”Then I showed it to a *real* tester.
“Might not be a 3,” the real tester said.Evil. Evil! And very, very, valuable.
For most things in life, we have choices. We can pay to extend those choices. An option is the right, but not the obligation, to have something.Implementation is a commitment. If we implement before we’ve had a chat about something, we are probably investing in the wrong thing.Similarly, if we do too much analysis about something when trying something out would be the right thing to do, we’re probably investing in the wrong thing.Automation is also a commitment!BDD, done well, helps us find the right balance between conversation and prototype.
If you don’t have actual testers, get someone to play that role. Someone who *isn’t* a dev. Us devs are very good at abstraction, and will start solving a problem before we see the whole problem. I don’t believe that an awesome dev can also be an awesome tester, or vice-versa.
That’s just how you pronounce it. Cynefin is a way of making sense of problems, and working out what kind of problem you have (relatively; the boundaries are fuzzy). This is important because…
This is how requirements have traditionally been gathered. Stakeholders are used to only having one chance to get everything they want, so they put in things that they think they *might* want. Even in Agile, we frequently have these Waterfall habits. How many projects have you been on where analysts or PMs spent time “grooming the backlog”?
Traditionally, we tend to do the most valuable things first. This gives us milestones. We normally manage these with a Gantt chart! But we’re *Agile* now, so let’s slice things up into stories…
…and then…
Bingo! Our big bucket of requirements has become a backlog. Now, we can start with the most valuable features. But really, why are the others even in there? What do we actually *need* to do to release something valuable?What if one of those 1s was really valuable, and only needed a 2 or 3 to go with it to release it? Why would you do all of them?
This is a great book to read. All projects have something new associated with them. If they don’t, get the experts in to do it (for instance, a SAP rollout).
We normally do this because we think that a deadline is the risky part of the project. I find a lot of deadlines are purely political anyway. I don’t know about you, but I hate working weekends and evenings just so a PM can look cool because they got their project in “on time”!
What if there was some aspect of the project that was differentiating? How little could we get away with doing just to get that one differentiating feature out of the door? Now we’re making money earlier, and if it turns out that our feature is too hard or it doesn’t rock the market, we haven’t invested huge amounts of money.
The summary of the next few slides can be found here:http://lizkeogh.com/2012/03/11/cynefin-for-devs/http://en.wikipedia.org/wiki/CynefinAnd this article is worth the money IMO:http://hbr.org/2007/11/a-leaders-framework-for-decision-making/ar/1The short version: There are different kinds of software.There are some things we do which make our project different to other, similar projects. Even if the only thing we do different is that it’s meant to be maintainable, or we’re doing it in HTML5, or we’re doing it for this new customer with these few new requirements, there’s always a reason we do the project, and the reason is something that didn’t exist before. People have differentiators, projects have differentiators, and so do whole organisations!If we make a cameraphone for the first time, it also has to be able to make calls, receive calls and look up numbers, otherwise it’s just a camera. These are commoditised requirements.There are also some pieces of work that are urgent and unplanned – production bugs that we have to expedite, for instance.And lastly, we have katas – simple problems with very well understood outcomes, which we often use as exercises to try out other, more complex ideas.
Spoilers happen when we see someone else’s differentiator and want it for ourselves. Eventually the differentiators become so spoiled that they’re commoditised. Everyone now has phones with cameras on them!
This matches the Cynefin framework.In the simple domain, we can understand problems easily and fix them. Cause and effect are tightly coupled, and we work by categorizing the problem.In complicated domains, we need expertise to understand the relationship between cause and effect, but they’re still predictable. We work by analyzing the problem.In the complex domain, cause and effect are only correlated in retrospect, and we can’t predict outcomes. They emerge. We have to probe, or run experiments, to understand what happens. The experiments must be safe to fail.In the chaotic domain, cause and effect aren’t correlated. Chaos is short-lived, and often very destructive. We have to act to stop our house from burning down or someone from bleeding to death!
There is a fifth domain in which we’re not sure which of the other domains dominates. So we usually act according to our preferred domain.Developers, for instance, love working in complex spaces, so they will usually take a complicated problem andautomate it, turning it into a different, complex problem.Some managers love command-and-control, which works very well when an urgent situation requires people to act, but not so well when you need people to interact in order to get an emergent outcome.
Along the border between simplicity and chaos lies complacency, which results in a small cliff-edge, like the fold in a sheet. It’s very easy to tip into chaos, and hard to get back out of it again without going all the way round all the domains!
When I showed you Feature Injection, I showed you a method of breaking down problems into smaller and smaller pieces. But we know that only works for problems which are well-understood, and for which expertise is enough!We have an expression, “Frog thinking vs. Bicycle thinking”. You can break a bicycle into pieces and put it back together again, but you can’t do that with a frog!
For things which are new, we can’t break them down. We don’t know enough about them. Breaking them down will give us the *illusion* of certainty without giving us certainty!Instead, in this space, find something we can *try out* and learn from.
On the left, you’ll start hearing the language of uncertainty.On the right, you’ll see people getting bored.BDD is brilliant for learning more about the domain in the middle, and for helping to work out when you don’t need to have any more conversations and can start coding something – either because it’s well-understood, or because it’s time to try an experiment!
What capabilities do I need to deliver if I want an app to quickly report text spammers to my mobile phone company?Which of those capabilities do we know have already been delivered?What’s the scope of this project? Would it be valuable to do it for just “3” (my network)? How about just spam containing “PPI”? What else would we absolutely need in order to release that safely?If you released that as an MVP, what would be the next thing you added to it? Another stakeholder, or another feature for “3” and me (Liz)? This is how we do release planning!
Conversations are a reasonably small commitment.
This book is all about Real Options, and I recommend it.
On one project, I got them to list the capabilities of their application. They always talked in terms of the 3 main architectural components, so we listed them in terms of the components’ capabilities.“Put a red dot on anything you haven’t done before,” I said.We estimated in very large-scale points. “Which is the smallest? Call that 20. Which is the biggest? How much bigger? Call that 400. Is there something in the middle that’s about 200? Fantastic; rank the rest.”After they’d finished, I said, “Now double everything with a red dot on, unless you can think of a good reason not to.”This included risk associated with people, process and technology… so anything where they were unclear about how it would happen, or who or when it would happen with, as well as new problems the company had never solved before.I now have a much better way of doing this: http://lizkeogh.com/2013/09/05/capability-based-planning-and-lightweight-analysis/
The team broke off different capabilities and the analysts split them into features. If the devs decided a feature was too big for a sprint, they split them into stories using scenarios. Mostly the scenarios were end-to-end.
If you were to take on the ideas in this talk, what would you like your Scrum or Kanban board to look like?
The ideas about uncertainty and certainty – and complexity and complicatedness -mean that this is a *really boring* scenario. This teaches us nothing, and if all our scenarios look like this we are yawning.
But by changing the context, we can suddenly discover uncertainty. Fred didn’t walk back into the store with a 120kg fridge-freezer on his shoulder… so, what do we do now?
Can you think of any scenarios which actually teach us something about our domain? Anything which might have more than one answer that’s “right”? Or anything which you can’t think of what the right answer is?
Those examples – the ones where we don’t know the answer and we have to try something out - *those* are the ones we want to find the most.
Hard-coding data behind a UI is a great way to get feedback on a new UI. You can also do things like send hard-coded messages over a message bus to test the performance, etc. Do whatever is new, first.
In any architecturally complex system, the feature we’re building will only need part of that system. By building just enough for the feature, we can get information about whether our chosen architecture will suit our stakeholders’ needs while leaving our options open elsewhere in the system for the future.
We code just enough of the architecture to get our feature working.
Sometimes showing an architect that you’ve left it open for change, so that it can be moved to the “ideal” architecture later, is enough. The best architects love this, because it lets *them* try things out and be wrong… and options have value.
We can look at different inputs and get different scenarios, then decide which of those inputs to do…
Or we can do the same things with outputs.
Sometimes the format of input and output is the same, but the content of output will change depending on internal rules. For instance, Amazon ships orders over a certain price for free, and Amazon Prime users get it more quickly.
This was a real project I worked on which had something similar. All those little squares are user stories. How can we possibly spot uncertainty when we break everything down up-front like this?Instead, I recommend breaking things down to the capability and maybe the feature level, then letting the devs break those down into stories based on what they think they can usefully do before the next time they’re due to see stakeholders for feedback.
Remember the Asteroids game? The big asteroids travel very slowly. The smaller asteroids travel faster. The way to die quickly is to split up all the asteroids into tiny little ones that you can’t keep track of. If you do this with your stories, you’ll find your project just as hard to handle. Take one big chunk at a time, finish it off, then go for the next one.
Think of the last time you did a long project, > 9 months or so.How long would it take to do the same project again with the same people, same technology, same requirements, same everything… just *again*?That’s how much of our projects is taken up with learning! The more innovative the project, the more learning will go on. If you’re into Theory of Constraints, you can think of a project as a factory which processes ignorance into non-ignorance through learning. By focusing on that, we go faster.If you haven’t come across Theory of Constraints, here’s the book to read: EliyahuGoldratt, “The Goal”http://www.amazon.co.uk/The-Goal-Process-Improvement-ebook/dp/B002LHRM2O/Along with “Waltzing with Bears”, it’s one of my two most recommended texts to get hold of. It’s also a fiction book, so a very easy read!
Here’s my stand-up template. Using this will help the team focus on the interesting things that people find out, which will accelerate the learning of the whole team as well as enabling them to respond to each other’s discoveries.As another hint: PMs, or anyone with authority, should speak last if at all. If they start the meeting off it will automatically turn into a status update meeting to that person.Those of you telling the team who should speak next… what would happen if you stopped doing that? If they had a beanie toy, or a ball, to throw to each other to determine the order in which they went and who spoke? What amazing stuff *could* happen?