deliver:Agile 2019

Abstract:
Imagine you have a grand piano in your living room. Now imagine you are moving homes and you would like to take your beloved piano with you. What is the first thing you would do? Jump straight to the task? Start pushing it along, attempting to advance it as far as you can?
Well if you are smart, the idea of moving a piano by yourself, or perhaps with yourself and one other person alone, should leave you thinking twice about your logic. The weight of the piano is grand, no pun intended, but also the shape is rather awkward. This doesn't make the task for any one or two people very easy. In fact, you would likely begin to least think about what reinforcements you could call in to assist. Extra hands could definitely (1) lighten the burden, (2) distribute efforts across the all the awkward areas of the piano, and (3) move it more efficiently.
So the real question I now have is, why do we not address carrying the weight of quality in a similar manner?? It is definitely a huge job, way bigger than any one person can handle alone. It is incredibly awkward, considering how many areas of expertise you would have to master in order to be the most precise at your job. And, the time it takes to execute testing is usually infinite. So why would a tester take on all of the testing by themselves?!
They shouldn't! And with proper planning, don't have to.
A tester can address testing understanding that the quality of the product they are working on is not entirely up to them, the work is far reaching, and can be executed with more efficiency when more people are involved. The way they do is by curating a detailed test plans - an interactive, self organizing process where experience and collaboration govern the team's ability to deliver in the most effective way.
In this workshop we will work together to come up with the master plan! Together we will:
Define Roles and Responsibilities,
Decide on Test Approaches,
Outline Scope,
Create a Text Matrix, and
Configure a Reporting Guidelines
With our time, we will call all hands on deck to work through a test plan, distributing the weight of quality, working together to produce better, stronger plans for our products.
This is a workshop for all members of a team. A chance to work together to understand testing at a planning and execution level.

Learning Outcomes:

• Executing a Test Plan
• Delegating Responsibilities
• Configuring and Outlining Scope
• Importance of Test Matrices

Abstract:
With business models and business needs changing so rapidly, an adaptable architecture is critical to allow systems to cope with change. Historically, adaptability has been sought through anticipating the places where a system must be adaptable and through various architectural approaches. However, recent experiences have shown these approaches to be inadequate, at least as currently practiced. This workshop presents some principles of evolutionary architecture that allow systems to respond to change without needing to predict the future. We then describe three approaches that realize these principles and discuss how these approaches support adaptability of systems in an evolutionary way. As an exercise, groups at the tables will take a couple of architectural requirements and decide on appropriate fitness functions for those requirements.

Learning Outcomes:

• * Learn about the underlying principles of evolutionary architecture and will see how various techniques like continuous delivery support creating and evolving the architecture of systems.
• * Gain experience creating fitness functions and seeing how they support architectural governance and test for architectural features.

Attachments:

• BuildingEvolArchWkshop.pdf

Abstract:
Agile methodologies lack the details of how UX fits into software dev projects. Some suggest that a Product Manager describing features is enough for developers, UX should train others to do their specialized jobs, or excluding UX experts solves them being “too siloed” and “not collaborative.” This happens with no other role in software dev; it’s hurting culture, efficiency, and productivity, and creating poor products for customers.
Your customer only sees your UX, not 1000 developers or if you were Agile or Lean. Companies are figuring out that UX specialists and the User-Centered Design process are good investments that more than pay for themselves. Recent highly-publicized UX failures remind us that skimping on the UX process can alienate customers, create negative media attention, and burn millions of dollars.
Learn how the UX process fits into Agile; augments DevOps goals; increases customer satisfaction; and saves time, money, and sanity before developers write a line of code.

Learning Outcomes:

• Objectives include:
• 1) Learn that DevOps goals overlap with UX goals.
• 2) Correct integration of UX experts and tasks saves time and money, increases productivity and efficiency, creates the best idea execution for the target customers, and keeps engineering’s changes and rebuilds to a minimum.
• 3) Learn how UX specialists conduct user research; design your entire product, app, website, or system; validate it through user testing; iterate to fix flaws; and deliver vetted blueprints so you can build once.
• 4) How User-Centered Design fits into project timelines and development methodologies including Agile and Lean.

