It’s surprising how little of the research around incentives has made it into practice. There’s widespread belief that the debate is about carrots vs. sticks or if it’s carrots or sticks, what kind of carrots or sticks. It’s also surprising how the understanding of this fundamental topic eludes many well-respected, experienced practitioners and coaches. There’s considerable research that suggests what incentives work (and don't work) for individuals and teams. Linda will bring in the latest from cognitive neuroscience and help those of us who care about development teams to learn what works best.

Despite thinking that organizations are slow to innovate, innovation actually abounds at many companies. Kodak, DEC, and Xerox did not fail due to lack of new, cutting-edge innovation; they failed because their organizations were tuned to their traditional markets, and a failure to change their business models and organizations led to their eventual disruption.

The key to achieving business agility lies in leadership that transforms organizations. Transformational leaders succeed by changing the system, leading with purpose, and steering from the edges. They own their responsibility and boldly lead their organizations into the future. As leaders, we can accelerate this evolution by enabling true self-management and team-based governance.

Join Bob and Sanjiv to learn how leaders can transform organizations with a flatter organization structure, work anywhere flexibility, participatory profit sharing, and delegated hiring and firing. Explore the agile leadership journey needed for true business agility.

Elevator Pitch

Sometimes teams need more than just questions. They need scrum masters and coaches who are courageous enough to have the hard conversations, challenge their decisions, push them to the next level. During this session we will introduce participants to some anti-patterns that have arisen in the scrum master and agile coaching communities and discuss ways to break free!

Description:

Coaching Agile Teams is all about asking questions and allowing them to self organize, right? Well, that's just part of the mission. During this session we will introduce participants to some anti-patterns that have arisen in the scrum master and agile coaching communities and discuss ways to break free!

Sometimes teams need more than just questions. They need scrum masters and coaches who are courageous enough to have the hard conversations, challenge their decisions, push them to the next level. However, sometimes we push our teams a bit too hard and create negative conflict. It's times like this when we need to demonstrate how to reach out and make the first move to repair the relationship. We will introduce the concept of repair bids to help in this area.

Lastly, we learn a model to put into practice to create a coaching alliance with teams so you can be in agreement on how you will work together for their best interest and improvement over a period of time.

The reason we chose to create this session is that over the past few years we have noticed that as people are learning more about coaching they are getting out of balance and believing that the only thing that coaches are allowed to do is ask questions. We've noticed that scrum masters lean so far in the direction of self organization that they no longer believe they can challenge teams to grow or to move beyond where the team decides to be. We believe that the root of the problem rests in the fact that people are learning a bit about coaching but not actually learning how to be a coach. We would like to introduce to the attendees the more direct coaching methods that are available for use such as 1) direct communication, 2) challenging, 3) courageous questions that push the edge of the comfort zone, etc.

Session is collaborative and includes interaction with the participants throughout. Also has collaborative exercises.

Are you someone who values everyone's contributions in your work environment? Have you ever struggled with how to be an ally for a peer? Do you sometime feel like your perspective is undervalued or underrepresented?

Industry research highlights teams achieve better outcomes when they are diverse and inclusive. This workshop will share what we see happening in the industry, and help participants develop learning strategies and leverages tools that they can bring back into their local environment. Attend this session and you’ll leave with the skills to grow as an ally and ways to foster a more inclusive culture within your organization.

Want to find the perfect Product Owner? It's easy, all you have to do is find one with the time to do the job, the power to make decisions, the knowledge to make smart decisions, the interest in doing the job, and the Vision to build the right product. Easy, right?

Via a story, the session will start by exploring 5 key attributes of being a Product Owner:

1. Bandwidth
2. Power
3. Knowledge
4. Interest
5. Vision

After that discussion, we do an exercise to identify what a Product Owner does day to day. The debrief will identify the balance a Product Owner must have in working with stakeholders, end users, customers AND working with the Scrum team AND product backlog refinement. We will also touch on client/vendor relationships and identify if the PO should come from the client or the vendor (and how technical should the PO be).

The session concludes the attendees being given a Product Owner persona scoring template. The attendees can use this template to score their Product Owners and we will discuss how to identify their Product Owners areas of strength and gaps areas.

Do your teams struggle with silos, multitasking, under performing, and not truly swarming to work with an understanding of shared responsibility

Based on the Swedish public domain game "Yatzy", we turn a familiar roll of the dice into a team building, learning exercise. This game is designed to not just talk, not just show, but to deliver a firsthand experience of what works and what doesn't in terms of incremental delivery.

This game is designed to teach:

• How multitasking costs time & reduces quality
• How silos disrupt the collaborative power of Agile
• When one member of our team under performs, we all underperform
• When we swarm to work, we all individual look better than we ever could on our own
• How working as an Agile team in earnest is addictive & once you go there, you'll never go back

With an array of different flavors, agile has a lot to offer. With Scrum, Kanban, Scrumban, DevOps, XP and everything else in between, organizations today can feel like kids in a candy store picking the right flavor for their teams.

Whatever methodology you might choose or however deep you might be into your agile adaptation journey, your people will play a very important role in making your adaption a success story.Are you or your organization suffering from failed agile transformations or not seeing the results even after following the manual to the T? Instead of blaming the methodology and retrospecting your choice , could you be compromising on one of the basic founding principles of agile: Individuals and Interactions over processes and tools. Specifically- people! You are diverse, but are you inclusive?

Join me as we discuss the power individuals have over anything and everything in agile. Together, we’ll uncover ways in which we can use empathy, inclusion and efficient employment to get the people onboarded onto your change train and make your transformation journey a success story.

In 2001, a group of software developers got together in Snowbird, UT, and created the Agile Manifesto. The Manifesto was a statement of core value and principles. The core values are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

These four values are supplemented by 12 principles of agile software. The original 17 signatories were joined by thousands of additional people with the ability to sign cut off in 2016.

These principles are the foundation of much of the work in agile that has occurred in agile development, but have been mostly frozen as practices and agile has evolved.

Modern Agile has been created recently to update the underlying foundational values and to provide a focus beyond software delivery. Those four values are:

• Make People Awesome
• Deliver Value Continuously
• Make Safety a Prerequisite
• Experience and Learn Rapidly

This talk will walk through this reimagining of the agile values and what they mean for delivery within a government context. We will take each value and look at government cultural and technical challenges and opportunities to advance modern development practices.

When organizations move to agile for software delivery, there is often tension with traditional portfolio management. This talk will illustrate how an organization can move from traditional portfolio management approaches to one that embraces agile software delivery. Doing so enables organizations to become predictable, improve the flow of value delivered, and pivot more quickly if necessary.

We will demonstrate the use of governance that allows a more adaptive portfolio management approach. We will cover topics that enable agile portfolio management including:

• Lean techniques for managing flow
• Effective prioritization techniques
• Long range road-mapping
• Demand management and planning
• Progressively elaborated business cases
• Validation of outcomes
• Support for audit and compliance needs

These topics will be illustrated by real-world examples of portfolio management that have been proven over the last five years with a wide range of clients.

Experience Report: Applying Lean UX to New Hardware Development

We often hear how Agile and Lean UX techniques are applied to software development, but there is much less information available on how to use these same ideas to develop new hardware solutions.

In this experience report, Matthew Maddox, VP of Digital Strategy at Mirion Technologies and Roland Cuellar of Lithespeed will show how Lean UX techniques were successfully applied to the design of new and highly complex integrated hardware and software products.

Mirion makes complex, highly regulated equipment that is focused on radiological safety for national security, first responders, and nuclear power. Mirion’s radiation detection equipment is used to protect people from radiation exposure, secure major events, and track down illicit radiological sources. Over the past year, Mirion has been experimenting with agile and lean UX techniques to design it's next generation radiation detection hardware and software.

In this experience report, we will hear how Matthew utilized rapid, lightweight, lean UX techniques to quickly develop hardware prototypes, gather feedback from past and potential new customers, and quickly pivot initial designs based upon feedback from customers.

As a result of this important process innovation, Mirion is now embracing more modern digital and agile techniques to more quickly bring innovations to market that are more closely aligned with customer desires.

Matthew Madox is the VP of Marketing & Digital Strategy, and lead the field research, primary design and customer validation phases of the next generation Personal Radiation Detector (PRD).

Topics Include: Agile Hardware Design, Lean UX, Hardware and Software Design Integration, New Product Development, Engineering Culture Change

Design Thinking has been developed as an approach to resolve issues outside of professional design practices -business and social contexts are great examples. Since the framework integrates classic creative problem-solving with art and design methodologies, it matured as a flawless and flavorful strategy for innovation.

Nowadays, even large bureaucracies like the Veterans Administration and IBM use Design Thinking to explore the experiences of key stakeholders and search for insights that allow them to improve product, services and processes.

Not every design thinking project is a success, of course, but as a risk management approach, few innovation methodologies compete with this strategy. As companies continue to adopt agile, Design Thinking gains traction as the right tool to create an intimate connection with final users, uncover the true needs and problems, and propose less risky solutions.

In this interactive talk, you will be walked through the 12 steps we followed -for 12 weeks- to understand homelessness, uncover the real issues and propose new concepts. You will be surprised not only by the insights we found but also by the power of the framework. After listening to this real-life, fresh example, you will leave the room looking for opportunities to apply the strategy on a daily basis.

In late 2016, the Nationwide Enterprise Digital group began a lean agile transformation to further improve speed to market and increase flexibility in a highly competitive environment. With the success of the Enterprise Digital transformation, other Nationwide business organizations have begun to adopt many of the lean agile execution practices used by the Digital organization. Besides focusing on how Digital’s successes were harvested and leveraged by other Nationwide groups, this discussion will also address organizational scaling challenges, including the critical role of leadership, need for a consistent vision, metrics in a mixed use environment, and the overwhelming OCM and team coaching needs to complete a transformation at scale. The presentation will conclude with discussion of next steps currently underway in the Enterprise Digital group to complete their lean agile transformation.

Agile methods not only promise us a better way of working, but also a better way of life. Through owning our personal objectives and iterating constantly towards our better selves, we can reap the rewards of agile philosophy in our personal lives.

Enter "Thing Three", an informal peer coaching framework to make personal agile a reality. In this framework, three people, with commitment to the process, hold each other accountable and offer coaching through brief weekly standups. The process includes personal adherence to agile techniques like limiting WIP, and iterating with purpose to ensure focus and progress. Ultimately, Thing Three leads to faster personal achievement, no matter the individual's goal. Plus the journey is so much more enjoyable with others to help you.

We look forward to sharing not only the process of our Thing Three agile peer coaching model, but also tips, tricks, and lessons we have learned over the last year using it. You will leave with the will and skills to use agile peer coaching to achieve your most ambitious goals yet.

Did you know that your brain tells you stories all day long, and that if they are good stories, you believe them? Come to this entertaining interactive session to experience some "cognitive illusions" for yourself, and learn what they demonstrate about how our brains' work. Cognitive science and behavioral psychology offer important insights for agilists, insights that can help us work more effectively with our co-workers and clients. You will learn how awareness of our brains' tendencies is a powerful tool to overcome our own innate cognitive bias, and the cognitive bias of others. This newfound awareness can open you to more varied perspectives in order to tell yourself a story that is both richer and more nuanced -- and closer to being "a true story."

Product Owners have the challenging task of choosing which items their teams should focus on next. By combining their experience, conversations, and intuition, they often have to make decisions based on a set of imperfect data, which is hard to do. Adding to this, that they may have to justify their reasoning, making the task of prioritizing even more difficult.

In this workshop, participants will explore the Kano Model, an approach that takes into account satisfaction, functionality, and categorization to best identify the most important things based on customer response. This model gives Product Owners real data and insights to aid their decision making process, vastly improving on "this is important because I said so!"

In our follow-up session to last year’s Kanban in Action: Thoughtfully Observing Flow, we are excited to bring our newest installment of the series: Kanban in Action: Thoughtfully Creating and Discussing Flow.

This session puts the attendee in the driver’s seat to create their own Kanban board configurations. We provide seven business scenario exercises and ask the attendees how they would go about configuring their Kanban board given the unique constraints of each scenario. Each team/table in the room will spend a few minutes discussing how they would configure their board using the provided flip charts, markers, and stickies. A debrief with the entire room follows as each team shares its concepts. The instructors will also share their own board configurations and ideas.

These exercises will increase your understanding of Kanban systems, give you practice interpreting and creating board configurations, present multiple implementable ideas for any given scenario, and provide you with approaches for meaningful engagement. They are great for aspiring coaches, managers, and leaders who want to have more valuable conversations with their teams and improve Kanban implementations.

You recently completed a two-day training, and you are now a Certified ScrumMaster. There's only one problem: what do you actually do next?

Part of the genius of the Agile Manifesto is that it doesn't tell you exactly what to do. It gives you a resilient foundation of values and principles that is grounded in discovered truths, and then lets you figure out how to apply it. Scrum describes process a bit more, but still leaves a lot of open questions. Again, this room to adapt is incredibly powerful. However, at the outset it can be quite daunting. Even after going through Certified ScrumMaster training, new practitioners may be a little lost as to what exactly to do next.

Over the years, I've built up a set of simple, concrete practices that I use both to get teams started and to help existing teams that are having trouble. Recently, I helped three teams get up to speed in quick succession. I wrote down these practices as a playbook. While I look forward to the day when these teams grow beyond my playbook and throw it in the trash, I have seen great results from starting with a small set of concrete practices. Come to this session and walk out with simple, specific things you can do to get your team flying.

Our industry exploded with tons of newly certified scrum masters. HR folks go through 50+ applicants to find a good scrum master. New Scrum Masters are challenged gaining experience to help them get a job and/or improve their abilities. How can we help new scrum masters become great and how can we help HR find them?

Join Joanne to review new approaches to interviewing scrum masters (any scrum team member) utilizing experientially based questions. Explore how as a community we are able to grow scrum masters and agile coaches internally and externally in our companies.

Let's disrupt the way we do things traditionally - the world is changing faster than our traditions.

Getting applications into production these days has never been easier. If you want to get a proof-of-concept or a small app deployed quickly, you can use containers and some of the latest cloud platforms such as Heroku, AWS with Elastic Beanskalk and Good Cloud Platform quickly and easily. Vic will give live demos of doing just that by deploying a simple chat applications to the cloud. Instead of talking about different ways that we can do that, we will do it live, and showcase some platforms that are available to make our deployments easier. We will go over deploying an app using the Heroku platform, Amazon Web Services using Elastic Beanstalk, and using Docker and Google Cloud Platform, while highlighting and comparing the benefits of each provider.

Want to help your data and analytics teams embrace Agile but don’t know where to start? Wondering why your data team seems to struggle with creating manageable yet valuable stories? Curious why we think Agile for data teams is a distinct challenge?

Data work is often structured more like a pyramid than the familiar “layer cake” metaphor due to the state of data infrastructure technology, common industry practices, and the heavy lift to integrate data before it can be analyzed and visualized. Prevailing Agile wisdom of cutting work into “vertical slices” thus presents significant challenges for Agilists working on data teams! Typical full-stack vertical stories in this environment can easily become too complex, interdependent, and unwieldy to fit into fixed-length sprints. Technical stories can encapsulate smaller work increments but risk becoming too abstracted from the customer’s core problems and trap the team in infrastructure work for too long. An additional impediment to traditional user stories is the highly exploratory nature of advanced analytics and data science projects where in many cases end users lack awareness of what kind of problems can even be solved and technical experts can’t initially predict which solutions will actually be possible.

This session presents successes and lessons learned from applying alternative story decomposition and writing techniques on several data products across multiple teams. Returning to one of the fundamentals of what makes Agile valuable, namely to obtain feedback on feasibility and end user value as quickly and systematically as possible, our approaches strive to ensure teams have small, independent stories while still maintaining a value focus. We discuss ways to decouple the technical stack through stubbing and gradual tightening of the Definition of Done. This technique accommodates the necessary foundational work in the background while also obtaining early feedback about the value of the eventual product delivery options. A second approach incorporates Lean Startup concepts and centers on replacing traditional user stories with testable hypothesis statements that allow for explicit experimentation and risk trade-offs towards relevant milestones such as model quality, performance, predictive reliability, etc. in the context of extreme uncertainty.

Join us as we discuss some of the friction Agilists can encounter on data teams, as well as some validated ideas for meaningful solutions.

Hurricanes Harvey, Irma and Maria left a wake of catastrophic damage in 2017 and overwhelmed all regular forms of assistance.

Individuals and grassroots movements stepped up to fill the gap. Largely unknown people helped other people, neighbors helped neighbors, and all of it used crowdsourcing with methods known as Scrum, Kanban or Scrumban, even when the individuals didn't understand what they were using.

Listen to the story of how an agile coach became part of the response and started a movement to help bring comfort and joy back to over 150 families in the Keys when they needed it most. More importantly, learn how you can use shared common purposes, agile values, principles and methods to do the same for any crisis that might come your way.

In this lightning talk, we explore the 5 attributes to look for in a ScrumMaster:

• Knowledge - Deep knowledge in Agile and Scrum
• Experience - Deep experience with Scrum teams and in Agile environments
• Coaching - Deep understanding of Coaching concepts and techniques
• Facilitation - Deep understanding of Facilitation concepts and techniques
• Servant Leadership - Deep understanding and desire to enable success for the teams and the organization

From there we look at the ScrumMaster's progression for removing impediments and addressing issues:

• Did we talk about it in the Retrospective?
• Did we discuss the impact?
• Did we identify root causes?
• Did we come up with solutions?
• Have we tried the solutions?
• What were the initial results?
• What are next steps from here?

We use the steps above to ensure:

• Our teams are not making the same mistakes time time after time
• Our teams are not having the same issues arise time and time again
• Our teams are not stagnating but rather are getting better over time

This session will arm session attendees with what to look for in a ScrumMaster and discuss how the SM uses the impediment progression to ensure we have a continuously improving team.

You don't need complex metrics that are onerous to track and analyze to drive continuous improvement. Lets look at 6 metrics that are easy for any team to use to accelerate their progress to being a high performing team.

Does your team have a "me first" mentality? Are people so focused on getting their own work done, their tickets closed and moved to the right, that they seldom look up to see what is happening with others? What about your division--do teams appear to be siloed, concerned about only themselves, not looking around to see how their work affects others? Let's change this!

Collaboration is not just working together. We can achieve real collaboration, the type where we inspire one another, challenge the way we work through problems and tackle work, do the things that scare us by making selflessness a daily practice. By making questions of "What did you do to help another person or team?" or "What did someone do to that really made a difference in how you worked?" into our retrospectives and mindset, we can build selflessness into the very fabric of the team. By bringing selflessness to the forefront and making it a talked-about, key ingredient to how our teams function, we can go from wishing for more opportunities to work together to achieving true collaboration.

What would you do if you overhear negative conversations about change in your organization?

We are starting a movement to switch conversations, about change, from negative to hopeful, by acting in the moment. We will teach you a simple technique*, called “The Elevator Switch”, to help you further transformational changes within your organization.

*Elevator not required to use this technique

“The single biggest failure of leadership is to treat adaptive challenges like technical problems.” -Ron Heifetz

We live and work in an increasingly interconnected and rapidly changing world. New business models are shifting duties to teams instead of individuals, which means people are now working more closely together. It also means leaders at all levels have to begin to adapt their leadership style to guide the intricacies of human dynamics and channel the collective knowledge of the groups they interact with.

In this workshop we will explore how leaders create environments that navigate the complexity of interpersonal relationships, overcome the human element of barriers to change, and support the growth and engagement of their employees. Attendees will walk out of the room with a clearer idea of their own leadership style and a list of action items they can use (tomorrow!) to move their teams one step closer to higher performance.

Agility is about adaptation, challenging the status quo, experimentation and learning. HR has historically hewed closer to compliance, but that has been changing rapidly.

Today's nimble teams and workers will no longer tolerate stifling, staid environments and management practices. The newly popular label "people operations" implies an emphasis on human engagement over bureaucracy and regulation, and indeed many organizations have been moving this way.

Be inspired by some of the most daring advances in human resources while also learning some practical approaches and techniques that can be applied to start leading your business down this path. We'll discuss new approaches in hiring, performance management, learning and development, and even the structure of HR groups and roles. Participants will also enjoy a few exercises that will illustrate some interesting techniques.

Prepare yourself for HR in the next generation.

Building new scrum teams with driven, smart people can jump start a team’s success, but more often than not, scrum masters “inherit” established teams who may need a kick start.

In this workshop, we will discuss Stephen Covey’s Four Disciplines of Execution and how teams can use them to set and achieve goals. It’s a simple framework that distills the simplicity of the Scrum framework to its most essential parts, and refocuses and re-energizes teams to achieve their full potential.

The disciplines of execution –

• Focusing on a wildly important goal
• Acting on lead measures
• Keeping a compelling scoreboard to engage the team, and
• Creating a cadence of accountability

- can help teams improve and focus on the fundamentals of scrum.

Many software developers (especially in larger organizations) are unhappy in their jobs. They are in a never-ending spiral of increasing code cruft, and their management does not allow them time to remediate technical debt or keep the code base clean. They feel helpless, beaten-down, defeated. They can't imagine that improvement is even possible. They respond to any suggestion to improve the status quo with comments like, "In an ideal world, maybe," "That will never work here," "You don't live in the Real World®," etc. They don't know their own power. This session is meant to show them that power.

Elevator Pitch:

Agile Transformation is harder than it needs to be because we often find ways to consciously or subconsciously sabotage our efforts if we can recognize this behavior it is possible to intervene and make a change for the positive.

Abstract:

Have you ever been on a project where it seems like team members are preventing the team from getting better? Why do they do that? I don’t know either- a psychologist might have to answer that. What I can tell you about is my experiences in seeing teams become their own worst enemies and unwittingly sabotaging the projects they are trying to make successful. My goal is to help you realize when you or those around you are behaving in a way that is going to lead the team plateauing or even failing. I have often found that many teams can get stuck, or plateau, at a certain point along the continuum of agile maturity. These teams can meander around without getting better or even changing anything for long stretches of time. I have also worked with teams that put so many hurdles in their own way that they had no option but to fail. They often fell back into old patterns and gave up hope that things can get better. As an Agile Coach, I have often felt that one of the most valuable things I can share with the people I coach are my failures. I have worked on Agile projects for a long time, and I have failed in many different ways. Having been through failure, I have learned that to keep getting better you have to recognize the things that you do that lead to plateaus and failures to overcome them. This talk is for coaches and team leads who want to make sure their team isn't getting stuck in a rut, or who are trying to get out of a rut with their health and sanity intact.

Failure signs and examples

No process is defined and followed

• ex. Projects that claim to be agile without any experience or training, or doesn’t have basic agile practices such as retrospectives, I.e. we are agile because we have hour long daily standup meetings.

Process practices are ignored or removed with no compensating practices

• ex. Agile practices hold each other together, supporting each other by the value they bring to the project, some teams decide to not do some practices without doing something else to get that value, for instance pair programming provides code review and knowledge transfer, many teams don’t pair program and don’t do code reviews and or knowledge transfer.

Automation is not valued or planned into work

• ex. We will automate tests later. Often that later never comes and the team is left with a code base that is hard to maintain and change because you don’t know what your changes break.

No stakeholder expectations management

• ex. The only way a project can negotiate scope and or schedule is to actively manage stakeholder expectations. An example of unmanaged expectations is the PO that never says no to a feature request or the executive that decides what must to delivered and when it must be delivered.

Quality and testing practices are an after thought or short changed on schedule

• ex. Teams that don’t complete sprint commitments because the testers get coded stories too late in a sprint to do all the required testing and the rest of the team isn’t held responsible to help test.

No negotiation allowed in deliverables and or schedule

• ex. Executives that dictate all of the terms of a project before a team is even selected.

The team doing the work didn’t estimate the work but are held to an estimate

• Many government projects have such a long procurement cycle that no one from the proposal team is put on the project.

Part time team members are in the critical path

• ex. Sometimes people with special skills are needed for a part of a project. If the person is part time but their work is in the critical path the project is in trouble.

Heavy team turn over

• ex. Heavy turn over is a sign of a project that isn’t on track, even if it hits its deadlines the quality and output will suffer.

Political motivations more important than team’s ability to do work

• ex. If the team is setup to fail for reasons outside the team, they will most likely fail.

Distraction from issues outside the work that needs to be done

• ex. Scrum Masters that don’t shield the team from issues outside the work that needs to be done during a sprint will end up with a team that doesn’t hit the mark.

Examples of what can be done to avoid failed projects:

Focus on shielding the team from outside influence

• Have the team focus on the things they can control and prevent outside issues from distracting the team.

Negotiate delivery with the team

• The team can develop an understanding of what it can deliver. Trying to make the team do more is going to lower quality and potentially make the project take longer.

Management of stakeholder expectations

• Stakeholders always want more, that is their job. Let them ask for anything but set their expectations on what is really going to happen.

Focus on technical excellence, quality, and automation

• If you want your teams to get better, have them focus internally on things they can control like technical aspects of the project including quality and automation.

Hire motivated team members and make it possible for them to work

• People who care about what they are doing will always be better than the cheapest people that don’t care. Hire people who care.

Maintain a progressive planning pace for getting requirements ready

• Agile requires planning at different levels, skipping a level for any reason means there are going to be disconnects between your stakeholders and the people doing the work. Disconnects means the project will not product the results you want.

I often suggest to teams that they should be using all sorts of tools in their pipelines- from simple static analysis checks and automated builds to security scans and performance testing. I've done presentations and talks at conferences. I've lobbied to clients. I've commiserated with my colleagues. But I've never put together my dream pipeline in one of my own projects.

There are always reasons that some tests and tools get left out- our policies won't allow them, they will take too long to get approved, we don't have time, we have bigger problems to deal with, it just isn't what the client is looking for right now. And I usually think, if only I were in charge, I'd make sure we were using those...

In late 2017 I took over maintenance on an open-source project. Now I have no restrictions. The sky's the limit. No one is around to tell me what I can't do. So why don't I have my dream pipeline in place yet?

I'll talk about the trade-offs and compromises I made when building out the pipeline. Why I decided to focus on some tools and tests but skipped others, and what I need to do or change to make this delivery process the pipeline I've always dreamed about, now that I have no one else to blame.

Sometimes, teams are faced with projects that don't align with Scrum or the Agile Guides. Whether because of organizational restrictions, or unique circumstances of the project, teams sometimes need to improvise in order to deliver. In this talk, Dave Pradko talks about a custom agile approach developed for a government agency.

Think of a time when multiple contributors were all working in the same area of code at once. Ever wish there was an easy way to resolve those inevitable merge conflicts? This certainly happened for us while contributing to the pgAdmin 4 open source project. As evangelists from Pivotal, Matt Kleiman and team contributed all of their patches to pgAdmin 4 using test-driven development. Attend his talk to learn the virtues of testing and the story of trying to bring test-driven development to an existing open source community. He will walk through an example of how Pivotal extracted existing, untested code and wrapped them in tests in order to benefit the entire community.

Are you “going Agile” but your executives are still asking you for Gantt charts and delivery dates? Here’s an exercise to do with them instead. Usually, they just want to know when to check back on “the project”, and whether or not their money is being well invested.

To answer the last question, many teams have discovered the “Weighted, Shortest Job First (WSJF)” method of project prioritization. Basically, if you have two items of equal effort, but one has twice the return on investment (ROI) of the other, do the one with greater ROI. And if you have two items of equal ROI, but one can be done in half the time, do the shortest job first. But that’s not enough. We all know of projects that had great promise, but customers wouldn’t pay for it.

Lean Startup has discovered that emotions are one of the best leading indicators (predictors) of future product success. Emotional-WSJF (eWSJF) balances customer demand with Minimum Viable Products (MVPs), i.e. "this only has true business value if we can deliver within 2-3 sprints."

I use eWSJF within my teams to prioritize Epics, and I’ll show you how to use it to keep your executives happy! It replaces the conversations about “Show me a Gantt chart,” and “When will this be delivered?” My executives instead ask, “Have you talked to any customers?” or “Can you build it faster?” To which my teams respond, “Yes we have talked to customers, and they’re even helping us beta test it!” and, “The next version will be delivered in two weeks, and here’s what it contains.”

“Test-driven development (TDD) is a programming technique in which the tests are written prior to the source code. It is proposed that TDD is one of the most fundamental practices enabling the development of software in an agile and iterative manner. Both the literature and practice suggest that TDD practice yields several benefits. Essentially, it is claimed that TDD leads to an improved software design, which has a dramatic impact on the maintainability and further development of the system.” (Reference: ieee.org)

Fannie Mae, a government sponsored entity (GSE), is in the fourth year of it’s agile transformation. Teams use an Agile Maturity Matrix as a roadmap for optimizing their agile capabilities as well as technical engineering practices.

As long-standing teams, we have a long track record of trying to incorporate persistent TDD practices with varying degrees of success. But it was only after the LDNG teams collectively matured their agile mindset and focused on optimization, implementation of TDD took flight.

Past year, 4 teams comprising the Loan Delivery Next Gen were recognized for being the first teams in organization to complete highest agile maturity model’s category, hallmarks for which include: Feature level BDD, Test first mindset & All layers of testing are automated and executed on every check-in.

• Do you want a real world example of implementing TDD in a large program?
• Are you unable to grapple with the challenges of TDD? Is TDD frustrating you?
• What are some misconceptions about implementing TDD?
• How do you get a good ROI (Return On Investment) by developing TDD capability?
• By the way what’s the big deal about TDD? Is it really helping or just another hype??

This talk is intended for the technical members on a cross-functional team (responsible for the “how” who are faced with implementing TDD) as well as well as Scrum Masters and Product Owners who are interested in understanding the benefits of TDD and why they should be advocating for / insuring there is capacity to develop and mature these practices as part of the team’s work. Unlike most TDD training sessions, this focuses on the subtleties and challenges of implementing TDD in a pragmatic manner that address everyday concerns of a large organization.

Join us to get answers to all these questions based on our real world experience as well as see a live intuitive demo.

While we are not experts in this field (at least not yet), we will share our journey and practical learnings. How does that sound?

Our presentation shares experience of Loan Delivery teams. We will share our journey in adopting TDD along with moving away from testers in team, to training developers with test-first mindset. We will also cover misconceptions and touch a little on testing techniques for developers. We would like to cover the non-technical blind spots that most TDD trainings might miss, based on our real world experience.

Also in the spirit of Agile, we will present practical real-time example of TDD in action that addresses a number of concerns, but mainly how to re-factor code using TDD. We will use personal laptop to demonstrate a loan calculator example.

Retrospectives are not just about making you feel bad for missing your commitments, pointing fingers at your colleagues, and hearing your talkative team members go on and on. They are supposed to help your team become great. This workshop is for anyone that participates in retrospectives, doesn’t always feel they are useful and wants to learn a better way to accomplish the intended goal.

We will explore several different topics to help revive retros such as:

• Understanding people's perspectives to retros
• The psychology of blame
• Looking for what is working in the team
• Problem solving strategies
• Getting the team's feelings out on the table
• Understand team perceptions
• Using data to determine the way forward
• Improving team interactions in a remote environment

Writing good acceptance criteria is key to effective software delivery. But, it can be difficult. This session introduces participants to Example Mapping, a low-tech, no-fuss technique that harnesses the power of collaboration to help teams dramatically improve their story refinement conversations and write higher quality acceptance criteria more easily.

With the increased adoption of BDD tools such as Cucumber and SpecFlow, more and more teams are beginning to use the well-known Given-When-Then format for expressing story acceptance criteria. But, not everyone finds the Given-When-Then format easy or natural. It is prone to misuse, especially in the hands of those new to BDD.

Example Mapping provides a structured approach to help teams tease out the essential business rules and examples that clarify a user story and improve shared understanding of story “doneness”. Acceptance criteria that the business can relate to, that can then be automated.

Experience this technique in this workshop, and perhaps you too can use it to sharpen the conversation that clarifies and confirms acceptance criteria, before you pull a user story into development.

Agile transformation can be a daunting yet very rewarding endeavor. Organizations are adopting Agile principles beyond their traditional software teams and looking for benefits in other areas across the value stream. This includes changes not only in engineering and how we build and deliver products but in other organizational areas such as management, procurement, leadership, human resources, or any area of the organization that is part of the delivery pipeline. Organizations are making great strides in their agile journey yet there are challenges and barriers to overcome as an organization’s beliefs, practices, and culture slowly change. Yet change does not happen overnight. Changing how we’ve done business for many decades can create feelings of fear and a sense of uncertainty for people. What can be done to help overcome these barriers of fear, uncertainty, unfamiliarity, and in some cases, inertia? What are some techniques that can be used to develop an agile mindset and make the shift to further adoption? In this talk we will discuss the importance of Agile across the enterprise and provide some examples from those who have gone “full agile” adopting it within their various functional groups and within any environment. Additional resources and references will be provided for those seeking to make a difference within their team, program, or organization.

Ever struggled to define what is minimally necessary? Whether it is defining a Minimally Viable Product or what is minimally necessary for a project or team, you need a way to not only brainstorm ideas, but also a way to cut the unnecessary waste out.

Pass to Perfection is a game for getting a solution, product, or project started with what is minimally necessary; in development terms, this is your Minimal Viable Product (MVP). It mashes up ‘Yes and’ thinking for co-creation, and the essence of The Perfection Game (from the Core Protocols) for negotiation and prioritization in a collaborative round-robin game format. Create ideas until you can’t think of anything else and you pass, remove ideas until you have what is essential and you pass. This workshop will have you try out the game and learn how easy it is to get people started.

Is it possible to deliver software improvements faster and with better quality in a highly regulated environment? What if the organization only uses off-the-shelf commercial packages like SAP rather than custom software? Oh, and much of the team is still learning the ropes? And by the way, our business users are unavailable during monthly and quarterly close, and to top it all off whole divisions go off-line for weeks or months at a time during refinery “turnaround” events? How can we improve cycle times, if it sometimes takes us months just to figure out how to design a solution for a single request?

In this session, we will examine a case study at an energy company that needed to increase their speed of delivery and their level of quality, while at the same time controlling costs. They started to adopt Kanban a year ago, by visualizing their waterfall process on a board and holding a daily stand-up. However, cycle times were still unacceptably long, and the board did not change much day-by-day. Worse, the business was getting more impatient and the backlog of urgent requests was growing longer. The team was ready to take the next step and deepen their kanban implementation.

We will examine a number of improvements that were made and the impact of each one of them. Larger work items were broken down into user stories, enabling progress to be tracked at a more granular level and helping the team to break down difficult problems into smaller, bite-sized chunks. Defects were captured individually on the board so large items did not appear to “stall” for no reason. Time-boxed “Spikes” could be created to capture efforts required to identify alternatives and reduce risk in design or implementation. The kanban boards went through multiple iterations as we updated them to better reflect our new process.

Hand-in-hand with these improvements came training and practice. How do we create properly formed user stories? When is it appropriate to create a Spike? How can we make process policies explicit—especially the Definition of Ready and Definition of Done?

Perhaps the biggest change for any team moving away from waterfall is the difference in the way team members interact with each other. Analysts and developers used to formal, defined handoffs gradually learned to work together more closely during all phases of a work item—from cradle to grave. Introducing this new way of working together exposed many concerns and biases, most of which have roots in the very different ways that analysts and developers think and see the world. We will review this phenomenon and talk about different techniques and approaches to help mitigate concerns and move forward.

Come join us for a stimulating, thoughtful conversation about one Fortune 200 company’s journey towards a deeper and more complete implementation of Kanban. Perhaps the “alternative path to agility” is right for your organization?

Change is inevitable. In this talk we will discuss the four facets of change that are constantly affecting us: changing products, changing priorities, changing people and changing process. We will look at where these changes comes from, the impacts they have on us and explore concrete tools we can use to get better at responding to them. Attendees of this session will leave with a new attitude on the churn that takes place around us everyday. They will learn to acknowledge the benefits that changes have so they can truly welcome it into their team, their practices, and their life.

The Triple Track Method

This talk is for Agile teams delivering using the Scrum framework

Who desire to put the customer as the central force in maximizing product value but struggle to do this in the midst of an intense focus solely on delivery of feature after feature

Unlike maximizing how many features are shipped by a certain date in a certain budget with limited customer engagement or having separate teams gather customer insights for the Agile delivery teams

The discussed approach focuses Agile teams on maximizing a positive customer behavior outcome and the resulting business impact through direct customer interaction throughout the delivery cycle

This results in moving the team towards a collective product ownership mindset, bringing the team and the customer together to achieve optimal outcomes.

You have a golden gem of an activity. There's a brand new project and your project sponsor says "I want to do some DevOps on our new Agile project!" Sigh. You respond with "Well, how about this? Let's BE Agile and adopt a DevOps approach to structuring our teams, designing our architecture, and leveraging automation to rapidly deliver value to our customers." There. At least we've set the mood.

Regardless, greenfield projects provide a unique opportunity for us as DevOps professionals. You don't have the established baggage of a legacy project. The project is probably open to modern tools and architectures. The project is trying to set up team structure that will have the right skill sets.

The problem is: where you do you actually start with greenfield projects? When we introduce DevOps to an existing project (brownfield) we have a unique set of challenges and we can prioritize where to start based on our biggest problems. What do you do when you have a blank page? "Do everything!" Well, what actually makes up "everything" and where do we start?

Putting a solid DevOps solution in place involves some key things. You can follow the religion of the "Three Ways of DevOps" (fast delivery, fast feedback, constant learning) made popular by Gene Kim, but you still have to start somewhere. In this talk, I'll provide a pragmatic formula to setting up well-integrated teams, establishing a DevOps platform, organically growing an initial DevOps pipeline with continuous integration and continuous delivery, establishing some (useful) standards, and guiding the system architecture to support rapid build, deployment, and testing.

By day I'm an Agile Coaching and trainer, but in my volunteer time I'm an EMT and run a Search and Rescue Squad. Very differnt worlds, but they both involve getting large numbers of people to work together in teams in rapidly changing situations, with limited information, in a high stakes environment.

This talk shows how I used my knowledge as an Agile Coach and ScrumMaster in a situation well beyond IT. We will talk about how Agile/Scrum concepts like breaking work down into smaller increments, using self-organizing team, frequent planning, and retrospectives all are being used in the emergency services field. We also explore how agile principles are incorporated into the cultural aspects of volunteer emergency services -- often thought of as hierarchical and command-and-control, there is actually a culture of of self-organization, decentralized decision making, outcome-based focus, andholding each other accountable -- and it illustrates the underlying cultural principles that are the heart of agile which holds teams together and form high-performing teams that apply in product and software development teams as well.

This fun and fast paced talk walks the participants how a high-urgency search for a missing child is run using agile principles and relates each practice back to a similar approach in Agile/Scrum in the product development world.

We all know the story of how the Agile ‘Software Development’ Manifesto emerged out of Snowbird in February of 2001. And we all know that Agile is still the current best practice for software development. What remains to be fully realized is that Agile has evolved to a best practice for business in general; a way of life for that matter.

I had the privilege of bringing Agile into business over the last couple years. In that time, I introduced my executive leadership team to Business Agility. After getting executive participation in the inaugural Business Agility conference in Feb 2017, we partnered together to seek the benefits of a comprehensive Business Agility adoption.

Using our corporation’s strategic planning and execution effort to exemplify, I will share with you how the Agile mindset and practices apply to business and drive the highest impact possible towards the most valuable goals and initiatives. Modern leadership and business practices such as those under the Business Agility umbrella bring a value-driven, data-driven, efficient focus on impactful delivery.

• Revenue and growth accelerate as we focus the company’s resources on delivering in the most valuable way
• Corporate processes lean out as we remove wasteful bottlenecks, saving money, time, and providing competitive advantage
• Employees are more capable as corporate practices are more meaningful and less taxing
• Back-office tools and data are integrated into a unified experience allowing real-time awareness and predictive analytics, increasing effective decision-making and enabling empowerment at lower levels
• Employees are happier. Customers are happier. The corporate bottom-line reflects this happiness.

I am enthusiastic about the spread of Agile beyond IT. And as such, I am excited to illustrate the brilliance of Business Agility to session participants, adding examples from my most recent corporate transformation effort to exemplify the mindset and practices presented. It is my interest that participants come away with an understanding of how Agile mindset and practices benefit the corporate back office as much as they do software delivery, and how their companies can begin to benefit too by applying what they learn from this presentation.

A well-defined Software Development Life Cycle (SDLC) is a requirement for many government institutions. However, the typical SDLC process is very "Waterfallish" by nature of it's phase gates and documentation requirements. This talk will explain how the SDLC at Fannie Mae has evolved as the company has transformed from a Waterfall to a lean Agile organization in alignment with Agile best practices.

This game lets players experience the burden of being a Product Owner, backlog management and having to choose between stakeholders. Players will form a team responsible for everything related to coffee and will try to create as much business value as possible for their organization while keeping stakeholders happy.

Are you involved with teams? Want to be able to shape team dynamics toward more productive outcomes?

Come dive below the surface of personalities and words to discover the perspectives that shape them.

We’ll learn together and from each other through facilitated hands-on experiences.

You will be able to apply what you learn immediately and directly to improving the quality of interactions.

The efforts of teams is widely regarded to be a competitive differentiator. Being a member of a high-performing team is often reported as a life high point by those who experience it. All around us there is a growing emphasis on teams and teamwork.

Yet effective teams remain elusive. More often groups of people who come together simply cooperate rather than collaborate. They avoid productive conflict, instead engaging in counterproductive discourse.

We can do better. As coaches, we can learn how to read the underlying dynamics that drive team behavior. To enable them to understand what drives their interactions (hint, it’s not the individuals!).

Facilitators will guide the group through a series of experiential activities to teach David Kantor’s Four Player Model and David Kolb’s Experiential Learning Model. Both models are robust and have been thoroughly researched and widely applied.

This may very well be the answer to getting your stuck teams to move beyond their perceived issues toward collaboration and creativity!

You are a passionate and a dedicated Agilist. You have heard that in order to truly empower and motivate Agile teams and individuals, you might need to learn how to function as an Agile coach, but you are not sure where to start. What does Agile coach do exactly? What is the difference between a Scrum Master and an Agile coach? How can you elevate your coaching skills? And how can you become an Agile coach when you grow up?

Join us to learn how to grow your coaching competencies, differentiate yourself among your peers and take performance of your teams to the next level. I will be sharing the story of my own journey from being a Scrum Master to being an Agile Coach and what I learned along the way.

The speaker is a ICAgile Certified Professional in Agile Coaching (ICP-ACC) and Agile Team Facilitation (ICP-ATF), an ACC (Associate Certified Coach), a Certified Professional Facilitator (CPF), and a graduate of Georgetown University Leadership Coaching program.

Is your team constantly missing delivery dates? Is the velocity decreasing from sprint to sprint while the development costs are rising? Are customers complaining about the increasing number of bugs and the long time it takes to add new features? These are all signs that you are mired in technical debt and probably on your way to bankruptcy or a complete system rewrite. Technical debt is inevitable, whether intentional or unintentional. However, not managing technical debt can paralyze your organization. Fadi Stephan expands on the technical debt metaphor and introduces a technical debt management plan that enables executives and teams to make prudent decisions on code quality and technical debt. Come learn how to measure the quality of your code base and determine the amount of your debt.

Where do you stand? Do you just walk in a room and trust everyone? Or, are you a healthy skeptic and you start at a zero trust position?

We talk about trust a lot with regards to adopting agile and Scrum practices. We talk about having courage, taking risks, and learning from failure. This is really easy to say, and hard to do in some environments -- trust may be damaged or doesn't exist at all.

Attend this session if you want to learn the mind science of trust, a look at the impact of trust on the Scrum team, and talk about a framework to assess and actively address building trust.

The common advice for a distributed agile team is, “Don’t do that!” And, we know that at least half of all agile teams are distributed. The common advice isn’t working or useful.

However, many distributed teams have problems using agile approaches. Too often, they don't understand how to adapt to this very different environment. In this talk, Mark Kilby will walk you through eight elements of successful distributed agile teams, and how you might take small steps and giant leaps to increase your team’s success.

You've heard all about how TDD will solve all your problems on a software project. Your defects go away, your time to market decreases, customer satisfaction goest through the roof. Everything is supposed to be awesome if your team just did TDD. However every time you try to adopt it, the adoption fails. Why? Let's explore why TDD is so hard for teams to adopt and find an alternative approach to either adopting it, or getting its benefits.

Agile Quality Management (AQM) at Sevatec was born out of a need for the quality department to add value to our organization. Sevatec is a contractor to the Federal Government with specialties in Agile, DevSecOps, Cloud Solutions, Data Storage and Cyber Security. The hypothesis was that we could meet and exceed all of our industry standard quality objectives through adopting an agile mindset tied to modern leadership practices.

Prior to the creation of the AQM office, Quality was driven by a single person behind a desk. There was no collaboration and the focus was on checking the box for the sake of maintaining quality designations. Data showed that there was little to no improvement as a result.

Our new approach to quality derived from implementing business agility practices, with the belief that our ISO and CMMI requirements will be met and exceeded through the holistic application of agile principles. This provided an added value to the company, in that quality is baked in to every aspect rather than being led by someone sitting behind a desk churning out excessive documentation. Typically, discussions of quality in the agile environment are tied to code, but in our experiment, quality was embedded into all aspects of the organization, not just service delivery.

Ultimately, our auditors spent more time asking us about our AQM approach than actually auditing us and were very impressed with the people, processes and tools we adopted. We believe that our holistic view of business agility will set us apart in the marketplace and drive our organization to its next level of excellent quality, in which all aspects of the business are operating in a lean, agile manner. Our focus on experimentation and continuous improvement lends itself to a fun, collaborative environment in which learning is expected, play is encouraged and quality is an outflow of our working culture.

The federal government loves modernizing software systems and it isn't wrong: stale, decaying software leads to major headaches and eventual catastrophe. Modernization efforts, however, have big risks and big failures.

There is an alternative: software renovation. That is improving, updating, and upgrading the software system one piece at a time while it continues to operate.

Dane has participated deeply in three US government modernization projects. Each project followed a pattern of pitfalls, scary "go-live" transitions, and unpleasant trade-offs.

Renovating legacy software is frequently a better option. The software system continues to gain functionality at the same time that its design and performance are improved.

I spent January in Antarctica hanging out with penguins, whales, and seals. It was about as different from my day-to-day work as can be. And yet, on my long flight home, I couldn’t help but reflect on how well my trip aligned with one specific value of the Agile Manifesto: “Responding to change over following a plan.”

Antarctica is a place that truly drives home why we need both planning AND, even more importantly, the ability to respond to change. This trip helped me fully appreciate how true this value is - and not just in software development. And after being stuck in Antarctica six days longer than planned, it also built up my empathy for team members struggling with dynamic situations!

Creating systems that accommodate users with disabilities is a requirement of all federal agencies, as indicated by the Americans with Disabilities Act, Section 508. But, it’s not just a federal concern, but instead a challenge for all organizations that seek an inclusive experience for their customers, patrons, or constituents. In the process of moving to agile development models, often times accessibility testing can be forgotten or overlooked. This can result in non-compliant code being pushed to production and a remediation plan that batches Section 508 fixes in a later release. This creates a frustrating experience for users who need accessibility features to access content and complete functions. United States Citizenship and Immigration Services recognized this problem early. They have been taking a multi-pronged approach to ensure their systems provide a high quality user experience for everyone. Come hear about some of their methods.

Are you daunted by the prospect of introducing automated testing to a code base without it? Does your code base have automated unit tests, but no one has confidence about what the tests say about code? Consider approval tests to confront these challenges. Approval tests simplify assessing the behavior of a system by taking a snapshot of the results, and confirming that they have not changed. They are useful for both bootstrapping testing automation and for creating more expressive tests. In this session participants will join in hands on exercises using LEGO bricks that illustrate the concept of approval tests, and will share the results of a case study where the approach was used to improve software testing.

This session looks at four team-based improv & collaboration games that help teams embrace "failing successfully." Rather than glorify failure, we should understand that its power is not in failing alone, but rather the learning that emerges from it and the power that such learning has to unlock otherwise unforeseen opportunities. Our goal is to relinquish our fears of failure, break us out of our comfort zone and accept the prospect of failure with the ultimate goal of using it to better understand what success looks like, and how the struggle and pain of failure, and the learning that accompanies it, opens our mind to new possibilities we wouldn't have otherwise seen. These games create comfort with failure and build up our actionable learning muscle (insight synthesis, etc) that should accompany every unsuccessful attempt at success. Failure and learning for the win!

Have you sat through a retrospective that feels like Deja vu? Didn’t we already come up with a plan to fix this thing we are talking about, AGAIN! Are you in yet another blame/complain session with no apparent way to fix the complaint? Time and again this happens in retrospectives and before you know it, the team thinks they should cancel them altogether because they aren’t effective. Fortunately, there are clear steps you can take to fix this and make your retrospectives highly effective.

In this session we will cover the common patterns that typically lead to ineffective retrospectives. The downsides to the team when retrospectives are ineffective. Then I will give you a very effective format to follow along with some different techniques to help get your retrospectives to be very effective.

Picture a tiger in front of you at this very minute. A ferocious feline looking for its next prey. Chances are you'd bolt for the door without even thinking. Your body would flip its flight or fight response switch and in this case run for safety. This is called heuristics, mental shortcuts that help us make decisions without spending a lot of time.

Now, ferocious felines in offices are most likely unlikely (and potentially questionable --someone call PETA!), however high pressure situations are not uncommon in Agile Teams. Situations that at times unconsciously flips our flight or fight switch in our brains and lead us to jump into conclusions about our work, our colleagues and lead us to make poor decisions. This the brain suffering from cognitive biases.

This talk provides an introduction to cognitive biases and how they sneakily find their way in our teams and affect our team dynamics and productivity.

I'll cover 3 aspects of teams that could be impacted by these cognitive biases - team dynamics, communication and productivity.

I'll discuss the symptoms of these biases and show you how to proactively control and reduce its effects for more effective teams.

Agile is a set of values and a mindset. As such, it can be hard to answer questions that leadership often asks. These questions include: How agile are we? Are we getting more agile? What are the growth opportunities for our team?

Many organizations use assessments to determine their level of agility. This session will introduce several assessment approaches and tools. Like medicine, when used incorrectly, the results can be toxic. We will explore the merits, potential uses, and possible downsides of each approach.

You will leave this session understanding more about your options, as well as insights for framing an assessment that fit your needs best when trying to measure your organization's culture and teams.

As an undergrad, when I declared my self-designed major to be a combination of Peace Studies and Information Technology, I remember my friends asking me, "What are you going to do with that? Mediate conflict between computer nerds?" Now, as an Agile Coach and Scrum Master, I find myself regularly doing just that (and I love it)!

While it can certainly be helpful for a Scrum Master to understand your AWS architecture, it is far more important for your Scrum Master to understand your organization's people architecture. They need to know how things are supposed to get done and how things really get done. They need to know how to create psychological safety inside the team while protecting them from interactions outside the team that may undermine that safety. Most importantly, they need to understand how the people in the organization "fit" together and how to mediate the inevitable conflicts that will arise when these parties have opposing goals.

In this interactive session leveraging real stories from the trenches, I will show how the non-technical, liberal arts Scrum Master can help your teams thrive by understanding an organization's people architecture to effectively anticipate, uncover, and mediate conflict between opposing parties in a productive manner.

No matter what you studied in college, you are welcome and encouraged to attend this talk!

Slides: https://www.slideshare.net/Camille_Bell/kata-your-way-to-sw-craftsmanship

Maybe you are a developer and want yourself and your team to become Software Craftsmen.

Or perhaps you've a leader and heard about the greater quality and productivity of high functioning agile development teams.

Or you could be in dev ops and know that you can't implement a CD Pipeline without a solid suite of automated tests. But your developers don't practice Test Driven Development, Refactoring or other agile technical practices, and you don't know how to guide them.

Whatever your role, you would like your team to become software craftsmen, proficient in agile technical practices.

Join Camille as she shows you how to Kata Your Way to Software Craftsmanship.