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."

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.

Agile at the team level fosters self-organization by leveraging constraints. Timeboxes, Work in Progress (WIP) Limits, and clear operational definitions are excellent examples of the kinds of constraints teams regularly employ to deliver reliably. Are you familiar and comfortable with these ideas, but uncertain how to apply them at larger scales? Are you looking for techniques that will allow you to harness the creativity of your teams to enable self-organization at scale? If so, this session is for you.

I’m passionate about applying concepts from Complex Systems Theory (as developed by Dave Snowden, Alicia Juarrero, Bob Artigiani, etc.) to the work of software teams. My colleagues and I at Excella have been exploiting these ideas by using a variety of patterns borrowed from different theories and frameworks to allow our teams to grow like healthy plants in a garden. From Large-Scale Scrum (LeSS) we leverage the concepts of a single product backlog and a shared cadence. Kanban principles of visualizing the work and limiting WIP help align the teams and foster greater collaboration. Dave Snowden’s emphasis on Homo Narrans—the human as storyteller—has provided a framework for clarifying and promulgating common values, which are essential for decentralized decision-making. Collectively, these mental models created an environment that helped us scale one of our engagements from three teams to eight over the course of a single year.

Shipping code is hard and it is rough! It doesn't have to be. Using Docker, Heroku and CircleCI you can set up a world-class Continuous Integration and Continuous Deployment pipeline in an hour with advanced functionality like Heroku preview apps, provisioning servers on-demand for to scale and containers that leverage layering to enforce Enterprise requirements, while giving developers access, flexibility and speed to get their work done. With duluca/minimal-node-web-server docker image and how you can tailor it to build your micro-services or web servers in a matter of minutes using Docker and deploy your web app on the cloud.

Does your Scrum team start all its stories on Day 1 of the Sprint? Do stories sometime carry over into the next Sprint? Or perhaps testing always gets crammed in on the last day of the Sprint? If any of these sound familiar, your team may benefit from improving its flow.

Flow metrics are common with Kanban, but can provide tremendous value to any team, including those using Scrum. In this session, we’ll start by exploring the value of achieving a smooth flow of work (versus simply achieving maximum utilization) and give simple ways for your team to measure its flow. We’ll look at examples of metrics including lead and cycle time, throughput, and the cumulative flow diagram (CFD), reviewing what each represents, easy ways to collect them, and how they can be used in both a Kanban and Scrum context. You’ll leave the session knowing how to interpret and capture all these valuable metrics, so your agile team can measure and improve its flow.

Story point is an arbitrary relative measure used by Scrum/agile teams to define the effort required to implement a story or feature. This is a metric to measure the cost related to the implementation of story points. This metric is called Story Point Cost. It should allow to track development costs and also make the Scrum team aware about the budget issues of their project and for product owners to easier compare cost to gained value.

Agile is an incremental and iterative approach to delivering value to our customers. But too often we assume it’s really all about ways to slice work into smaller batch sizes and that both approaches are fundamentally equivalent. However, there is a crucial difference and this lack of awareness is a major contributor to projects and teams that are AINO (Agile In Name Only)!

In this session, we will discuss how to differentiate between incremental and iterative approaches, their strengths and weaknesses, and why you really need both. We will explore the many ways in which iteration shapes the core of Agile practices, how it supports and enables the benefits of agility, and how understanding its awesome power is a key step in moving from “doing” Agile to truly being agile. In addition, we will take a close look at the practical implications of when to use each approach by discussing real world scenarios, highlighting common Agile anti-patterns and (re)examining familiar story slicing patterns.

You will walk away with both a better understanding of one of the most important underlying principles of agility and immediately applicable insights for your daily work!

Losing good people during your transformation? Getting more resistance than you expected? You may be producing unwanted reactions in the way you are leading your people through change.

If you want your Agile transformation firing on all cylinders without the harmful side-effects, managers at all levels should focus on becoming Catalysts. Much like a chemical catalyst, your job is to help boost organizational performance by creating a healthy environment and providing the needed support.

In this interactive presentation-tutorial, we’ll explore how you can do that through some simple techniques that anyone can do; extracted from Fearless Change and Liberating Structures. We'll relate these techniques to how trust works and give you some powerful ways to improve your organizational trust.

Have you ever been in a technical interview, stuck at a whiteboard or solving a brainteaser, and thought “there must be a better way”? Good news: there very much is.

Agility and adaptability are crucial for a development team's success, but how often do we target for agility when considering who to bring into our team? And how do we set expectations for agility from the first time this potential new hire begins evaluating our team?