Abstract:
Agile methodologies promote and advocate for colocated teams, but many if not most companies employ distributed teams. Can distributed teams turn the Agile dials up to 11 and still have whiteboards, sticky notes, pair programming, TDD, and full-participation agile ceremonies, all without regulating some team members to being second-class citizens of the project?
Yes we can, and yes we do! Joe will walk through the processes, practices, and enabling technologies developed at pioneering agile consultancy Pivotal Labs over the past 13 years. Learn how to incorporate a few occasional "remotes", maintain teams split across regions and timezones, and even how to adopt an "everyone's remote" approach to your distributed agile teams.
Part I of this session is an overview and discussion of the team processes, pro-tip, and pitfalls of several distributed agile team structures; Part II will be a deep dive into supporting technologies, remote pair programming, and a unified solution to all time-zone challenges... kind of.

Learning Outcomes:

• Demonstrate that distributed agile teams can be as successful as colocated agile teams
• Teach attendees the process skills to efficiently run a distributed agile team
• Teach attendees the tools and technologies that help enable successful distributed agile teams
• Attendees share out their own pro-tips and pitfalls so everyone can improve, including the speaker.

Attachments:

• Distributed Teams, Pivotal Style, v2 (1).pdf

Abstract:
Discover insights that can be transformed into opportunities ripe for innovation with our Customer Journey Mapping workshop. When user’s often desire seamless experiences across mobile, online and offline platforms, mapping with empathy can help you understand and maximize effectiveness of every touch-point. You will see the big picture holistically and learn how to tell the story of common pain points along the journey and harness the power of visually storytelling the customer experience.

Learning Outcomes:

• When to use the tool, who to engage, and how to make it a living document as your product evolves
• To discover what is customer visible value
• To empathize with your user, understanding how they experience your product or service
• To find opportunities to better engage with your customers by identifying the gap between the current and desired experience
• To prioritize at high level based on the greatest value delivered

Abstract:
Organisations today can no longer afford to deliver new features to their respective markets once a year or even once a quarter. In the attempt to catch up with the competition, they jump onto DevOps journey starting with the "How" and losing the sight of "Why" and "What".
Join this gamified simulation workshop to gain a solid understanding of foundational principles of the DevOps culture. Experience the benefits of DevOps transformation even before initiating one in your enterprise!
Ideally designed for organisations that are
• Evaluating their approach to DevOps transformation
• Making their first steps in adopting DevOps practices
• Noticing the gaps left by “automation only” approach to DevOps.
This course
• Is based on real-life examples from medium to large size organizations
• includes the latest findings from the State of DevOps report 2018
• delivers key ideas from “The Phoenix Project” by Gene Kim
• facilitates a number of debriefings to draw parallels between the issues highlighted in the simulation and some of the similar issues the learners may have in their organisations (impact on business, segregation of duty, change management, Job security and even fear-based culture)
Through this powerful role-based simulation with LEGO and Chocolate, participants experience the benefits of cross-training, learn to eliminate silos, adopt systems thinking and gain valuable insights that can be immediately applied in their organisations.

Learning Outcomes:

• Explain the benefits of the business and IT alignment with DevOps.
• Identify the principles and practices including: Continuous Integration, Continuous Delivery, testing, “shift left” on security, “one piece flow” and the Three Ways of DevOps.
• Relate DevOps to Agile, Lean and Theory of Constraints.
• Discuss the critical role of the safety culture in enabling Continual Experimentation and Learning at the level of an organisation.
• Explain the changes DevOps brings to a Segregation of Duty, Audit requirements, CAB, risk management etc.

Attachments:

• Dana_Pylayeva_DevOpsCulture_immersion.pdf

Abstract:
Test-First is a larger umbrella than many think. It ranges from more than Acceptance Test-Driven Development and Unit Testing. Done properly, it starts with product management and goes through value realization. This talk will not discuss all of test-first but will center on how Test-First affects the developer – from a requirements point of view to development to release. It will discuss how test-first with the product owner sets the stage for good design as a side-affect of getting clarity on requirements. This “side-effect” is something called out in design patterns, but not often discussed. The talk will also discuss on how the use of test-first needs to focus on value realization, not merely writing the code. The talk concludes by discussing the relationship of developers to ops and other post-production roles in the organization.

Learning Outcomes:

• how test-first is useful virtually throughout the value stream
• how design patterns espouse a test-first mind set
• the relationship between the code quality of "testability" relates to quality design

Abstract:
Since the dawn of software development, we've struggled with a huge disconnect between the management world and the engineering world. We try to explain our problems in terms of "technical debt", but somehow the message seems to get lost in translation, and we drive our projects into the ground, over and over again.
What if we could detect the earliest indicators of a project going off the rails, and had data to convince management to take action? What if we could bridge this communication gap once and for all?
In this session, we'll focus on a key paradigm shift for how we can measure the human factors in software development, and translate the "friction" we experience into explicit risk models for project decision-making.

Learning Outcomes:

• Attendees will learn see the challenges of software development through a new paradigm, with new strategies for keeping a project off the rails.

Attachments:

• ultimate_metric_v6.pdf

Abstract:
Abuser stories give us a way to view our systems from our enemies perspective. Think "user stories" through the bad guy's lens.
Abuser stories capture potential vulnerabilities in software systems, using the standard user story format. While user stories are written from a user perspective, abuser stories are written from an enemy or attacker's perspective and describe the enemy's mal-intent and motivation.
The session will look at the concept of Abuser Stories in-depth, with hands-on exercises to create and practice your own.

Learning Outcomes:

• How seemingly benign functional user stories can create vulnerabilities in our software, leaving lots of opportunity for our enemies to take advantage of our weaknesses.
• How to use the concept of abuser stories to shed some light on where these vulnerabilities can be introduced.
• How to craft a good abuser story.
• How to craft refutation criteria so that we can determine that the attack depicted by the abuser story is not possible.
• How to estimate and rank abuser stories.

Abstract:
Part talk, part demo, part live coding. Paul and Tyler from Pivotal will take the audience through the basics of Kubernetes and then turn to the audience to go down a Kube Your Own Adventure exploration of a number of different Kubernetes related topics.

Learning Outcomes:

• Learn how to build a docker image, run that docker image, run it in Kubernetes, Write and Run a Helm chart, you name it!

Abstract:
Are you in an organization where management or leadership challenges the adoption of agile technical practices by questioning the true business value such practices provide?
Perhaps you’ve heard – “pair programming – why on earth would we pay two people to work on the same code at the same time – that’s not productive” or “why should we spend time to automate our deployment pipeline when our release process only takes about 15 minutes to run manually – we can release every day if we want to” or even better “why do we have to pay everyone overtime for being on-call during after-hours Sev1 incidents, when 90% of the time the DBAs are the root cause of Sev1 problems so everyone else gets paid overtime to sit on the bridge and wait for DBAs to fix the problem”.
If any of this sounds familiar, chances are you are working in an organization that has yet to define and communicate the impacts of adopting agile technical practices using business metrics. While technical metrics such as code complexity, test coverage, defect density, build failure rate, crash rate and many more are useful metrics to measure technical improvements by adopting agile technical practices, simply reporting these metrics to management and leadership does not adequately convey the true business value of agile technical practices.
The true business value of agile technical practices is best communicated when agile technical metrics are linked to business metrics such as mean time to resolution (MTTR), conversion rate per session or increased customer engagement / activity.
In this interactive workshop, participants will explore how to improve measuring the business impact of agile technical practices by working in small groups to first identify & prioritize technical metrics for specific technical scenarios. Participants will then be challenged to link technical metrics to business metrics to convey business impacts supported by increased adoption of agile technical practices.
All participants will leave the session having created a sample dashboard that links technical metrics to business metrics so as to demonstrate the true business value of agile technical practices.

Learning Outcomes:

• Participants will review the most common technical metrics used to measure the technical improvements achieved by adopting agile technical practices.
• Participants will review recommended business metrics that are commonly used to demonstrate the true business value of adopting agile technical practices.
• Participants will experience a collaboration framework that guides the selection of both technical and business metrics to assess the technical improvement and business impacts of addressing a specific technical challenge.
• Participants will gain insights on how to measure the technical & business impacts of specific scenarios by working through a specific scenario themselves, and then having an opportunity to see what metrics other groups selected to measure other scenarios.

Attachments:

• BizImpactsOfTechPractices-SessionPacket.pdf
• BizImpactOfTechPractices-FacilitationDeck.pdf