In this talk, I walk through my philosophy & provide practical tips for running technical interviews that are primed for success.

Sure, we would like everyone to have an agile mindset and focus on continuous improvement, but sometimes as Agilists we need to work with stakeholders who don’t agree with our priorities or our methods. When you need to get something done in a bureaucracy, how do you adapt? Every place you operate has a unique combination of people, processes, and problems. We'll discuss general principles that will help you navigate successfully.

Over the last 5 years, Agile approaches have seen widespread adoption across the US Federal Government. Where real commitment is given to proven Agile frameworks and techniques, programs do see significant improvement in value delivery and speed. But unfortunately often, ‘Agile’ nomenclature is used while perpetuating behaviors that make real improvement impossible, and may actually make the lived experience worse for participants or stakeholders. And where Agile approaches fail, they add to a narrative that real methods won’t work in this environment. Many of the anti-patterns I’ve seen working as a Coach in the Public Sector are rooted in decision-makers clinging to 5 myths about Agile in Government. This talk will explore these 5 myths, where they come from, and some ways out of them.

Have you ever been asked the question, or even wondered yourself, "Is a Scrum Master job really full time?" In this workshop you will explore examples of exactly what a Scrum Master could be doing on a regular basis and things an effective Scrum Master does that may get overlooked by individuals and organizations. By the end of this session, you will be armed with a valuable set of information that will empower you to have conversations about just how challenging of a position Scrum Master really is, even if that conversation is with yourself in the mirror!

What can an experienced Scrum Master learn by going undercover, passing himself off as a software developer?

• Why developers complain about meetings!
• Why they always want to "pay off technical debt!"
• Whether TDD & Pair Programming are worth it!

For the last year, Dane has served as a Ruby developer on a Scrum team, while all of his prior experience on Agile teams was as a Scrum Master or Product Owner. Dane will share his experience and insights from life on both sides.

Scrum is easy to understand but difficult to master. Many team members think of Scrum as a framework with roles, meetings and artifacts. They take a training class and come back to work and take on new roles. They setup Sprint planning, daily scrums, reviews, retrospectives, and grooming meetings. They create product backlogs and user stories, task boards, and burn down charts. They work in Sprints while building a product iteratively and incrementally. This starts out well but soon difficulties arise and anti-patterns and smells emerge as teams start moving from Scrum to ScrumBut. You’ll often hear “We do Scrum but we don’t have a Product Owner” or “We do Scrum but we don’t test within the Sprint”. In this interactive session we will tie elements of the Scrum Framework back to the values and principles of the Agile manifesto to better understand the purpose behind the framework and it’s roles, meetings and Artifacts. Come to this session to understand the reasons things are setup in a certain way so that you can assess the risks and impact of a deviation from the basic framework.

There are now so many well-marketed Agile Scaling Frameworks ([email protected], LeSS, SAFe, DAD, Nexus) that’s it’s difficult for organizations to differentiate their value propositions, tenets, assumptions,… But luckily there’s one, well established approach that blows all of these methods completely out of the water. Come learn about DONt: The best way to scale.

Whether it be in non-profits, the government space, or even in commercial software development, we are often at the beck and call of powers outside of our control: a new election result, a tax-law coming into place, a competitor trying to get to market first. This causes us to have to abandon the best practices that we know we have to do in favor of meeting our client's expectations. "You don't need to write so many tests, just write non-buggy code! Why are you pair programming? More developers working on a single story is inefficient! We don't have time to refactor code, just make it work!" This is a story that we all know too well. In this talk, I'll speak about my experiences with two different entities under entirely different expectations. One is a non-profit that needed to update its ageing mainframe system, and the other a government agency that is tasked with a seemingly impossible goal that happens to coincide with an election cycle. In each scenario, we see the effect that this has on the quality of software. We'll also look into how the environment, people, and timelines impacted the approach of each team.

Retrospectives are a key component in assisting you teams to improve. Most Jedi, er, Scrum Masters know how to facilitate a retrospective. However, many do not consider how to SELECT a retrospective based on the needs of their teams. Different types of retrospectives will be considered, such as the 6 Thinking Hats, Appreciation, Sailboat, and in addition, two Custom retrospectives. Have you considered which retrospectives you would facilitate for your team based upon their needs? For example, if you are with a new team, what would retrospective would you select? If your team seems to have trouble working together or communicating, which retro? How could you customize a retrospective to address the needs of your team?