Abstract:
Do you have that piece of code that grows bugs every time you try to change it? Yet, do you find it difficult to fund a repair? Fixing it will take a project, and that one just never makes it to the top of the queue. Or do you spend a lot of time finding others' bugs? Or do others around you always take the safe path, even when there's a better option? Do you get interrupted every sprint by a couple bugs, and so miss the sprint goal?
Safeguarding addresses all of these and more.
Safeguarding is a simple, 22-minute practice that allows you to find, fund, and then execute real changes to your process and product. Fix technical debt this sprint. And next sprint. And the one after. Without slipping features. Fix process debt. Fix psychological safety issues.
In this workshop, you will safeguard a real problem that you are experiencing right now. You'll learn how to facilitate yourself and your team through safeguarding. And you'll learn how to sell this practice to your product owners and managers.
My goal is simple: I want you to go home after the conference and start actually fixing technical debt, start actually preventing bugs. By this time next year, I want you to have less than 5% of your current number of bugs.

Learning Outcomes:

• Can define good remediations, on the basis of a bug, to prevent future bugs.
• Understand hazards and know how to look for them.
• Understand when to safeguard to get the best results.
• Ready to start safeguarding when they get home.

Abstract:
Interest in Functional Programming has exploded in recent years. If you are an experienced OO developer, your design techniques and coding practices can easily get in the way of FP success.I t certainly did for us! Fortunately, there are way to leverage what you already know.
Join Declan and Shawn in this interactive session. Explore the joys and challenges of moving from Object Oriented programming to Functional Programming.

Learning Outcomes:

• principles and practices that work with both FP and OO
• learning path to becoming a better FP developer
• things to watch out for as an OO developer when applying FP
• refactoring techniques to move OO code to an FP style

Attachments:

• Overcoming Dys-Functional Programming .pdf

Abstract:
The goal: Clean Code That Works, and getting there is half the fun. Working with a legacy mess can be frustrating, boring, dangerous, and time-consuming. When FIBS occur (FIBs = Fixes that Introduce Bugs) you often enter an endless Test and Fix cycle that can quickly escalate into a nightmare. I've been there, you've been there. How do we return to pleasant dreams?
In this code-centric mini workshop we'll look at ways to introduce sanity and calmness into the process of maintaining and improving buggy, poorly written, poorly designed code. Few slides, mostly code. I've been fighting the good fight for a long time and we are going to show you how to turn any project around and have fun doing it. It is our opinion that we can fix and enhance any code.
We'll be working on an example project and learn the steps of making changes to code in tiny steps. We'll find ways to clean up the most common problems of duplication, clutter, and complexity.
Our approach will have us using Solo or Pair, and maybe Mob Programming to do exercises and work with others as we experiment with many simple techniques that combine together to make a big impact on the quality and cleanliness of our code.

Learning Outcomes:

• The basic goal is to learn enough about refactoring in baby steps so you can begin doing this immediately. We'll be covering a number of basic refactoring techniques that provide a wide range of easy to implement improvements, and learn how to identify some common code "smells" (symptoms of potential problems)

Attachments:

• PracticalRefactoringHandout.pdf

Abstract:
Given an ancient codebase that makes refactoring risky and expensive, how do you clear a path to continued delivery? The old wisdom says the best time to plant a tree was 20 years ago, and the next best time is today. But if you already have a gnarled old source tree, preserve your software investment by planting a Strangler: a pattern for reaping continuous value from your existing system while growing new functionality alongside it.
We'll take a quick look at a Strangler, demonstrate the basics of Mob Programming, then split into small groups to test-drive new features into the system. You'll leave with a powerful strategy for extending the useful life of working, valuable software -- especially when it's hard to change -- and with a free bonus development practice to accelerate your team's learning. For a limited time only!

Learning Outcomes:

• Form and function of the Strangler pattern
• Contexts where it may be useful
• Coding in a real Strangler
• Challenges of putting the pattern into practice

Abstract:
Most of the writing and examples on serverless application architectures either lack enough detail to understand exactly why serverless has any real advantages over other methods of building software, or is far too in-the-weeds to understand how the particular discussion would be better than an alternate implementation that was not serverless. In this workshop, I will defines and explains how serverless is different from other application architectures, explaining the philosophies and benefits of what good serverless architectures deliver. Then, I will take the participants through each of four different application architectures, taking the time for everyone to pull the git repos and build and run the code, walking through more of the details of the code, and leaving everyone with very concrete examples of the substantial agile benefits of good serverless architectures.

Learning Outcomes:

• - What serverless means
• - What good serverless architectures look like
• - Why serverless architectures deliver better agility to organizations than traditional application architectures

Attachments:

• The Extreme Agility of Serverless Architectures.pdf